Announcing The Matasano/Square CTF | Hacker News Reader

Announcing The Matasano/Square CTF

matasano.com

297 pointsalepper72 comments

Go easy on us for a bit; this is a fresh deploy in a new environment and it's bound to be janky. The odds of it not completely asploding tonight are pretty low.

Happy to answer questions.

One obvious question we haven't answered: how long will it be up for? Answer: a'unno. Until it gets boring? Or super expensive? We're in no rush to shut it down. I've never understood why awesome CTF events are so eager to shut down.

Here's what it looks like:

http://twitter.com/tqbf/status/423992147155509248/photo/1

We're on Freenode #uctf if you want to bug us live.

In case you're interested: this is a very small Rails app talking to an emulator we wrote in Golang that exports an HTTP/JSON interface.

This looks cool!

> I've never understood why awesome CTF events are so eager to shut down.

We actually were planning to leave the first Stripe CTF up indefinitely. We'd mostly just built it as a side project, and hadn't really expected anyone to take notice. But we were swarmed by thousands of users, and suddenly keeping everything running was a full-time job — Andy wrote a script to alert us to forkbombs, and every hour or two we'd have to go in and clear out the forkbombs from a machine. The runner for level5 would get wedged due to an exploit that hung it, and would require kicking. One of the machines would be overloaded with level6 password bruteforcers, and we'd have to spin up another or kill off runaway ones.

For the second CTF, we at least knew what we were in for and built a much more resilient architecture. It was successful in that it was much less work to maintain, but there still was a lot of maintenance, ranging from working around an EC2 security groups bug that would blackhole traffic from certain client IP addresses to spinning up more level2 boxes (since everyone was overloading them in their attempts to bruteforce the level8 passworddb).

Anyway, my tl;dr is that running any production system is hard, and we couldn't have kept them running without significant time investment.

In other words, "we're going to keep this site up for a long time" sounds like famous last words to you. :)

On the other hand, we're a security consultancy, so maybe we have lower, more tolerable standards for "up in production" than Stripe does.

Nelson Elhage is a machine; he ripped through 9 levels in under an hour.

Yep, pretty much :).

Also, fun fact: Nelson was our test solver for CTF2. He also ripped through all the levels there in a few hours. But then he got to level8 (PasswordDB, which was source port counting), and was stumped for a few days. He had a lot of hypotheses about the vulnerability, many of which were much cooler than the actual one. Given it had taken him so long, I decided the level was too hard and made it easier by adding some code that would log source ports. (It turned out to still be too hard, so launch day I released a bunch of hints until finally wgrant solved it, at which point I went home and got some sleep.)

Is there any place to download the code or the image to the original Stripe CTF? I would love to replay it again.

Yep: https://stripe.com/blog/capture-the-flag-wrap-up.

I also recently learned that someone packaged our second CTF: https://github.com/e28eta/stripe-ctf-2.0

Enjoy!

I won one of your Launchpads at CSAW -- it seems that was just a teaser to this challenge. I'm having lots of fun so far!

I like the references to "Cy Yombinator."

Does this mean the matasano crypto challenges are over/no longer available?

I sent an email last week to join, but haven't heard back yet.

Nope, but it does mean I've been a little slow about them this week.

Can someone explain what "cmp.b @r13, 0x2400(r14)" does, and/or how I would find out myself?

I looked through the manual and saw the instruction 'cmp' tests the two parameters for equivalence, but I don't see 'cmp.b' anywhere. I found the TI manual for the instruction set which happens to say something about '.B' being a byte operation, but I'm not sure if that's related.

The tutorial explained that @r13 uses the value in memory for the address in register 13, but '0x2400(r14)' is really confusing.

I was thinking it just meant register 14, but that doesn't seem to be the case because the comparison fails when r14 (which is the value 0x0000 at this point) and @r13 match. I thought it also could mean the literal value '0x2400', but the comparison still seems to fail when it should match, and that doesn't explain the r14 in parenthesis at the end of it.

0x2400(r14) is an offset syntax. Take the value in register 14, add 0x2400 to it, and look up what's in memory at that address.

Awesome, thanks :)

The .b means the instruction operates on a byte, not a full 16 bit word.

Bit late, but what does "cmp #0x7669, 0x0(r15)" mean on level two? I assume it's the same syntax for the second part (offset) but is the first part the constant value 7669?

It's 7669 in hex.

I'm not sure if this is the manual you're referring to, but I've found this [1] very helpful. This point is under the section "Byte and word issues".

[1] http://mspgcc.sourceforge.net/manual/

Does it say somewhere that this is targeting an MSP430, or did you just recognize it? I thought it must be something with a real compiler targeting it, but I couldn't figure out what it was...

In any case, thanks for the link!

Crap, I'm an idiot - there's a manual at https://microcorruption.com/manual.pdf that talks all about it.

