BackdoorCTF and Quizzes

I recently hosted a Geek Quiz at my college along with Giri. The quiz was mostly geek with some sports and pop-cult trivia. Here are the slides for the quiz (both prelims and finals):

Geek Quiz Prelims

Geek Quiz Finals

Some audio/video files for the finals are up here.

BackdoorCTF 2014

Last year, I was the coordinator for Backdoor CTF 2013, a jeopardy-style CTF contest hosted by SDSLabs under the aegis of Cognizance. This year, I contributed 3 problems to the CTF. The problems were as follows:

  1. web200 - Timing Attack (Source)
  2. web250 - YAML Code Execution (Source)
  3. web100 - _ Template Code Execution (Source)

You can find writeups/solutions to the problems all over the internet and on ctftime. Hosting a CTF is always a humbling experience and it was great to see teams from all over the world participating in backdoor. We hope to return next year with even better challenges.

Cogni Geek Quiz

After that I teamed up with Giri again (along with Sukun) for the Cogni Geek Quiz, hosted by the winner of my quiz, Vikram Rathore. While we won the quiz by a large margin (30 points), I managed to get my own tribute question wrong unfortunately.

However, it was a great experience involving some really nice questions. Update: The slides are up at mega.

Colors & Typefaces


My experience at nullcon 2014

I was recently a speaker at nullcon 2014, a premier infosec conference in India. My talk was a re-hash of my earlier talk at Deloitte CCTC-2 and was titled “Browser Extension Security”.

I applied for the CFP sometime in November with a copy of my talk, paper and code I’d used. My application was reviewed and I was told, accepted under the night-track on 13th February.

The talk itself covered browser security mechanisms, and where the current state of art lies (Chrome) with respect to Browser Extensions. The talk was pretty well received (even though I sweated a lot onstage), and a lot of attendees came up to me to discuss it further after the talk.

The paper behind the talk, and the related source code can be found on GitHub. Create a new issue or send me an email in case you have any queries. ~The tool demo I gave during the talk can be found at (Not available anymore). Note, however that it currently uses cached data to check for permissions, and is not a LIVE tool.

nullcon was my first conference, and I’m glad to say I enjoyed it very much. From the great hosts to the amazing parties, and all the free booze, I loved it all. I made a lot of friends, and I plan on keeping in touch. The networking level was amazing at the conference, and I was happy to get in touch with so many guys in the industry, so to speak.

A lot of people queried me about future research on the topic, and while I currently do not have enough time to pursue it, its on my radar of things to do. I’m also thinking of getting in touch with the Chrome Security Team with my research.

As an aside, a big thanks to Rushil for helping me in the first version of the paper for CCTC. It won’t have been possible without him.

##Some Clicks

I’m still waiting on receiving official clicks from nullcon. Will update this post when I get my hands on them.

Using Jekyll optimally without plugins

If you’re a programmer, by now you’ve surely heard of the various static-site compilers that are taking over the world. My pick of choice is Jekyll, (about which I’ve blogged earlier as well) mostly because it is the default supported tool for the GitHub Pages service. Read my earlier blog post if you don’t know about Static Site Generators.

Using Jekyll means that it is far more easier for me to host my blog on GitHub Pages by just writing down posts in plain markdown. Markdown, for those of you don’t know is a simple markup language that uses an email-like syntax that is then compiled to HTML.

A lot of power in Jekyll comes from its various plugins, but I’ve always been vary of using them as the default host for Jekyll (GitHub Pages) disables all plugins and runs in safe mode. Plugins are an awesome tool to have, but they are only good if you are hosting the site on your own machines. I’m not shying away from using them but want to point out that plain-Jekyll itself is powerful enough to do most of the tasks. What follows are some examples of how to use Jekyll optimally.

Data Files

This is a recent addition in Jekyll that allows you to use data noted down in YAML format inside the _data directory that is accessible to you anywhere using the prefix. For instance, I recently shifted the SDSLabs Team Page from plain HTML to Jekyll, and I used a data file to define all the required elements that are shown for every user. The data file looks something like this (_data/members.yml):

- name: "Abhay Rana"
  pic: "abhay.jpg"
    Facebook: ""
    Twitter: ""
- name: "Team SDSLabs"
  pic: "sdslabs.jpg"
    Facebook: ""
    Twitter: ""

Then, I iterate over this data using the following syntax:

{% for member in %}
<img src="pics/{{member.pic}}" alt="{{}}">
<div class="img-bar">
  <span class="img-title">{{}}</span>
  <span class="img-icons">
    {% for link in member.links %}
    <!-- link[0] holds the hash key = facebook/twitter -->
    <a href="{{link[1]}}"><img src="assets/{{link[0]|downcase}}.png"></a>
    <!-- link[1] holds the hash value-->
    {% endfor %}
{% endfor %}

Earlier, you could have achieved the same thing by adding this data to your _config.yml file, but the _data folder allows you to store data properly in various files, if needed.

Liquid Filters

Since Jekyll relies on Shopify’s Liquid language for templating purposes, it has a very large list of supported functions, filters and markup tools ready for you to use. For instance, while working on the SDSLabs Portfolio, I used the split and downcase filter to convert a known list of categories to single word objects that could be used as file names.

{% for category in %}
  <!-- category is something like "Web Development"-->
  {% assign category_name = category|split: ' '|first|downcase %}
  <a href="/category/{{category_name}}.html">{{ category }}</a>
{% endfor %}

The above snippet converts a string like “Web Development” to a smaller string “web” that can be used by us for filenames much more easily.

You can check out more liquid filters over here. These include things like plus, times, reverse, and even md5 (helpful for gravatars).

Code Highlighting

Markdown is really awesome, but it lacks Synax Highlighting for code. Jekyll uses pygments to support syntax highlighting for various languages. To highlight a piece of code, you just use the following syntax:

{% highlight ruby %}
def show
  @widget = Widget(params[:id])
  respond_to do |format|
    format.html # show.html.erb
    format.json { render json: @widget }
{% endhighlight %}

And the output will look like this:

def show
  @widget = Widget(params[:id])
  respond_to do |format|
    format.html # show.html.erb
    format.json { render json: @widget }

Everyone knows about handling the blog posts permalink using the permalinks setting in _config.yml. But did you know that you can provide custom permalink to any page in your site? For instance, the Jekyll documentation site uses the following:

permalink: /docs/config/

in the frontmatter for the file docs/ The file would have been published to docs/configuration.html by default, but the permalink in the file forces it to be published to /docs/config/index.html. Its a really nice setting that allows you to customize the post url for any particular post.

Raw Liquid Tag

In the rare case that you want to use liquid-like syntax somewhere, say you are using Handlebars (which uses {{{variable}}} to echo variables). You can use the following syntax:

{% raw %}
Here is some {{mustache}}
{% endraw %}

In fact, I’ve used the raw tags a lot in this blog post to escape all the liquid portions. You can see the liquid documentation for more help.

Side Note: Writing the endraw tag in liquid is really, really hard.

Embedding HTML/CSS inside markdown

Sometimes, there are some things that just can’t be done with markdown. For instance, if you need to use a custom tag, or need to write some css within the markdown document for some reason, there is always a way: just embed content inside <div> tags. This is not a Jekyll feature, but an implementation detail of Markdown itself, but I think its hacky enough to get a mention here.

Writing **markdown** here
      margin-top: 10px;
Back to _Markdown_.

Anything inside a <div> tag is untouched by Markdown, and is rendered as it is.