Tag Archives: SQL

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.


In July of 2015, I volunteered to create a web app to score college gymnastics. There’s an old blog post from my original COGSS project. COGSS 2.0 is going to be a place to submit scores and have rankings for a meet. Sounds simple right? Turns out it is not, this project feels like it is turning into a full blown application which ideally would require a dev team… Instead there is me!

Notes from the first attempt at COGSS

The site was built using PHP, blame my three years of experience working with older projects while I was a programmer at Matrix. PHP was my most proficient web app language at the time. The only issue was that the code was monstrous. In a rush, I didn’t use a class structure. Sections of PHP and HTML interwove each other and there were even 50 line chucks of echo .= “<html>stuff…”. After more years of better web development and looking at Java classes and NodeJS, I knew there were much cleaner ways to code. I vowed to revisit the code and clean everything up…. one day

Something else that slipped my mind but was a major overlook on my part was being too lax with my Github commits. Without a .gitignore file, I committed the entire project to easily load it onto my server. Not a big deal, except that it means my config file (and credentials) were stored publicly in plaintext. When I found that recently, I had a mini-heart attack. Well, guess it’s a good a time as ever to change passwords…

The last take away from the old version I had was performance. Page loads were waiting on SQL, server side pages would take minutes to load for a client. That’s terrible, so hopefully this next time around the cleaner code and one-page-application (thanks Node) will make things run slightly smoother.

COGSS 2.0 Redesign

COGSS 2.0 redesign notes
Messy i know, but the ideas are all there.

Over the summer, I talked to my girlfriend who is the president of the EMU Gymnastics club and she told me a lot of things about the layout and design that I overlooked. It will be a lot cleaner with the new design and I’ll upload more pictures when I have something better to show later on. It’s still heavily reliant on Bootstrap because I’m not going to spend the time to customize everything, I’m not even sure what people want so I’m going to go with their “minimalist” look.

I wanted to have better URLs as well, so routing was something I was looking into so that instead of “teams.php?q=blah” in the URL, it would be something clean, and that requests would be used correctly. NodeJS should make that really simple, but I have little to no experience with it.

Tasking / Planning

COGSS 2.0 Kanban board
COGSS 2.0 Kanban board, all my tasks neatly laid out thanks to Trello.com

Last time, I didn’t have a good plan, I had goals… but no plan. It was chaos and it surely showed in the final design. This time I’m using Trello to create a sort of Kanban board. There are four sections, backlog, blocked, doing, and done. Tickets are smaller items with only one feature. This will help me organize what to do, and my commit will look cleaner as well. For example, my next task is to “Add [the] Teams Page”. Basically set up the routing and use a template to load a proper page. Hopefully the smaller tasks will make this easier. I need to finish the project by the end of February.

Why COGSS 2.0

A lot is changing from the old version, for one thing I’m switching from a PHP web app to a NodeJS app. That in itself is scary and awesome at the same time. It is scary because I have barely used Node before and my main reference is a coworker’s Github repo that he presented last summer. It includes a lot of things I don’t know much about, like Express, Angular, and Less. I can learn on the job and I am really excited to see how it all turns out. What makes it awesome is that is lightweight, fast, and makes routing simple and easy. The only things that will be the same after I’m done will be the database structure and the Bootstrap framework.

Monitoring Honeypot Output

Last week I posted in Hacking about installing a Honeypot to record SSH traffic. Since it was installed, I’ve been working on easily monitoring of the output. Michel Oosterhof, the creator of Cowrie, has done a lot of development work to create some awesome logging output from the honeypot. There are a lot of different options and you can even store output in a mySql database. I found instructions for that on a wordpress blog. Feel free to checkout the current page at greenjam94.me/honeypot.html

First Attempt

After setting up my mySQL, I wrote a page of php functions to run about 8 different queries to get back information I thought was relevant. At first, the page was as simple as possible, the same page with all those functions also displayed the front end. It was a late night rushed kind of job, but you could see some pretty cool stats, in the first 24 hours of the site, we had over 500 attempts to establish a SSH connection to the honeypot. I linked the php page to my website and was happy for the night.

Second Attempt