PSA for people like me who aren't security specialists: "shellcode" (in the survey) does not mean "a shell script", it means this: http://en.wikipedia.org/wiki/Shellcode

Yeah, I think that question should have three options for answers:

   [] Yes
   [] No
   [] I had to look shellcode up on Wikipedia

(I'm with you in that last category.)

Oops, count me among the ignorant. I wonder if I can correct that questionnaire.

I've worked a lot in assembly, but never tried to exploit anything before. This is like crack.

I've always been meaning to try out a few public problem sets of this sort that a couple university security courses publish. Theirs are often based on a VM image with various binaries inside them that you are supposed to exploit. While those would probably have the advantage of being slightly more relevant to my everyday work (since they're running a Linux OS/environment more like the one I regularly use and program for), this contest makes it much easier to get over the hump of setting everything up, and of course the points/competition aspect is highly motivating.

Nicely done. :)

I used to jump at hacking challenges in high school, blowing off homework and in the summers staying up til 5am.

Nowadays I see these and I have to practically tie myself to the ship's mast to not drop everything I'm doing and sink days into it. I couldn't resist with Stripe's CTF but had to quit after I got busy. This one's especially hard because I love tinkering/building embedded devices.

I guess the point is please, please keep this running as long as you can so I can have a crack at it when I'm not working day and night =].

During the tutorial, it seems like the memory dump goes blank for me (it loses its scroll bars, and loses its contents) -- http://i.imgur.com/ta9iykd.png

This is Firefox 25.0~b1+build1-0ubuntu0.12.04.1, on Ubuntu 12.04. I'll try it on something more modern when I get home.

Looking forward to it!

Additionally -- on the first "Yay!", I don't get the nextlevelbutton (which seems to be what it wants me to do next); gray_bg and youwin_outer remain display_none. I have to go manually put them in place in order to proceed on.

This looks like it will be a lot of fun, though.

Thanks for this. We're looking into it now. You can also mail us at support@microcorruption.com.

FWIW, happens with the second "Yay!" as well.

Thanks for making this!

We think we fixed this now.

I had everything arranged vertically until I reloaded. I think they're being slashdotted.

The lock (fake) manual is available here:

https://microcorruption.com/manual.pdf

Cool! Notably, it appears that it is based on TI MSP430, which is a real CPU with its own instruction set. At first I thought they had invented their own ISA, which would have been crazy.

MSP430 is a remarkably elegant instruction set. Wikipedia has a good summary: http://en.wikipedia.org/wiki/TI_MSP430#MSP430_CPU

Well, let's just say it's an architecture Square knows well. :)

That has less to do with it than the fact that it was the smallest ISA I could find that GCC would readily compile down to.

