-
Notifications
You must be signed in to change notification settings - Fork 6
Challenge Ideas
Daemon listening serving as a "concatenation server". Attacker will be prompted for two strings to concatenate and return. There will be an off by one error allowing an attacker to perform an adjacent memory overflow to combine the two buffers into one long enough to overwrite eip after being sprintf()ed into a buffer.
Daemon listening which prompts an attacker for a term to look up or add an article. Adding an article has no filtering and allows for shellcode to be entered into the body of the article. Entries are stored in a linked list and provides the article number which allows for the attacker to guess the offset. Lookup contains format string vulnerability which allows an attacker to overwrite eip with the address of the shellcode in the article.
Web site where attacker can submit QR codes to be read back to them. Binary which is called contains a stack overflow which the barcodes can overflow and gain control of eip. Due to limitations of QR codes attackers must use alphanumeric shellcode in order to get execution.
Daemon. Preset Canary that attacker must enter in with their payload in order get past a custom set of canary checks.
A client and server will exist. Attackers are only given a C binary which is the client. Challenges will be taken from project euler and given to attackers to solve in js. They'll enter their code into the client through stdin and the server will eval it to check if it is a valid solution. If it is they will be ranked against other solvers which serves no purpose.
The server will be written in NodeJS and use the sandbox module to make it more difficult. The client will use ssl to make it difficult to determine what's going over the wire. The client will not inform the attacker what language is valid and they will have to reverse engineer the client to see that it's using JSON to send a js function over the wire and figure out that it's NodeJS.
A simple daemon that reads in a word from the client, runs it through a regex to bromangle it, and returns it. It will use a member of the printf() family to have a format string vulnerability inside of it that will allow the user to pull the key from memory. The key will reside on a file on disk and will be read in any time the daemon forks (libjack3d limitation). A number of %x %x %x %x %s type payloads should do the trick. Like the rest of the C pwnables, it will run on a 32 bit debian VM.
DTMF as we know it actually contains 16 tones. aside from digits 0-9 (10 symbols), there's * and # (2 more) and then A, B, C, D (4 more) that are usually only seen on lineman's handsets. But that gives us a total of 16 symbols, more than enough to take Hex output and encode it in DTMF, as you already have 0-9A-D. E would be * and F would be # via SED.
Audacity has a pretty awesome little DTMF generator built in. All we'd need to do is zip up a flag, bin2hex it, and paste that string into audacity to generate the file.
Decoding could be done using MultiMon, so if they find it, that removes a lot of the challenge.
The input file would be a ZIP file containing the flag that would be using weak zip encryption they'd have to crack. Suggested pass: thegrid
The final artifact would be a FLAC file of the DTMF tones to prevent lossy codecs losing data.
PDF with a statement from sabu snitching on other lulzsec members and activities. Have a bunch of redacted portions of the pdf. Hide the flag in one of these sections. CTF quals had something similar maybe 4 years ago where it was covered in a black box. xpdf, and not many others, allowed an attacker to select, copy, and paste a redacted area. This is a little too simplistic for a 200 point but we could swap it with 100 or come up with something more challenging.
32 bit Linux binary that checks for ptrace attach calls being made. If ptrace attaches to the process it sets eip to a random location in memory causing the application to hopefully crash. Should probably add a bit of obfuscation in addition to make dead code analysis harder. The flag will be algorithmically decrypted in memory so that it's not possible to just run strings and get it. They'll have to patch the binary to stop/ignore the check and cause it do the full decryption then read it from memory. We'll stored the string "FLAG" or something similar a few times before and after the location where the flag is decrypted to to make it obvious once they actually get this far.
Using the recent MySQL vulnerability, build a web service that allows you to login to view keys. Hide the un/pw in the comments or something like that. (don't need it to be injectable.) Once you login, it will give you a search utility that contains a process execution vulnerability. From here, you'll need to exploit an older MySQL binary to gain root access (See this post for PoC) and set your account to admin. Then refresh the page, and get the key. Ideally, they key will not be contained in the DB.)
Put a SQL injection in the first factor, to get a username/password.
Give them a dump of cookies with timestamps and sequence numbers that are time correlated. This way, they have to predict the sequence for the time, and then use that as their secondary factor.
To input the secondary factor, the user will have to predict the sequences. We'll set a cookie, with the wrong value and they'll have to edit it manually.
Remove the extra polarizer on a monitor with a QR code in the QR code, encode the flag
Very simple, write out a URL in UV reactive ink. The URL will spit out a JPEG that is progressively encoded with some random data stuffed near the beginning. The JPEG file will have a key encoded in the bitmap. (Like last year's 500 pt challenge.)
Build 8 devices to hang on the walls throughout the room. Each device will display 2 hex characters. Each display will be a port number. The correct sequence of these will be used to Port Knock a service running over an IRDA ethernet network.
The node with the IRDA hardware will be responsible for having 2 interfaces. one primary, one aliased. (can that even be done? FIND OUT.)
The primary will have the DHCP server listening to dole out networking information. The secondary will be secured with knockd and the correct sequence will have to be given before the service will open up.
In the DHCP packet, the next-server option will be populated with the IP of the system they need to knock. If they're not paying enough attention on the wire, they'll never find it.
Once it opens up, you'll have to NMAP to find the service that's listening. The service, upon completing a handshake, will spit out a base64 encoded PNG of a QR code. The QR code will be encoded with the key that they'll need to enter into the challenge board.
If aliasing and DHCP don't work with IRDA, We could make the plastic boxes give an IP and sequence in O1,O2,O3,O4,P1,P2,P3,P4 format. So they'll get the codes from the boxes, we'll set up the hint as something like "Knock, Knock, neo.." and then give them a network number. Like 10.3.0.0/24. (That will be the IRDA network) My T40 running the IRDA port will have a screensaver on it with some rotating pictures depicting things like: the IRDA logo, a remote control, the BroCTF logo, etc. So it will be at least slightly more obvious what to do with this challenge.
Once the knock the IP and get it open, they can port scan to find the listening service, and the rest of the challenge works as above.
Build a RAID5 in software out of 3 loopbacks, each about 200MB in size. Assemble it, use ext4 to format the filesystem (volume name: brometheus). Then what we do is divide a key in half. Open vim, edit a file with half of the key called flag.txt. VIM will create a swap file. kill -9 that process, swap file (.flag.txt.swp) remains. Now, edit a new file (problem.txt) with the last half, save the file and exit normally. This way, the file on disk has half the key, and the other half is encoded in the swap file. All you need to do is touch flag.txt and edit it and choose recover from the options.
Now, unmount and then only give out TWO of the three RAID devices. Users will have to build the array in degraded mode. There's also a dummy filesystem with a /dev/loop0 that they can mount with a key.jpg file thrown in for decoys.
The finished artifact is a 20MB tar.lz file.
Scrape brotips.com, put into DB4 table. Use the bro tip ID as the key, and the tip as the value. The key will be one of the bro tips somewhere in here.
Zip that DB4 table up, make a blob, put it into a Postgres database, with blobs of other various Bro JPEG's.
TBD: how do we corrupt the PG DB to have it still be recoverable?
Think 300 n,8,1 by Information Society. I think I have a couple modems I can ATA/ATO together to make this happen.
Current thoughts: Connect up two modems to my old machine that still has 2 physical COM ports. Use one of those RJ11 splitters and two pieces of RJ11 patch to connect the two modems together. Plug the male end of the splitter into my old beige box that happens to have an audio output jack. Said jack should be wired into a recording device.
From there, open up two different minicom sessions, and connect each to the other's modem. remember to use 300/n81!! With the recording device switched on, type ATA in one terminal and ATO in the other. That should cause them to connect, eventually.
From here, it really doesn't matter which terminal you use, but pick one, and start pasting in the key file multiple times. This process is really shitty on the decoding end, so you have to give them a few tries in case the string gets corrupted.
Perhaps then paste some ASCII art as well for great lulz.
Once that's done, stop recording. Bring the file into an editor, and downsample to something like 16Khz, 16 bit, mono. The final artifact will be a FLAC of said recording. (Any lossy codec may destroy this!)
Recovery is much the same as encoding, save that you'll need to inject the audio into the already connected modem's.
Dubstep or fistpumping WAVE file. STEG'd with an MP3 file of us reading the key aloud, as bros dude!
Give them the encoder binary, ARM linux, make them write a decoder based on it. Decoder will be a bribe, also a ARM binary. maybe PPC32, if the endianness works out?
Binary will have a few things to defeat strings, such as a big brofistpump in ASCII encoded in as a function somewhere. Maybe some other obfuscation techniques?
Pingtunnel download PCAP of doom.
Capture on a busy network with a lot of other ICMP packets going out. Traceroutes, pings, etc. Redtube stream of the nastiest stuff you can find.