The link below will take you to a Web site which contains numerous vulnerabilities but is being defended by the Fortify Real-Time Analyzer (RTA). When you conduct an attack, Fortify RTA will block your efforts and redirect you to a separate page. However, if you conduct a particularly impressive attack, Fortify RTA will redirect you to a different page, with a code word. There are three code words available.

Fortify RTA had a tight lock on that website! I probably came up with a hundred separate attacks against their website, but they were only looking for a very specific 3. Every so often, I’d come up with what I thought was an impressive attack but it wouldn’t give me any points! Here’s one example:

I found an authorization problem when viewing account details that let me enumerate the database for and grab the account details of every client in the bank. I used Burp Intruder to automate harvesting this data, making over 10,000 requests to the server to gather the info. Then I manipulated client-side parameters on the ‘transfer funds’ page to steal money from other clients and deposit it into my account. This wasn’t an attack they were looking for and didn’t get me any points! Grrr..

I took screenshots of all the actual attacks below.

You had to recognize that they set an AuthType cookie when you logged in. Changing this cookie to 0 let you view and access a hidden admin panel.

Once in the admin panel, RTA triggered on a command injection vulnerability:

… and on cross-site-scripting the other admins:

The last attack was a SQL injection on the account details page:

My biggest problem was that I overthought the attacks they were looking for. Once I calmed down and stopped trying to become a millionaire/root-shell-0wner I realized they were probably looking for the basic web vuln trifecta: command injection, xss, and sqli. All in all, a really fun challenge. Thanks Fortify!

The level 1 challenge was a binary that asked for input and, if your input was correct, printed out an e-mail address you could use to get the level 2 binary. The Khallenge is a contest of speed, so the first person to get to and beat level 3 wins. Unfortunately, I solved level 1 after the contest ended and the level 2 and 3 binaries aren’t online yet, so no prizes and no info on those.

The first thing I did was open the binary is a disassembler and try to get a general feel for it. This would help me develop an attack strategy. In IDA, you can easily identify that your input is being XOR’d almost a dozen times and with a global variable somewhere. It quickly overwhelmed me, so I took out a pen and paper and started writing things down. I also had lots of problems identifying exact addresses and byte offsets in IDA (I haven’t used it much before), so I switched to Immunity Debugger at this point.

The first set of instructions your input needs to pass through are at addresses
69001081 to 6900108F, and it turns out they are a compiler-optimized strlen function. Pseudocode for these addresses looks like this:

if(strlen(input) != 4)
    fail();
else
    ...

The XORs start immediately after this check. After staring at it for a while, you will figure out that your input is being used as a key to decrypt a global variable located at 0×690030D0. This global variable becomes the answer e-mail. I wrote out the encrypted e-mail in a column and mapped the XOR’d input bytes to it. Here is that table (encompasses addresses 69001095 to 690010F6):

e-mail @ 0x690030D4		input @ 69003100
e-mail[0]: 0x07		XOR	input[0]
e-mail[1]: 0x2E		XOR	input[1]
e-mail[2]: 0x35		XOR	input[2]
e-mail[3]: 0x29		XOR	input[3]
e-mail[4]: 0x70		XOR	input[0]
e-mail[5]: 0x20		XOR	input[1]
e-mail[6]: 0x76		XOR	input[2]
e-mail[7]: 0x68		XOR	input[3]

After all the XOR’s, the application starts to check the final values of 4 select bytes in the e-mail buffer.

e-mail[4]: 0x70		XOR	input[0] == 0x32
e-mail[1]: 0x2E		XOR	input[1] == 0x61
e-mail[6]: 0x76		XOR	input[2] == 0x30
e-mail[3]: 0x29		XOR	input[3] == 0x79

If you do the XOR in reverse, you can find out the input they are looking for:

0x70	XOR	0x32 = input[0] = 0x42 = B
0x2E	XOR	0x61 = input[1] = 0x4F = O
0x76	XOR	0x30 = input[2] = 0x46 = F
0x29	XOR	0x79 = input[3] = 0x50 = P

Run the executable, put BOFP into the prompt, all the XORs happen, all the checks pass, and the e-mail buffer decrypts to “Easy2o08.” Done!

Thanks again Aleksey and Phn1x!

Our website with descriptions of the contests as well as winning entries from previous years is located here: http://isis.poly.edu/csaw

Also to note: many of the makers and hardware hackers in this crowd will be happy to know that we have a new embedded systems challenge this year. Check it out!

I’ll talk about some of the challenges I went through, but if you’re really interested in these kinds of things you should compete in one of the capture the flag competitions that I developed for these upcoming events:

• NYU-Poly’s Cyber Security Awareness Week – A yearly event for students that our lab puts on. Compete in 7 different information security competitions for prizes! If you win, we’ll pay for you to come to NYC and collect your prize!
• OWASP AppSec NYC – A 2-day web application security conference taking place downtown this September. There will be a web capture the flag contest, also with prizes. Everyone is welcome to play and challenges will be accessible to beginners and experts alike!

Now about HOPE/Packetwars CTF…

