Sunday, September 17, 2017

CSAW CTF 2017 - Write-up

CSAW CTF 2017 - Write-up

Challenge: Misc, Serial

This challenge had to do with Serial, just like it’s name.
This is what we get when we connect to the server:
You can already guess that it has to do with parity checking. When you research 8N1 Parity, you’ll learn that the format is:
START_BIT, DATA(byte), PARITY_BIT, STOP_BIT
We’re asked to evaluate the data and respond with 1 or 0.
Even parity is explained pretty well here http://www.globalspec.com/ImageRepository/LearnMore/20157/parityc189996e759b44a7ae14aa7d36630839.png:
Basically, you want to end up with even amount of 1’s. If your data contains three 1 bits then you need 1 as your parity bit. If your data contains eight 1 bits then you need 0 as your parity bit.
We’re asked to respond with 1 if parity bit is correct and respond with 0 if parity bit is incorrect.
I used pwntools and binascii to implement my solution.
It looks something like this:
First my checkparity function is defined, which will tell me what I need to transmit back to csaw server (either 1 or 0).
I make a connection to the server then read the data (All 11 bits). I send the data to my checkparity function.
Checkparity will look at only the byte value (actualdata) and parity bit. I also count the number of 1 bits I’ve received.
If I have even number of 1 bits then parity bit should be 0, if I have odd number of 1 bits then parity should be 1. If that isn’t the case then I have bad data and I retransmit 0.
The good bytes can be converted to ascii and that’s our flag!
This is what it looks like when ran:

Challenge: Pwn, Pilot

This was an exploitation challenge and the goal was to get a shell.
In this case, the tools I’ve used were gdb with peda and pwntools and struct libraries.
This was a 64-bit binary. I don’t I’ve done overflow on 64-bit before in any CTF so it was kinda new to me. The concept is still the same as 32-bit though.
I use ‘pattern create 50 out’ to generate a file named out with 50 bytes. ‘run < out’ takes bytes from the out file and inputs them after running the program. As you can see in the image above, there is a crash.
I can run pattern search to look at offsets. I also look at backtrace and look at the offset for the pattern find there. It is 40. This means that we need 40 bytes + address and whatever the address is should land in RIP and the application will jump to that address.
I test this out below:
In the screenshot above, you can see that BBBBAAAA is where the application jumps to.
When we connect to the server, this is the output:
Notice the location address it returns. This is where our code will be placed. The downloaded application also does this, obviously. Our goal is have some code at that address to obtain shell.
This is what my code ends up looking like:
First I make a connection then read the input. I extract the address that I need to jump to then pack it. I found shellcode that executes /bin/sh and I’ve added that as well.
\x90 is a nop, however, when testing, I was using \xcc (int3) which makes the debugger break (as in breakpoint) and lets me do step by step execution.
My data I will be inputting will be SHELLCODE (execute /bin/sh) + nop * (40-lenth of SHELLCODE)
I then send the data and interact with the socket connection.
Below is how I got the flag.

Challenge: Forensics, Best Router

This was 200 points but rather easier than other ones I did previously.
There is a file associated with the challenge, which I have downloaded.
Visiting the URL looks like this:
File that you download is called: best_router.tar.gz, I untarred it and ran the file command to find more information about it.
We can guess that this is an image for the router. We can mount the partitions and examine the insides. I used kpartx.
Partition 1 didn’t have anything useful.
Partition 2 on the other hand has linux file system.
We know the title of the site is BEST ROUTER, we can just use grep to find it.
And looking at the files in var/www gives us the username and password:
The username and password allow us to log in and get the flag:

