Tag Archives: hacking

VTech Kid Connect Data Breach

On November 14, 2015, VTech discovered a hacker had broken into their databases, servers, and websites. The hacker used SQL injection to gain complete access to the databases that held all of the data used by the Kid Connect application that VTech uses.

A friend of mine wrote up an awesome case study about the breach and you can read it here StephenManz_KidConnectHack.

My two cents on the VTech breach

(Not a TL;DR of the case study, just what I took away)

While in the database, the hacker discovered that passwords were hashed using MD5. Which is pretty easy to crack now thanks to faster machines and better algorithms. MD5 hashes any input to 16 bytes of encryption, using brute force or rainbow tables, even guessing common passwords and comparing them to the hash, are great ways to break the hash.

This means the hacker gained access to customer data, related information like who ordered the toys, and information related to that. For example credit card info, home addresses, and more.

This is another example why it’s really important to consider abuse cases when testing you applications. Even if your databases is “just for a kids app” it can still be the end of the world for your clients. Proper input validation and query construction is very important for any application. Automated test cases should try things other than what is expected, like SQL injection or XSS. For example, a child’s name shouldn’t contain special characters.

Exploits of a mom, xkcd #327
Exploits of a mom, xkcd #327

Also don’t use algorithms that are broken, at the very least google the algorithms you plan on using and see what the infosec community thinks of them. MD5 hashes and SHA-1 encryption are examples of algorithms that used to be good, but have since been become crackable. Do your research!

Again, please check out Stephen’s case study in the link above, he did a great job summarizing the VTech breach. VTech also has a formal press release about this breach.

My first CTF: ruCTFe 2015 w/ #Misec

I know there is a lot of different people reading this post; mentors, coworkers, students, friends and family. So I’ll be as thorough as possible to cover all the bases. Mainly because I’m very excited about all of this and I want to write down all of the details before it gets too late. (Feel free to skip a paragraph if it gets too boring)

what’s ruCTFe?

First off, it is capture the flag! Why am I so pumped about a game of capture the flag? It’s the international hacker version of capture the flag!! Imagine this, Russia (the ru part) is the host. They give every team a virtual machine (vm) with a number of applications “ready” to be deployed. Each team is responsible for keeping their apps online as well trying to bring down other teams apps. Our Russian hosts have access to everyone’s apps and are able to “drop” flags throughout them.  Flags are strings like “A23HFK36JG732IE436GHD8OVH1297QUF=” and you know it’s a flag because it’s 32 capital letters and numbers followed by a “=”. Each app has a unique twist that makes the game more interesting. For example, one app was written in Python, another was in C and used .cgi files (WHAT?). Some apps stored data in mysqli and sqllite databases, others used files with JSON. The variety added  complexity that made the game more fun. #Misec (a local hacker group and our team) arranged people into four groups. Red team focused on attacking other apps and searching for flags. Blue team was responsible for defending our apps and hardening the server. Green team was ops, they built and maintained the network. Fuchsia team was our developers  and became jack of all traits because they worked along side red team on code dives while implementing blue team’s defenses.

I was a part of the red team. I really enjoy penetration testing and I knew this would be great experience. Our team lead was Austen. He walked me through a lot of what it means to be on the red team. I’m very thankful for his help. This was my first time implementing a lot of tools on the Kali OS and  I had no idea what I was doing. Last weekend was a prep meeting and I found out that my old Kali box wouldn’t update, so I had to prepare a new one during the week. #Misec was really helpful every time that I got stuck or hard a question during setup.

Walk Through

My day started at 3:30am with a blaring alarm clock. That was probably the worst part of the day, which also means the day would only get better right? I arrived on site around 4:20, just in time to help hang wires and bring in equipment.  As everyone showed up, we brought out our machines, connected everything and got the VMs ready. I worked with Brad (Fuchsia lead) and Austen to reset the root password and config SSH so that I could log in from Kali. Once our environments were set up, the red team started looking for what ports were open and what  services were listening. This was the first time we found what the apps were using. Like I said earlier in the explanation, there was a wide range of databases and languages at our disposal. Brad dumped the databases and passed it around for others to try and understand while Amanda (El Conquistador and Blue team leader) searched for passwords and configurations that needed to be updated. Otherwise other teams could use the default accounts to own us.

Throughout the morning, the green team worked to get the apps online. As they did that, the red & fuchsia  teams searched high and low for vulnerabilities in our VMs that would get us an advantage against other teams. The blue team continued to check our apps and secure them as needed. I spent this time running my VM through Armitage. I wasn’t able to find any exploits right away that the apps were vulnerable to, but that was to be expected. Armitage is very automated and it’s hard to customize exploits to work with specific apps. After that turned out to be unsuccessful I turned my attention towards Burp Suite. However, I wasn’t able to configure it correctly so I turned my attention towards code dives hoping to find something obvious like SQL injection or worse. The apps were all in their own directories under home/ and it was very interesting to look through how our hosts had made the VM. As I was looking around, Austen found one of the apps used the same auth token in a cookie for every user in the app. I helped him confirm that by recreating what he did on my VM. The idea for a exploit was that if we could pick up  a player’s cookies when they dropped flags off to the host, we could get into the apps they were just at.  Austen also found a second vulnerability where for the Python app, the password was “hashed” by turning numbers into their ascii hex equivalent. I wrote a small python script to decode the hashes incase we ever got a hold of another teams JSON files. Just a quick note, this is the first script I’ve written to help break a web app and I was really excited to see how easy it seemed; the development background (and wide range of python libraries) really helped.