After looking at the page for a while, the load page took forever, it also didn’t look that good. For one thing, the code was horrible. I had so many php echo statements where there were paragraphs of unformatted HTML. The front end web page was a clear reflection of that. My goal of my second attempt was to make the webpage load fast, even on mobile devices. To accomplish that, I moved all the html to an actual html file and used Javascript and AJAX to bounce requests to the old PHP page.


It’s not anything new, but the site loads immediately and info fills if possible. If for some reason the PHP fails, the site doesn’t break, the page simply doesn’t display that part of the content. With the page being more formatted it was easier to make design changes. The site is slightly more responsive and mobile friendly thanks to better implementation of the Bootstrap framework.

IP Info

The website also uses ipinfo.io to get more information about where an IP address is located, right now the page is only displaying Country Codes, but the idea is to display the IP addresses over a map. Wouldn’t that look really cool? I want to use something like d3 but I haven’t had any experience with it so it may take a while. It’d be nice if it could look like this cesium example.


Our honeypot is monitoring traffic and we see results, but we aren’t doing anything with them. Files and uploads are saved so it’s possible to analyze things further. VirusTotal is a website with a public API to review IP addresses and files for viruses and malicious code. One of my future goals is to set up a connection to the API to turn in anything that gets uploaded through the honeypot. The only issue I see is that filenames get changed, and VirusTotal doesn’t like that. The name is changed to a hash of information about the session that uploaded the file.

Future Plans

Better use of IpInfo and VirusTotal are the next steps to improve the site. After that I’ll work on improving the site in other ways. Right now, the honeypot is logging through regular log files, JSON, and mySQL. In the five days it’s been running, we’ve had over 1,000 sessions and logging those in triplicate might get expensive on the hard drive. It’d be more efficient to write the PHP backend to pull from the JSON logs instead of needing the SQL database.

Defend your website against SQL injection and XXS

Hey everyone, so at work we’ve had a couple vulnerabilities pop up so I was privileged with writing this up and I wanted to share it with you. I hope you find it interesting! Sorry it’s such a long read. There’s two parts, one for SQL injection and one for Cross Site Scripting.

SQL Injection
Check out SQL injection on OWASP

SQL injection is, simply put, a user adding additional requests to your database calls. For instance if you ask for a search term and compare that term to the database with something like:

SELECT title, author, text FROM books WHERE text LIKE ‘%$input%’

Developers can defend against SQL injection by validating all inputs. This means that we use a function that strips away characters that is required to run SQL from that input.

validateInput() would be a function we define that removes characters such as
*, `, or “. Something else to put in your validateInput() function would be PHP’s  MySQLi escape function. It’s also wise to not allow Users to type in what tables they want to access in the database. Use separate queries instead of a dynamic one.

One of the simplest ways to test your inputs is to add ” or 1=1” to the end of the input. If we put ”’something%’ OR 1=1”’ into the example above we get:

SELECT title, author, text FROM books WHERE text LIKE ‘% ”’something%’ OR 1=1”’ ‘

Cross Site Scripting (XSS )
Check out XSS on OWASP

XSS is similar to SQL in the sense that a user is trying to add their own code to our website. This time instead of affecting our database, it’s adding a javascript script (or a similar tag) to our pages code. Do you know what this is below?


It looks like a lot of gibberish to me! While we don’t expect our normal users to type this into our log-in field, a hacker wouldn’t hesitate. While it looks like nothing, this is actually the HTML escape characters for <script>alert(1);</script>. The user just added their own javascript to our website!

Just like the input we use for SQL queries we need to validate all inputs! I can’t say that enough. If the page is grabbing something, we need to pass it to a function that strips out anything illegal. In XSS’s case, we want to remove anything that is or could be a tag.

Our validation function needs to remove all tags, and the easiest way to do that is with PHP’s strip_tags function!

Want to see if you can add your own javascript to the website? Use the alert(1) from above. It’s harmless and has a nice visual to show you
that your site is indeed vulnerable to XSS.

In Review
* In general, assume that all users are vicious hackers trying to break your brand new website.
* Do NOT use user input for HTML comments, scripts, attributes, or CSS. ”’EVER”’
* Consider hiding SQL errors on live sites, Hackers use the information to understand the database layout.
* When taking input from a user, minimize their possible choices as much as possible.
Example: Ages – Should only be positive whole numbers, no special characters.
Example: Email – Should be a string @ string . string. Now might be a good time to learn regex
Example: Names – Should NOT have punctuation or special characters.