That’s all. I attempted other challenges but didn’t obtain flags. :-(
Posted by at

Friday, September 8, 2017

CTF Tips and Resources

Introduction:
This post has tips and resources for doing a CTF...
Tips and Resources:
First read Trail of Bits CTF guide. It’s very good. https://trailofbits.github.io/ctf/
Also watch these:
If you’re playing CTF with a team, you can do different type of tasks (web, crypto, reversing, exploitation, etc) or focus on one category. Either way, you should aim to learn more of whatever you’re trying to learn.

Prepare your tools. I recommend setting up a virtual machine with Kali Linux. Kali should contain many of the tools you need. Remnux is also a good VM to have. You can also run a VM on a remote system. I personally have a machine setup on Vultr with docker and ctf-tools (https://github.com/zardus/ctf-tools) I highly recommend installing ctf-tools. You can also install tools such as Pwntools (https://github.com/Gallopsled/pwntools). Depending on what you’re trying to do, you’ll need different tools.

I highly recommend writing your own tools as well. You can keep them to yourself or share them. You might participate in more CTFs and you might get challenges where you can reuse the scripts or tools you ended up writing.

Document all of the things you do. While you’re doing a CTF, you should be documenting how you’ve been solving challenges. I recommend using a tool such as KeepNote. KeepNote also lets you export to HTML. Keeping notes of what you’ve done will help you in the future and you can also share them so other people can learn. Typically, some people will publish write-ups from CTFs on how they solved challenges. When documenting, keep the files you were given for challenges and save the challenge text as well so your audience knows what you were actually trying to solve.

Read write-ups! Read write-ups that other people have written. Everyone approaches problems differently. You’ll notice that people have solved a same challenge differently. You can pick up these techniques to use next time. This github page has organized write-ups from different CTFs https://github.com/ctfs Write-ups get posted on https://ctftime.org/ too. Stuff gets posted on securityCTF subreddit too https://www.reddit.com/r/securityCTF/
Here are some useful sites:

Posted by at

Monday, August 28, 2017

Quick Solstice Pod analysis

Introduction:
My school has started using Solstice Pods (https://www2.mersive.com/land/solstice-pod/) in some classrooms. First thing I thought about is how I could troll people in classrooms by playing Rick Roll. Doing this would require me to have 4 char. access code.
In my post about Crestron Airmedia  (http://www.boredhackerblog.info/2016/04/bruteforcing-crestron-airmedia.html), which is a similar product, I was able to get access code by brute forcing the code and looking for a specific reply. In that case, the access code was made up of just numbers. Access code for Solstice Pod has numbers and uppercase alphabetic chars. Also, the channel for sending access code for Airmedia was in cleartext and easier. I can’t figure out how exactly Solstice client sends the access code. I know it’s not cleartext. I didn’t do enough reversing to answer this question. I think I would have had to use Frida at some point if I was able to do better reversing.

Anyways, I brought one of the Solstice Pod boxes home so I could play with it and see if I could find other ways to mess with it or find potential security issues. I spent less than 8 hours researching this and probably won’t continue researching it because school will start again.

Some students from last years Risk assessment class did do an assessment of Solstice, however, they were not able to find anything major. Also, they were evaluating an older version (I think version 2).

Device information:
Username: admin
Password: anything you set the password to be, in my case i set it to be password
Version:

Solstice Pod runs Android and Solstice Server runs on top. The hardware has USB input, HDMI output, Ethernet, and Wireless. It has same specs as Razer Forge since it’s actually Razer Forge with Solstice software.

There are two ways to connect to the device. One is by using ethernet and the second is by using wireless. You can connect using clients for Windows, Mac, Android, and iPhone.

Nmap scan of the device from wireless connection:
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
443/tcp  open  https
7100/tcp open  font-service
8080/tcp open  http-proxy
8443/tcp open  https-alt

Nmap scan of the device from ethernet connection:
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
7100/tcp open  font-service
8080/tcp open  http-proxy
8443/tcp open  https-alt

Other ports that are open:

Solstice documentation has information about the ports.

Findings:
Wireless:
If you have wireless enabled, Solstice can create an AP for you to connect to so you can broadcast your screen. If the client is connected via wireless, then they can also access the internet using the ethernet connection. There is a setting option that allows you to disable this! It’s would be an issue if you deployed bunch of these and forgot to disable wireless or routing via ethernet. Not really a big issue though.

Screen access code bruteforce:
As mentioned in the introduction, I was not able to figure out how to brute force the access code by doing the analysis I did. There is a way to do brute force, however, it requires Look-in option to be abled. Look-in option allows people to view whatever is on Solstice display remotely via browser.
If it’s enabled, you should see a link:
When you click on the link, it asks you to input the screen key (I’ve been calling it access code…):

I was using Burp suite to intercept the requests.
I tried the key AAAA:
First a POST request is sent with screenKey AAAA.

After that a GET request is sent with the screenKey AAAA

The response to GET request shows that the screen key did not work.

Next I performed the GET request with the correct key and here’s the response:

You’ll quickly notice that the response is an actual JPG image. (JFIF header)

If you didn’t know the screenKey and wanted to find out remotely, here’s how you could go about doing that.
1) Look-in feature has to be enabled. I don’t think it’s enabled by default.
2) You need to generate possible keys. You can do this easily in Python by using the following script:

import string, itertools
pass_length = 4
chars = string.ascii_uppercase + strings.digits
for guess in itertools.product(chars,repeat=pass_length):
   print ‘’.join(guess)

(found an example on stackoverflow, I forgot to bookmark it :()

3) You would brute force http://IP/lookin/thedisplay.jpg?screenKey=SCREENKEY and look for a reply bigger than 38 bytes(if key is invalid we get screenKeyValidationRequire response, which is 38 chars).
4) Be patient. Brute forcing all the possible keys would take a long time.

This again is not a very big issue. You would notice someone brute forcing the box. It’s really not worth doing, even if you’re trying to Rick Roll someone.

DoS attack:
I moved to examining Configuration page. Screen key lets you share your screen or view via Look-in feature. Configuration has a separate login. The username is admin and the password is whatever you set it to be.
On configuration page, you’ll get a login prompt:

As mentioned before, I had Burp Suite running. In previous versions, when you tried to login, the application would pass the password in cleartext in a GET request. The newer version does not do this. The newest version hashes the password with SHA-1 then sends that via GET request just like the older version.
9d4e1e23bd5b727046a9e3b4b7db57bd8d6ee684 is SHA-1 Hash for pass.

I decided to just pass bunch of data in the password parameter just to see what would happen. It actually crashed the Solstice server and restarted it. Screen went blank and restart takes about 20-30 seconds.

This is how you can trigger the service to crash: (I didn’t have word wrap enabled so I just added new lines. It should all be one line. :D) Finally, this is something that’s useful. You can setup a script to trigger the crash and keep causing DoS for the instructor or other students utilizing Solstice Pod.
Undocumented Paths:

I wasn’t able to find any documentation on some of the paths I found using just strings. As mentioned before, Solstice software runs on top of Android. After logging into Configuration page, I noticed JSON response:
"canUpgradeToVersion":"3.0.1","canUpgradeToBuild":"6923","canUpgradeToBuildDate":"","canUpgradeToBuildTime":"","canUpgradeToDate":"7/11/2017","canUpgradeToRelNotes":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/ReleaseNotes.html","canUpgradeToDownload":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/Solstice.apk","latestReleaseVersion":"3.0.1","latestReleaseBuild":"6923","latestReleaseBuildDate":"","latestReleaseBuildTime":"","latestReleaseDate":"7/11/2017","latestReleaseRelNotes":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/ReleaseNotes.html","latestReleaseDownload":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/Solstice.apk","installedReleaseEdition":"Unlimited","installedReleaseVersion":"3.0.1","installedReleaseBuild":"6923","installedReleaseBuildDate":"","installedReleaseBuildTime":"","installedReleaseDate":"7/11/2017","installedReleaseRelNotes":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/ReleaseNotes.html","installedReleaseDownload":"http://www.mersive.com/Support/Releases/SolsticeServer/SGE/Android/3.0.1/Solstice.apk", It included a link to an APK file. I downloaded the APK file and just unzipped it. There is a web folder with all the HTML/JS stuff that you see on the webpage. There is also a lib folder. I searched for “Look-in” to see which binary contained that string. I loaded up the binary file in IDA so I could look at strings. I started looking for common Linux commands to see if they were based on any user input. If they were I could try to inject something but I didn’t find anything that was based on user input. I came across something interesting while doing searches: There is /diag, which you don’t see when running Burp. Accessing anything under /diag does require you to authenticate. The username is admin and the password is whatever password you have set for configuration. Loglevel shows you the loglevel settings. Logs.zip gets you a zip file with logs. Clearlogs probably clears the logs, I didn’t test it. Log prints out the logs (screenshot below). I didn’t get logcat either. Tcpdump gives you an option to run tcpdump and download pcap files (screenshot below).
I started looking for more potential paths that I didn’t come across before. I found /test. Accessing /test does not require authentication. You just get system and performance information. Conclusion: I hope that someone finds this post useful or gets ideas from it. There wasn’t much of a methodology I followed. I did use automated tools such as OWASP ZAP and Subgraph Vega (found nothing)  before doing manual work. Vendor response: I reported DoS bug on Aug 4, 2017 Vendor responded on Aug 7, 2017 saying that it will be fixed in the next update Vendor released an update fixing the DoS bug on Aug 27, 2017. Version with DoS fix is 3.0.3.
Resources for this project were provided by the Living Lab at IUPUI. https://livlab.org
Posted by at
Subscribe to: Posts (Atom)