The apps go live

Between 11 and noon, the green team was able to bring our app online at full capacity. This was our first time being able to score points and everyone was really excited. However this also brought a new issue, where other teams could now attack us. The plan seems to be working pretty well though, we were earning points for keeping the app alive and no one seemed to be trying to attack the server too badly from the outside. As soon as the red team had access to other teams, we started to poke other teams servers to see what was possible. I tried to find a way to get my python script to work, but first I needed a way to find the json file. I tried calling it directly from the URL, SSH-ing into their application server, and just crawling through the app. This didn’t turn out very well so I tried another tactic. Now that we had real targets, maybe it’d be worth trying Armitage again, other applications might not be as hardened as ours, right? Well, like my VM, it didn’t return any easy results, so I abandoned the idea to return to poking at random teams’ apps, hoping to find a XSS or SQL injection bug somewhere. While I was digging around, my box froze. I have no idea why, but it used to happen all the time when I was running windows7 (I assume it was related to the hardware). I just rebooted Kali and continued my barrage of random attempts to attack other teams.

During my assault, Amanda came over to ask if we had done a game-wide nmap scan to list all of the active teams. The game was a almost 3/4 of the way done and no one on the red team had thought to scan everyone after we had gotten our apps up on the game network. Amanda showed me how to use RAWR, a python wrapper of nmap that allowed us to scan and log more cleanly then just saving nmap output straight to a text file. While Amanda filled me in, she was scanning some of the other teams’ servers. I used Python to create a input file for RAWR that would hit the production box for 254 ip addresses. As I started to run the scanner, Austen found another way to grab flags by recreating auth tokens for users of a Ruby app. He quickly wrote up a Ruby script to loop through different teams and a range of IDs (both were used to create the auth tokens) and distributed the code amongst the red team to try and crack as many teams as possible. He ran the code first and started to find flags on the other teams servers, however when he went to turn them in, the host’s scoreboard server was having connection issues.

Down to the wire

Since there were issues from the host, we tried to hold onto flags until we were able to reconnect to the scoreboard and turn them in.  This was risky because it was going on 2pm and the game was only live for another hour. As soon as Austen found a valid flag, the red team started running his script over different teams trying to get their apps to give up more flags. I made a couple modifications to his script on my box so that instead of going through 100 IDs on a team, then going to another team (and so on), the script would ask me for what team to scan and wouldn’t iterate to a second team. I was able to use this modification to run a few scripts at once and try to grab as many flags as possible. As we were searching, we were able to find a good amount of flags. The second modification I was trying was to add inputs for the starting and ending IDs for the script. I couldn’t get it to work and didn’t know why until after the game ended when I asked Austen to look it over. I was still able to get 6 flags in the last ten minutes of the game and I was very excited to have contributed to increasing the team’s score. It felt amazing. At the end of the game, we were ranked 118th out of over 300 teams and I was proud to have helped and learned so much, especially since we climbed 3 ranks within the last few minutes!

ruCTFe partial scoreboard
Misec beat Batman

Conclusion

I want to give a huge shout out to Misec for pooling some great local talent into an awesome team. Thanks to Steven for organizing this year’s event and to Jason for building our infrastructure/network. Also, if it wasn’t for Austen, Brad, Amanda, Wolf, Ben and everyone else who helped me and made me feel like a member of the team. I wouldn’t have been able to learn as much as I did or have as much fun without you. I can’t wait to see what will happen at ruCTFe 2016!

jwgoerlich’s PCI talk at #MiSec

First meeting at #MiSec and I missed it! Right as I was about to leave, there was a knock at my door. Impromptu Comcast employees trying to save us a couple hundred dollars. Of course by the time they were done installing free cable, it was already 7:05 and it would take 30 minutes to drive to the meeting… So I watched the live stream on youtube and wrote comments on IRC.

Besides the hilarious chat and twitter jokes, J’s talk was really informative. While it was high level (which is great for a n00b like me), it left me with a lot on my mind about things to expand into. Some notes that I took away was.

  1. “Old man my ass” The old ways of hacking are still relevant. For Example, applying old phone porting techniques can get you someone else’s apple pay wallet.
  2. Bluetooth is insecure. Mess with it early since stores will be adopting it for purchasing and such
  3. So what if someone steals your credit card? Smart card holders will review often and will report bad charges (maybe cancel the card)
  4. @taco_pirate will p0wn @jwgoerlich by the end of the week.