(many details are witheld as I’m unsure whether they reuse contest images for other events)

All the challenges were time-limited and you could only play them solo. This was awesome and is something I’m considering for the CTF’s that I run (OWASP and CSAW). I wouldn’t have played CTF if I knew I was going to miss 3 days of my life but 30 minutes was easy to give up.

The CTF was split into 3 rounds where the first round was a qualifier. The objective was to find all the hosts in your network and enumerate their services. It sounds simple but some services were specifically tuned to throw off nmap and pf and tcpwrappers were playing tricks on you. Still think it’s easy? Try building new tools (who really carries around more than just nmap?), figuring out how pf/tcpwrapper are protecting the services, bypassing that protection, and then scribbling down everything you know on a 3×5 index card (yep, an index card) in 30 minutes!

I started off the first challenge without realizing that we were being graded partially based on how fast we handed in our answers. I ended up in 7th place and just barely qualified for round 2 because of that! I don’t think anyone else got more information than me, but they all handed it in faster. Oops!

The Packetwars guys hinted that the later rounds would be based on the first, so Friday night I researched a few things about OpenBSD, ssh, dig, and tcpwrapper that might (did) help me out the next day.

That worked great, because round two was a .NET web application (a shopping cart) running on Windows. They gave us no direction and just told us to find the hidden codes inside it in 1 hour. “Awesome,” I said, “my day job is spent doing web security testing, I am going to blow everyone out of the water on this one”… The freakin’ app had Fortify Defender (a Web Application Firewall) in front of it and it caught every code injection, SQL injection, and session manipulation attack I tried! I figured they must be asking us to look for logic bugs, leaking credentials in the comments (gasp!) or something else lame like that. 2 clicks later, I used WebScarab’s “Fragments” tab to find the administrative credentials. Go me for thinking like a CTF developer!

So now I’m hard at work on the admin interface trying to steal money from other users and trying to buy things with my ill-gotten funds, reading other user’s shopping carts, and locking out my competitors. I tried to violate every single item in their security model. Some of it worked, most of it didn’t, but I couldn’t find those codes! In my last act of desperation, I started fuzzing every variable I could find with Burp Intruder. Time ended up running out and I never found anything, but luckily no one else did either.

After the second round was over they explained that all they wanted us to do was XSS the front page o_0. WHAT!? Who was there to XSS!? Ourselves!? Sheesh, I really overthought that one. I blame Erik for only teaching me how to 0wn the living daylights out of web apps (no cursing on the blog ). When they started looking through packet logs, they unanimously decided I won that round.

Round 3 was back to OpenBSD and was very similar to Round 1. The objective was to gain access to as many of 3 machines you could and to maintain that access. We had 2 hours. Since this one was a little longer and a little deeper, my explanations are abridged.

Problem #0 – There was a firewall between me and the targets and it wasn’t making it easy to even find the hosts. This resulted in lots of panicked mashing on keys and liberal use of the command history but I got around it soon enough. Bigger problems followed.
Problem #1 – All 3 machines were recent versions of OpenBSD (3.9+) which meant no scalp exploit and no sshutup-theo exploit.
Problem #2 – All 3 machines were running on Sparc which meant that, even if they were vulnerable to CORE’s mbuf exploit or mod_ssl’s SSLVerify_CRL() vulnerability, there was no chance I’d ever get working shellcode, especially not in 2 hours without a test platform.

So I gave up on ever getting remote code execution. How familiar that it was down to misconfigured services and weak passwords! Some services were still messing with nmap, but that wasn’t a problem since I had amap and a few protocols memorized for netcat. One or two services were tcpwrapped and played the same tricks as before, but I couldn’t seem to find the correct IP to authenticate with and those services remained inaccessible to me throughout the round. I used DirBuster to attempt to identify usernames on host 1, used dig to do a zone transfer out of host 2, and used the [previously unknown] DNS name for host 3 to talk to its FTP server. The FTP had a 15 second delay before displaying a USER prompt, so brute forcing it was impossible. The only other service I had to brute force was SSH, so what the heck, I went after it. I used 6 py_sshbrute threads to brute force the passwords for “root” and “hacme” (their domains were *.hacme.com) with john’s password.lst. It was right about this time that someone with Nessus managed to crash the SMTP, POP3, and HTTP daemons on a few of the hosts. SMTP and POP never came back up AFAIK (note to CTF developers: always have a console on your vuln box during the contest!).

It was now about an hour into the round and, as I was flailing about trying random attack after random attack, I took detailed notes on my index cards about what I had done so far and why. I didn’t think anyone else was going to get a shell on any of the boxes unless they got incredibly lucky and I thought the index cards would determine who won. Another 45 minutes went by and I discovered a few more things but nothing that gave me a shell. I spent my last 15 minutes writing down an epic 0wn strategy I could have tried had we been given more time.

Time ran out, no one got any shells, and they used the cards to determine the winner combined with weightings from Round 2. It pays off to carefully listen to and follow the rules .

