MicroCorruption Embedded Security CTF
This is a really interesting challenge for people looking to get into the intermediate levels of hacking. There is a lot to learn in these short challenges about the inner workings of computers; You'll see live memory dump, disassembly, processor and register memory states.
This is not an entry level contest. It assumes you have some knowledge of exploits, and exposure to assembly language, processor state, program counter, heaps, stacks. It teaches by showing. By throwing you into a perfectly designed environment for hacking and letting you sink or float by your own determination. All you know is that there IS a way (or several) to accomplish your mission.
If you're intimidated, I highly recommend some books if this topic interest you. Hacking: The Art of Exploitation, by Jon Erickson or google "smash the stack" for the latest in trends. There are several good articles titled Smash the Stack, and I found this one that looks pretty good on google. School name lends credit: http://www.cs.umd.edu/class/spring2018/cmsc414-0101/papers/stack-smashing.pdf Once you understand concepts like buffer overflow and remote code execution you will be able to get started.
You step into the MicroCorruption debugger:
The tutorial gives the interface a story feel. A story about bypassing locks using knowledge about the system is exciting and I'm ready to get hacking and open some doors for our operatives.
My heart races, as I look over the initially meaningless Memory Dump
I didn't expect something so low level. It's hard not to be intimidated by this wall of obscure Hex/ASCII/memory dump.
I throw those thoughts of imposer syndrome to the back of my mind and think back to the recent reading I'd done on the topic. The tutorial world quickly clarifies any confusion I had about the interface with a walk through. Having understood this, and seeing the password in plain text in the memory dump, my brain explodes in wonder.
That was some clean, good hacking fun. Taught in one of the best ways. They deserve a big fat 5 Star recommendation. Check it out if this sounds at all interesting, it's well documented, and the Assemble or Disassemble page they also provide is quite a handy tool for assembly injection into password fields.
Spoilers Ahead! Go check it out for yourself first if this sounds interesting. It's not as fun when you know how it's done.
Challenge one:
New Orleans is very straightforward since it is just like the tutorial and the password appears right in memory.
But as I move onto challenge 2 I can already see it's not all going to be so straightforward.
Sydney:
Opened and read through the check password section again. It's still interesting. It appears the password has been divided up into literals and is checked in segments, so lets just use those literals as our password, but it doesn't seem to work.
I decide I need to do some studying before I try to attack this.
I took long enough reading, studying the page, and doing research that my lock got reset.
Then the whole thing froze so I decided to fully read the user guide.
Some time goes by before I notice a push command writing the nibbles backwards and realized that I was trying to crack the password with the nibbles in the wrong order. Once this was apparent everything fell into place, and the imaginary door unlocked
Hanoi:
I notice that the change logs can give me a hint about how to solve the prior challenge, so much like a real hacker I read ahead in the challenges to check for anything that might have been changed that might signal a weakness in the versions which were not yet updated.
Looks like I just have to pass one letter to get access on line 455a
password starts on 2400, so Just the last letter matters, and the door swings open.
Cusco:
Starting to look a little different, as the passwords aren't obviously compared anywhere.
My understanding of buffer overflows leads me to just enter 10*'A'+10*'B'+10*'C' and see what gets overwritten. The segment isn't very large and unfortunately it's in a segment that doesn't get executed. But I get an unaligned error which tells me that a jump, or return call failed. I'm overwriting onto part of the stack, so maybe I can replace a return location with my own address.
Success!
Time to move onto Iceland.
Reykajavik:
Not sure if it would help me as much as I believe but I'm wishing I could set a watchpoints to check whenever a location was accessed, or when a register becomes a specific value. Especially because the code appears to have been obfuscated in some way: function called do_nothing, there is a jump to nowhere (x2400), plus there is no longer a function called unlock door. But that's ok we know we have to look for one of the 7F type codes, Unfortunately I don't see anything like that, but I know it has to be here.
Trying the buffer overflow off the bat to see what happens; the lock closes with no error message.
Lock Closes with no error message when the password is entered incorrectly
After a jump to 0x2400 that must be a function call of some sort because some more code opens up and begins executing, but There is no dissassembly for it. I wonder how the memory dump and Dissassembly didn't have this segment of code, but search again for 7f, and this time it shows up.
My initial question is why this didn't show up on the assembler to begin with? To answer my own question: It's actually common practise to encrypt (pack) code that you don't want people to be able to read. But at some point this has to be undone in order to run the commands. So the last call before the jump is made to the secret section must be the unpacker.
I tried putting the code in the free version of IDA but ran into too many problems that probably have easy answers that I was just unable to uncover (like which version of assembly to use).
Thankfully there is a link to their assembler on the page.
The code being vast and unlabeled, My best bet is to attack at the 7F point. I see a compare for the unlock .
b490 a09b dcff cmp #0x9ba0, -0x24(r4)
0520 jnz $+0xc
3012 7f00 push #0x7f
b012 6424 call #0x2464 (the interrupt function)
This looks similar to when the password was a literal. I set a breakpoint to check the value of r4-24, and sure enough it turns out to be the start of our password, so the key should be a09b.
WhiteHorse:
Trying a long password first shows us that we overwrite 2 bytes in memory and gives us insn address unaligned. I test the Hex string 0001 0203 04050607 080910 12131415 1617183c44. We get another address unaligned and the PC changes to 1817. I replace the digits 1718 with 5c44 (the segment that pushes 7e and calls INT).
But this isn't quite right, and doesn't give us our intended result because 7e requires the password as an argument. So lets just trigger INT the way we want it.
Let's pad 16 chars, set the new return address to the INT function (4532) and push 7f where INT expects. I'll also leave 3c44 there so that the program returns there and exits normally. This doesn't matter for the challenge and 3c44 could be anything, but I'm thinking we don't want to crash the lock with an unaligned error and give away our tampering.
01020304050607080910111213141516 3245 3c44 7f00
Montevideo:
Starting with 20 chars of padding and stepping through shows us that this system is vulnerable to the same problem as WhiteHorse. So, just as before we can just call INT with our value of 7F... AND... We're in!
01020304050607080910111213141516 4c45 3c44 7f00
Johannesburg:
The info on this version says passwords that are too long will be rejected, but I can see that I can overwrite up to 64 bytes which is not far enough to overwrite code that will be running again. Something odd about this is that I don't get a unaligned error this time around. I notice an extra bit of data before the return address I have been hijacking. Searching the assembly for the value shows us that this is some kind of protection used to determine that the password is shorter than 16 characters. It also abruptly ends the program if the value is changed.
I tried 01020304050607080910111213141516 00e2 4644
but the address didn't get changed. I saw that this was due to the strCopy function which stops executing when it reaches 00, so I just replaced the zeroes with more padding and ta-da!
Well, I've captured some cool flags this week. I'll definitely pick this up at a later time when I need to train up again. Something tells me this day will be soon.