MD5 Length Extension and Blind SQL Injection - BruCON CTF part 3

This will be the last video covering the Brewon CTF 2016. I didn't cover every challenge, but I think they were quite diverse. But let's not waste any time and check out the last [Music] three. The first challenge is called Breaking the Crypto. There's also a hint about Flickr which might help you in researching what it is about. But in general, you either know how it works and solve it in a matter of minutes or your mind gets blown. To be honest with you, I didn't know about this kind of attack until I participated in the Breaking Bad crypto workshop by Philippo at the Chaos Communication Congress in 2014. He did a walkthrough of a Vimeo crypto vulnerability and explaining it in great detail how it works. And I just sat there in awe. I'm not going into all details right now because I do want to cover this properly in a full episode at some point, but if you are interested in it, go research it yourself. I will just explain the abstract idea and show you an easy tool. The challenge itself is not that cool. The crypto attack is just so beautiful. And now that I completely overhyped the attack this challenge is based on, let's have a look at it. I kind of forgot to record most of the challenge, so I got to describe it to you. So, the initial URL you are given points to a login field and somewhere was a hint that the secret key is 18 characters long. Besides that, there is not much. Looking at how the login or session stuff is implemented, we learn that there are two get parameters. One is user and the other one is called MAC. user is a B 64 string and decoding it shows that in my case the user was number 68. We can see the user number is between two pipes. Our goal is to log in or authenticate as admin which has user ID 1. So first attempt would be to simply change the basic C4 string to contain pipe one pipe. But this doesn't work. The reason for that is the MAC parameter. MAC stands for message authentication code. Like the name says, this code makes sure that a certain message is authenticated, meaning trusted. The question is how the MAC is implemented. We have two kind of information about it. First of all, the hint said that the secret key is 18 characters long. A secret key is necessary because this way the server can verify that a message is trusted. You could almost say it got signed by the key, but but that that is not correct. The second thing we can assume is that the MAC is implemented with MD5 just based on the length of the hash. Now a very weak MAC implementation would simply do the following. It would take the secret key and append the message it wants to authenticate and then creates an MD5 hash of the whole string. Next time it will receive a message and this MAC. It can then take the secret key again, append the message, calculate the hash, and compare it to the MAC. If that's the same, the message is trusted. This way, only somebody who knows the secret key can calculate a correct hash and thus create a user parameter with ID1. Right? Well, here comes the mind-blowing part. MD5 is vulnerable to a length extension attack. What does that mean? Uh MD5 length extension attack basically means that we can add more characters to a string and update the hash so that it stays valid. In this case, we have an unknown secret key with some characters we control afterwards. And we know the hash of one valid message. You would think you need the secret key to calculate the new hash. But we can simply take the already computed hash and the valid message we know and then extend it and update the hash. So when the server verifies the message, it uses the secret key and the message, calculates the hash and will get to the same result as we do. Obviously, it's not as simple. There are a few pitfalls if you would completely implement it yourself like padding and you would have to understand how MD5 is computed. But we will now just use a tool to do it for us. The tool is called hash pump. We simply pass the MD5 signature. We know the part of the message we know which is the 68. The secret key length we know with 18 and the data we want to append in this case the one. So the result will be the new MD5 hash and the new extended message with some annoying things in it like petting. But I was just hoping that the application will forgive when it comes to this stuff. And I was hoping it will ignore it and just take the last number. So now you just get the B64 encoding of the new message, copy it together with the new MAC MD5 hash into the URL, send the request, and we authenticate as admin and get the flag. Very easy, but a lot of points. The next challenge was my favorite of the whole CTF. Not that it was particularly difficult or a crazy challenge, just because I haven't done it before and it was somehow interesting for me. The challenge is called lock analysis BSQLI. The description says you are good at hacking. So what are you tracking? Find everything you need and make the flag. The hint also said that the flag will be the password of the administrator or something. So the challenge was actually less vague than the description makes it sound. Anyway, the title is already basically telling you what it is about. You have to analyze a log of a blind SQL injection short BSQLI and you are given a typical web server access log. The log contains a lot of information such as IP address request method, the access path as well as the HTTP response code. For example, 200 means everything is okay and some more information like the size of the response and the user agent. So as a first step, I just try to get an overview of what the log contains. scrolling around a bit and with searching for interesting keywords, you can quickly find all the SQL injection attempts, but it's a bit hard to see what's going on. So, I start to write a simple Python script to explore the content more. For example, I URL decoded each line to make it easier to read and I stripped away what I considered unimportant information. Later, it will turn out that I stripped away too much and it took me a while to realize how valuable some of the information was. But I keep exploring the data set by changing the script, filtering for certain lines, searching for interesting keywords, cleaning up lines, and so forth. Just trying to figure out what it might be looking for. The challenge was clear that we should analyze the blind SQL injection attempts. It's not hard to find these. So when you look at these requests, you notice that at the end, it always does a comparison with a number. For example, is something bigger than 64. And this is basically what the blind SQL injection does. In a blind SQL injection, you won't get data from a database directly as output, but you create a query such that you can leak small pieces of information by for example causing an error if your question is wrong. Let me extract one of those sequences and explain it with that. So basically the automated tool uses limit to access only one character in this case the 40th character of whatever it wants to leak and then ask is the character's ask key value bigger than 64. And if we look at the line afterwards we can see that the next question is if the character is bigger than 32. This means that with the previous question, it probably got a different response and was able to conclude that the character value must be smaller than 64. So it does a binary search for the correct character. Next is checking if the character is bigger than 48. This means that the response of the bigger than 32 was probably correct. And once you follow that, you get closer and closer to the correct character. And at the end there's one last question. And basically now we know the character must have SQ value 49 or 50. Now just write some code to extract those rules from the lock file. The code is super ugly and just very quickly written so don't judge me. But here is where I got stuck at first because I was left with two choices for each character. So I didn't know which of these two is the correct one and brute forcing all combinations is too much. So I put the challenge aside and went out for dinner. I had sushi. Well, I was walking with my friends. I had a revelation that the access lock also included response code and size. This might be the missing information I was looking for. We probably are able to see difference if a certain question returned true or false based on the different sizes of the return code. And that's why I said earlier I got rid of important information. Anyhow, once I included that info, I was able to correctly identify the real character, which allowed me to dump all the extracted information from the blind SQL injection. And here's my script in action. And one of the blind SQL injections did load the etc shadows file that contained the hash of the root user. And then I took the hash and brute forced it with John the Ripper. Took a couple of minutes, but then I successfully found the correct password, which is web master. That was kind of fun. The last challenge was weird. Not really a meaningful security or hacking challenge. Anyhow, the description says, "Is is it encrypted or offiscated?" Here's the content of the file. And you can immediately see that this is not random, so it can't be really encrypted. And some strings look awful lot like meaningful strings, especially the first line reminded me of hashbang n for environment. And that kind of told me that all lines are reversed. So, first I reversed all lines and then I noticed that there are things in there that look like the flag. I know that the flag starts with bron and uses curly braces. And when you start looking for these pieces, you can slowly assemble the flag and you're done. [Music]