After they announced the winner we all sat around in a circle and discussed the challenges. One of the guys from the Packetwars team actually told me, “We were running an old, almost 2 years old, version of OpenBSD with remotely exploitable services!” I’m sorry guys, no one is dropping fresh exploits or giving you big-endian shellcode for your CTF . One guy also fessed up to running Nessus and bringing down said services heh.

Tools I used at some point: DirBuster, py_sshbrute, bash, Brutus, dig, w3af, THC-AMAP, netcat, john, Burp Suite, WebScarab, my brain, maybe some other ones…

All in all, I had a fun time and I would absolutely play in Packetwars CTFs in the future. Even though nothing was as epic-ly hacked as I wanted it to be, the time limits and varied challenges kept me from getting too frustrated. I was able to take away a lot of little techniques that I’ll be able to integrate into my own CTFs in the future. Thanks everyone!

If you made it this far, let me reiterate: play in the CTFs that I run! OWASP AppSec NYC CTF and CSAW CTF are both coming up in September.

On another note, I wasn’t the only one who won it big this weekend. Former ISIS member, Michael Aiello got a video interview on CNET news about his RFID-blocking apparel! Check out the video, he is wearing one of our shirts from HOPE 6 .

“Michael Aiello, president of DIFRwear, demonstrates at Last HOPE how easy it is to swipe the data off someone’s RFID-enabled credit card, building access badge, or passport from a few feet away. DIFRwear sells wallets and cases to protect cards from data thieves.”

I had a very, very quick talk with someone at NYSec tonight and we highlighted the Social Responsibility panel at Shmoocon that wrapped it up as one of the biggest letdowns of the weekend. It’s a panel that should symbolize all the hopes and dreams our entire community wants to accomplish but instead time was wasted debating the meaning of the word ‘hacker’ and what constitutes “our” “community”. I think Toby summed it up best when he threw a Shmoo Ball and said (paraphrasing) “We’ve debated what the word hacker means for 20 years and we’ll do it 20 more. We need to move on to talk about more important topics.”

Toby is exactly right, but his comments didn’t prevent the conversation from getting derailed again just a few short minutes later…

I’ve met Johnny Long before (at an Apple Store in rural Maryland, don’t ask) and I really like the guy. He exists at the fringe of our community: he’s not a security manager and he’s not very technical, but what he does is impressive. He gets tons of money and publicity through this No Tech Hacking idea that he practically has a monopoly on and uses the money to take trips to Africa to set up technology infrastructure. That’s his angle. Basically: “We have opportunities that allow us to become computer security professionals and fly and spend money coming to these conferences, but there are starving children in Africa for god’s sake!” He’s even gone so far as set up a charity – Hackers for Charity – to do more of this kind of thing.

And you know what: that’s great, good for him and even better for those kids in Africa, but… starving children in Africa are everyone’s problem, not just the computer security community. You don’t need computer security specialists to feed children in Africa, anyone can do that, and a lot of us choose to do this on our own time. However, not anyone can solve security problems, only we can do that. The rest of the world needs us to do what only we can do, we have a duty to the world to be the best at what we do, and our own community needs us to solve internal problems that threaten to tear us apart.

Want to see what I would have rather we discussed? Check out Bruce Potter’s “Dirty Secrets of the Security Community” talk from Defcon 15.

This is the second time I’ve felt like this (the last time was after HOPE). I can’t sit here and complain anymore. If I disliked the presentations so much at ShmooCon, then I should present something myself to make up for it.

Who’s with me? HOPE/ISIS Con ‘08!

Unknown to many amateurs, computer forensics is extremely difficult and goes beyond simple technical problems. Have you ever heard of the Best Evidence Rule? Do you understand the rules surrounding Expert Witnesses in court? No? Then you shouldn’t be collecting evidence for use in a trial. Computer forensics is not as simple as picking up your favorite tools, whether it is standard like TCT or your own set of shell scripts, and applying them to your clients hard drive. Doing that is a perfect way to completely sabotage a trial and get yourself into serious legal problems (tampering with evidence).

Licensing computer forensics practitioners legitimizes and standards it into a profession. It allows others to recognize and respect us and to trust our ability to gather evidence. The problem lies in the execution. I’m not intimately familiar with PI licensing, however I’ve heard it requires things like years of training and a mandatory apprenticeship. I also don’t know specifically what activities these proposed laws restrict.

Ideally, we’d want a license that isn’t overly difficult or time-consuming (as learning computer forensics isn’t overly difficult or time-consuming) and one that doesn’t apply to situations that won’t end up in front of a jury at a later date. Congress should not be able to legislate what I do with my own or my friends machines. As long as those above topics are respected, I see licensing of professional computer forensic investigators as a positive move.

Someone prove me wrong.

Crouching Powerpoint, Hidden Trojan: An analysis of targeted attacks from 2005 to 2007
Presented by Maarten Van Horenbeeck of the SANS ISC at the 24th Chaos Communication Congress
http://events.ccc.de/congress/2007/Fahrplan/events/2189.en.html

See the links at the bottom for presentation materials including a PDF, video, and analysis of actual targeted exploits. I highly recommend the video, the torrent was extremely fast.

Enjoy