I would have loved it to be some old ARM ISA to use it as a testcase for Avatar[0]. On the same topic, FIE paper may be an interesting reading for msp430 lovers[1] (but it needs source for symbolic execution, so doesn't directly apply here).

[0] http://www.s3.eurecom.fr/tools/avatar/

[1] https://www.usenix.org/conference/usenixsecurity13/technical...

In particular, Square's credit card readers use an MSP430 chip to encrypt the stripe data before passing it on the phone.

Their first credit card readers were entirely analog devices, which were very easy to use to skim cards.

Hopefully the latest batches have per-device unique keys (based on some centrally-known KDF) so a compromise of one doesn't re-enable such an exploit.

Just so I can be super clear here: none of the code in this challenge has anything whatsoever to do with anything Square ships. We deliberately made things less realistic to make the levels more fun, and easier to ramp up with.

Hopefully the latest batches have per-device unique keys (based on some centrally-known KDF) so a compromise of one doesn't re-enable such an exploit.

Yes, that's how it works.

I encourage anyone who's avoiding taking part because they don't know assembly or reverse engineering to at least give the tutorial a try, you might just surprise yourself!

Having not really touched assembly that much before, I found the tutorial to be an excellent introduction. I'm now battling with level 4 after thinking I wouldn't even get past the first level.

Great work Matasano & Square!

Dean Pelton: Agnes, cancel all my appointments.

Agnes: What appointments?

Dean Pelton: ...Wishful thinking.

Damn. There goes my weekend.

Yup. There went my evening.

PWNED! I've never been one to shout at my computer, even in multiplayer games, but I've been doing plenty of yelling over here, and a few victory dances too.

This is AWESOME, thank you for putting it together. This should be mandatory training for developers in languages with no bounds checking. It's downright scary how easy some of these exploits can be. Yes, I know x86 makes things more complicated, but I had no idea the basic concepts could be so simple after reading disclosures about buffer overflows, stack smashing, and other spoilery stuff I won't mention here. Working on Algiers right now.

Minor bugs: I like to hit "enter" in the debugger to keep single stepping, but every now and then the focus disappears from the input window. Typing "s" works because it seems to jump back to the window, but typing "enter" does nothing.

Several levels produce garbled text from puts() -- doesn't affect the playability, just looks funny. Or maybe you fixed that already, I'm not able to reproduce it now.

It would be nice to be able to copy/paste from the memory dump to the disassembler without having to trim the other columns off first.

And the cherry on top: remember my "hide box headers" setting. Thanks!

Thanks! If you look closely at the requests we're generating, it's pretty easy to see how to get direct access to memory and to the disassembly. Just don't abuse it.

"Never printed on paper."

https://microcorruption.com/manual.pdf

FYI - On level 3, the "okay" button is obscured by the page footer, and can't be clicked on one of my machines. Scolling down doesn't help, the button remains obscured by the page footer which scrolls with the page.

I got around this by zooming the page out in Chrome, in case anyone else is having trouble.

Use a bit of javascript to press it for you? Maybe that's part of the puzzle !

And then it turns out that this was a massive Mechanical Turk.

Possible bug in the score board:

In most cases, it won't let me see the scores for levels that I haven't beaten yet. Presumably this is because seeing the input size and min cpu cycles would be a strong hint about how to solve the level.

However, when viewing a particular user's profile (e.x. https://microcorruption.com/profile/294), it shows their completion stats for the level you are currently on, despite having not beaten it yet. The levels after it are still obscured, though.

Yup. This is fixed, but won't be deployed until later tonight; we don't want to disrupt the site right now.

If anyone is worried about participating because they don't understand this domain very well, don't be. The tutorial is very useful, and the interface is generally very nice. Check it out.

This is embarrassing, but... I'm totally stuck on puzzle #2 (Sydney) since the cmp doesn't seem to match up with what's in memory, and I bet that the puzzles won't get any easier from here! Is there a good resource, trove of documentation, or excellent book for those of us who would love to learn how to do this stuff? The tutorial great, but it was definitely pretty basic.

Me too! I must be missing something...

Hint: http://en.wikipedia.org/wiki/Endianness

Not sure if anyone is still checking comments or not. I'm completely new to reverse engineering, ASM, etc. Looking at the cmp statements I tried the changing the endienness of the address being compared, but I still am not seeing that address. For example, when looking at 'cmp #0x3866, 0x0(r15)', to me this means add 0 to the value of r15 and look up the value at that address and compare that to the value at memory address 0x3866. So I'm changing the endienness of 0x3866 to 0x6683. Is this the correct thought process? Thanks.

It's been a long time since i've written any asm, but I just did this. You're almost correct; 0x3866 contains 2 pieces of information, 38 and 66. so you should end up with 0x6638

http://mspgcc.sourceforge.net/manual/x147.html helped me with this.

Thank you. I came to this thread for this.

Encountered quite some bugs with FF (Aurora here), most prominently the highlight wasn't updated when I moved a step forward.

Suggestion on top of that: It would be really nice to grab the whole 'firmware' and dump it to a local .hex file. If that isn't allowed for obvious reasons/by design: Fair enough.

I put my credit card number in, and it didn't give me an account. Did I do it wrong? Why isn't there a padlock on the signup? Ohh nooo...

I was all excited with myself for passing the first one after the tutorial and then couldn't get past the second...though I've been drinking.

This is very cool and I think would be "even more awesome" if there were a separate version that provided a tutorial for the skills required for each level.

For us 'tards. :P

This is fun. For those looking for more details on the instructions and addressing modes, check out the MSP430 User's Guide:

http://www.ti.com/lit/ug/slau049f/slau049f.pdf

I went through the tutorial. Seems very cool. Disappointed that "password" worked though - I thought it would show me how to read the value my input was compared to instead of just matching the string (and lucky guessing).

Funnily enough, I had to refresh once or twice during the tutorial, and I started realizing that it was checking it against a known number (9). Your input wasn't really compared against anything but its length. It took me a good minute, but I figured that out before it told me the password. (because of the tutorial)

This is awesome, I'm having a lot of fun reactivating my assembler knowledge.

Also, I want to compliment you on the interface, my laptop broke yesterday and I'm doing this on a borrowed Acer A500 tablet without any serious problems.

As someone completely inept in this niche, I'm looking forward to the results. I hope you share them. You'll probably have to dumb them down for us commoners.

Go through the tutorial at least. It's quite a good tutorial in the concepts of simple reversing (I'm just starting to learn a few things in this area)

This is great. I hope at least the UI is open-sourced at some point - it's really clear and it'd be good for other reversing tutorials.

Just did the first one. This is a lot of fun. Great work!

This would be a great way to crowd-source the cracking of a digital lock ... I hope you're opening the warehouse that contains all the NSA's secrets (every HN story has to have comments that reference the NSA or they'll be thrown into the dead-pool).

No it wouldn't.

Reply on news.ycombinator.com