This repository has been archived by the owner on Jun 9, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 8
/
Copy pathconcepts.txt
126 lines (119 loc) · 12 KB
/
concepts.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
* = complete with solution
+ = challenge written, needs solution/writeup
-- PHYSICAL --
100 - Poor Man's 2FA - You're presented with two combo keyboxes tha tare shackled together. One is a 4 dial combo style,
the other is a push button lock box. Both are easily decodable with no tools required. All information on how to decode
them is easily found on YouTube. Inside each box is half the code, so both boxes must be decoded and opened to successfully
get the flag.
200 - Shall we play a game? - You're presented with a box. It's got a number of toggle switches, colored buttons, a keypad,
small LCD screen, and two tubular key locks. You're also provided with what looks like a partially redacted document. The
idea is that WOPR decided to go ahead and launch a nuclear weapon. The document describes the steps necessary to abort the
launch. The buttons and toggles will be variations on requiring the correct secquence to be set. The final step of the
challenge requires two keys to be turned simultaneously. However, only one key is provided. A tubular key cutter and
blank tubular keys will be provided to the participants and they will have to figure out how to duplicate the key. If
they can successfully duplicate the key and then turn both simultaneously, the nuclear launch will be aborted and
the flag will be displayed on the LCD screen.
300 - Forgot My Password - You're presented with a rotary telephone. Attached to this rotary telephone is an RFID reader and
a lock on the 8 digit of the dial. On the face of the dial there is a 5 digit number with the note "IT Help Desk".
When this number is dialed, an automated IT help desk system answers. There are multiple options in the phone tree,
but option 9 leads to a password reset menu. However, due to the lock, the 9 cannot be dialed. On old rotary phones,
there is a dialing technique called switch hook dialing where the button normally used to hang up the phone can be
tapped to dial numbers. By using switch hook dialing, the password reset menu can be accessed. You are then required to
input "your" employee ID number. Some of the CTF organizers will have custom RFID badges with their picture and a barcode
printed on the front. The barcode, when decoded, is the employee ID. RFID cloners and blank cards will be provided,
and users will have to covertly clone a badge as well as capture/decode the barcode. Once a correct employee
ID is entered, the system requests the user to scan their badge on the RFID reader attached to the phone. If the badge
associated with the previously entered employee ID is scanned, the password reset will be succesful and the flag will
be spelled out over the phone.
-- DATA RECOVERY --
300 - Off With Your Heads! - In order to find the flag for this hardware focused challenge you have to perform a task very
similar to the data recovery procedure known as a head swap. In a normal head swap for data recovery the technician first has
to remove the bad heads from the "patient" drive, very carefully remove the functional heads from a "donor" drive, then place
the donor heads into the patient. Since matching donors with patients can be a challenge unto itself and would require more HDDs
and more space, this challenge only requires you to completely remove the heads from the hard drive provided to you then place
them back into the same drive. What is meant by completely is that simply sliding the heads off the internal ramp won't count.
The heads have to get "air time". Someone will be supervising you during your attempt to make sure the removal is complete.
In addition to the head swap procedure itself you must fashion your own head combs (these keep the hard drive heads which are
magnetically attracted to each other from touching and rendering them incapable of reading data ever again). The DIY head combs
materials typically used by old school data recovery gurus will be given to you but you are not required to use them. If you
think something better will work- do it. Just keep in mind that HDD heads are extremely fragile. If they touch anything, they
are toast. Once you have fashioned your own head combs and think you are ready- go forth and swap. In the CTF room you will
find a table that has everything you need to make the attempt including a glove box style clean hood which will help keep major
debris from damaging the platters (disks) or heads. Someone will be at the table to assist you with using equipment and
equipment only- they will not help you with the actual procedure. When you are done with the head swap you can test to see if
it was successful on your own machine. If it was successful you should be able to find the flag. If it was not successful, the
flag is nevermore. Signs that it wasn't a success are clicking, beeping, buzzing, scratching, gurgling, moaning, and/or dead
silence (as in the drive won't boot).
100 - Gravedigger101 - So, the head swap challenge was too difficult for you. Fear not! And want not and waste not etc etc. No
reason to immediately discard an entire hard drive just because of a few bad heads. Data recovery requires the use of all the
components of a hard drive, and we tend to recycle our donors only after we have harvested all the good parts so we can use them
later. Now along with head swaps, PCB swaps are another common procedure in this field. Without the ROM which is located on the
PCB we couldn't access the hard drive's Service Area thus allowing it to boot and spin, let alone allow access to user data. And
ROM capacity is just large enough to store a CTF flag..so that's what we did! The challenge will require you to first figure out
that you aren't quite done with the HDDs post-head swap. You will be prompted to visit the "data recovery graveyard" where you
can dig through the dead HDDs from OffWithYourHeads! as well as an assortment of other PCBs and HDDs from various manufacturers.
Though the graveyard will contain many different brands/families of non-functional HDDs as well as functional/non-functional PCBs
they will all share something in common- the ROM chip can be desoldered. Once desoldered you will have to figure out a way to
dump the ROM. We will have USB MiniPRO TL866CS Programmers (x2) as well as USB to TTL CH341A EEPROM programmers (x2) available
for use to create a ROM dump and find the flag. The programmers will be labeled with "Gravedigger101". Both the MiniPRO and the
TTL programmer will require the download of drivers. Due to the variance in ROM size of each HDD, the flag will not be hidden at
the same offset though it will be located toward the end of the ROM data, inserted just before the last "empty" space begins
with FF FF FF FF.
-- PWN --
100 - rot13 - You're presented with an x86 Linux binary. The binary is compiled with NX, PIE, and stack canaries all
disabled. You are prompted for input, then the program performs a ROT13 on the input, and finally prints back the result.
There is a buffer overflow on the input, as more bytes are read than the allocated buffer size. The problem is, the input is
modified by the program (each byte is incremented by 13), so the payload must be modified in the reverse (each byte
subtracted by 13) before sending it to the program. The actual payload is simple, as it can just be shellcode with a gadget
to jump to it.
300 - pwnchess - You're presented with an x86-64 Linux binary and a copy of libc.so running on the remote
server. The binary is compiled with all default anti-exploit mitigations except for PIE. The binary allows the
you to peform one of three operations; read one byte at an arbitrary, write one byte to an arbitrary location,
or exit. The catch is that you are allowed to perform only 2 operations. So first you must write a larger value to the
global variable, moves, memory address. Next, you will have to leak the libc address by performing multiple reads to
an address from the GOT section. Once a libc address is leaked, offsets can be calculated using the provided version of
libc. Then, you use the free leak the application gives to the stack to calculate the address on the stack where the
return address is read from. You can finally write a ret2libc ROP chain to this location, and finally either exhaust all
remaining moves or write 0 to the moves address to trigger the ROP chain.
-- RE --
100 - Magic Numbers - You're presented with an x86-64 Linux binary. The binary will notify the user that
there are 3 magic numbers they must find. These numbers are static, hardcoded values. After each number is
entered, the binary will either tell the user that the number is incorrect or prompt for the next number.
Once all 3 numbers are correctly entered, the program will "decrypt" and print out the flag.
300 - Bad CryptXor - You're presented with an x86-64 Linux binary as well as an encrypted file. The program used
to encrypt the file is a pretty simple XOR cipher, however, the file is hidden behind a password-protected, custom
cryptor. So the user will have to unwind the cryptor or use a debugger to reveal the embedded 2nd binary.
-- MISC/FORENSICS --
100 - [Challenge Name] - [Challenge Description]
200 - [Challenge Name] - [Challenge Description]
300 - [Challenge Name] - [Challenge Description]
-- WEB --
100 - Signed, Sealed, Delivered, I'm Yours! - You're presented with a register/login page. You can register
and login to accounts. Once logged in, there's a button that says "Get Flag". If you click it, you'll get an
error saying you're unauthorized. The solution is to modify the JWT stored in localStorage and modify the
admin claim to be true, and change the signing algorithm to none. Since the server doesn't verify algorithm,
it accepts the none signing algorithm, and accepts that you're an "admin". When you hit "Get Flag" with this
crafted JWT, you get the flag.
200 - Yours truly - In this challenge there is no frontend at all. Instead, all that's given is the
path to an OpenAPI document on a backend. This doc outlines an API for a service that returns Hackers
characters, paths to images, and presigned URLs to those paths. You notice in the OpenAPI document
that there's a commented out portion for a header called X-Debug-Characters. You expose an nginx
server to the internet and pass it's URL in that header. You see a GET /users request, so you
configure nginx to respond with a JSON blob that looks similar to the original backend response but
with just the paths and names (no presigned URLs). You now see the backend is presigning whatever
paths your server returns. You look again in the OpenAPI documentation and see a default value for the
path in the response of a random UUID. You try returning this path from your fake server, and get a
presigned URL for it. You go to the URL and an image containing the flag is returned.
300 - Hell.js - You're presented with a login page. You don't have a username/password and no SQL injection works.
After noticing the backend responding with X-Powered-By: Express, you assume it might be using MongoDB. You end up
searching around for common MongoDB vulns and find MongoDB injection. You pass {"$gt": ""} to the server for the
username and password and are able to login. You are now greeted with a table of items that allows you to search
via queries formatted like "return false;". You can also see that the browser is making requests to a different server with
the endpoint `/flag`, however this server is always responding with 403 Forbidden. You look at your JWT and see
that a claim named "get_flag" is set to false. You try setting the algorithm to "none" like the 100 challenge, but
no dice. You move on to looking at the table since you're not getting anywhere. You try another MongoDB injection,
but it doesn't work since the server is using an explicit query selector this time. Instead, since the query looks
like Javascript and you think the server is running Node, you craft queries like this to exfiltrate the JWT secret:
`customer.gender = JSON.stringify(process.env); return true;`. Since you know the JWT is signed with
HS256 from inspecting it in jwt.io you use the secret to sign a version of your token with the "get_flag" claim
set to true and make a request to the other server with the flag endpoint. It returns the flag.