My high school aged son came down at around midnight the other night to my cubby office in the basement, concerned about what had me up so late. I had my laptop open and he could see various bits of code up on my monitors. “Mom, what are you working on? Still stuff for work?”
I had a jsfiddle open, various tabs up in my web browser, and a kali Linux VM up. How to explain to my son my addiction which had me spiraling into the wee hours?
“No, closed out my work hours ago. This is coding for fun on a CTF”.
“Getting anywhere?”
“Welp, hashcat is churning, but so far it doesn’t look good, and this other stuff is me futzing on code to solve a different challenge. So, maybe?”
“Going to bed anytime soon?”
“Probably oughta, but…”
“Alright, mom. Love you. See you in the morning”
He knows me too well. A couple of hours later, I decided hashcat was not going to make it and I oughta find another approach. I left myself notes on the jsfiddle code as to next steps to try. Went to bed. Still up in time to wake him up for school. Life of a geek mom.
Category: Cyber
WiCys Challenge 2
After a day of supporting First Lego League as a judge (lotta fun!), I was delighted to see an early release of next week’s WiCys cyber challenge. The title is ‘Wireshark doo dooo do doo’ and it’s only a 50 point challenge, so I was expecting a not too difficult exercise in finding things in a network traffic file.
Not too difficult is right. After checking the file properties (and importantly, looking at the comments, as well as doing a quick search in the text of the file for the flag format of picoCTF – hey, easy finds are still points!), I looked through what the file’s protocol hierarchy said it held. Mostly HTTP, with a little bit of line-based text data. Let’s start there.
Results: two packets that returned text/html or text/plain data. The line-based text data one has a syntax that looks a lot like a flag: foo{morecraziness}.
I tried using CyberChef’s Magic decryptor, without success. I even tried telling it what I expected the first bits of the text to be (“The flag is picoCTF”) – stil no dice. I then tried an online substitution cypher breaker I’ve used before: https://www.dcode.fr/rot-cipher. In this case, the first thing it returned in its long list of possibles was ROT13, with text that said THEFLAGISPICOCTF. OK, that’s my likely winner. I went back to CyberChef and used its ROT13 recipe, figuring it’d better handle upper/lower, numbers, etc. Bingo. Flag in hand, all w/in ~15 minutes.
Going to have find some more interesting puzzles for the rest of the week…
WiCys Challenge 1
Intriguing item in my Slack feeds this morning:
What is it: Weekly challenges from the picoCTF gym in #wsc-ctf-challenge
How it works: Each week a challenge from the picoCTF gym will be shared in #wsc-ctf-challenge with cross post to #general, the following week a solutions thread will be opened for people to discuss their solutions. (Please keep spoilers in thread for people that are solving challenges later)
Challenges will be shared Jan 23nd, Jan 29th, Feb 5th with a zoom walkthrough planned for Feb 12th.
This week’s challenge was entitled ‘Scavenger Hunt’ and led us to a very basic webpage. The hunt was on! As it looks like they’ll be releasing these on Sundays each week, I’ll see where each Sunday leads, and then write up my discoveries.
First step: inspect the HTML through developer tools. There was a comment in the primary webpage that described itself as the first _part_ of the flag. No mention of how many parts.
OK, looking further, I looked at the site’s javascript, which gave me a clue that led me to look at the site’s robot.txt file, which is used to keep Google from crawling the site. That told me I had part 3 of the flag, and mentioned that the next flag was related to the site being an Apache server.
Checked the CSS next, which showed me part 2.
This is where I was stuck for a while. I tried a number of things related to the site being an Apache server.
- Brute force trying a few potential file paths: admin, README.txt, …
- Tried running TRACE against the site, after reading a couple of articles [1, 2] which talked about hardening your Apache server:
curl -v -X TRACE http://mercury.picoctf.net:27393 - Tried banner grabbing via nc, since that’s one of the other things the links suggested turning off: nc {ip of box} {port}.. Then immediately followed by HEAD / HTTP/1.0 (also tried 1.1)
- Tried fuzzing to find unrecognized files:
sfuzz -S {site} -p {port} -T -f /usr/share/sfuzz-db/basic.http -L picofuzz.txt -q- My plan was to grep the log file for ‘flag’, ‘part’, or even regexs of chars_chars_chars, since the flag structures seemed to look like that
- I left sfuzz running while I was at church, but it didn’t even retrieve the javascript files or robots.txt
- Tried directory busting via
gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -u http://mercury.picoctf.net:27393- No results
Finally I opted to look around and find some other CTF writeups that referenced Apache, in case they led to more angles. I found this one, which mentioned using dirb to identify entry points. Running dirb http://mercury.picoctf.net:27393 turned up an .htaccess file, which had a flag in it and another clue.
The next clue said: “I love making websites on my Mac, I can Store a lot of information there.” I started a looking for ways to find common Mac files. I used to have a Mac, so was used to seeing an extra file or two around, but couldn’t remember what they were called. I started looking for sample .gitignore files for Mac developers, and found this posting which mentioned that “This will ignore any files named .DS_Store, which is a common file on macOS.” Aha – now I see why store was capitalized. Sure enough, browsing for that file gave me another piece of the flag and a message that said I’d completed the scavenger hunt.
One other thing I did try which I’ll want to use again in the future: I used the tool “nikto” which exists to scan web servers for known vulnerabilities. When pointed at the hostname and port, it gave me some information about the system, including the existence of the .htaccess file. It would apparently have also pulled back the banner information from the web server.
Masters – complete!
On Thursday, Dec 16th, I turned in my last paper for my last project for my last class of my cybersecurity degree. On Friday, December 17th, my teammate turned in the last deliverable of the project. I’m done! We’ve gotten feedback on our deliverables already (“Exceeds Expectations” – a common refrain) and a hearty “best wishes in your future endeavors” from our professor. I’m done! I’m done! The grade hasn’t posted on my transcript yet, but UMGC is holding virtual commencement exercises today. I’m walking on cloud nine, just not on a stage. I wouldn’t have walked on the stage anyway – I just wanted the achievement, not the hassle of getting to some event somewhere to be announced to people I don’t even know.
Instead, I’ll spend my weekend working with balloons for a Clementine gig this afternoon and just generally being ecstatic that I’m done!
Succumbed to temptation
Succumbed to temptation today and bought a laptop. I’ve been thinking about it for a while. In two more weeks, I’ll need to hand back in the one I’ve been using from work. This Macbook has stood me well through college and capture the flags, and I’ll be sad to see it go, particularly since it’ll take another week after that before my new one arrives. That said, 32GB of RAM, a 1 TB NVME drive, an NVIDIA GPU with 8GB, and an AMD Ryzen chip: gotta put this poor box to shame. I’m going to have to grow my chops in reverse engineering and cyber exploitation to match it!
Solved a thing
You may have seen a few more geek notes on here of late. I’ve really enjoyed jumping into CTFs. My objective isn’t to win, but to find more ways to solve puzzles.
This weekend’s adventures were a little different, though. My company sponsors UMBC’s CyberDawgs team, and they’ve asked us to contribute challenges to their upcoming CTF. I tasked our IRAD team with coming up with a few and I wrote a couple, as well. So this weekend I spent some normalizing our submissions’ README files and doing a final test of the submissions.
One of the submissions was really giving me trouble. The IRAD team member who’d developed it had demonstrated it to us, but the solution instructions in the README just weren’t “clicking” to then be able to reproduce a solve, much less help anyone else understand how to solve. It’s customary in CTFs to have a Discord channel where mentors can offer assistance to those on the right track; given that I don’t want to be up all night myself providing that support, thought it best to provide a walkthrough for someone else..
Not only did I “crack” it (helped, of course, by the solution instructions in his README), but then I was able to provide a linked reproducible recipe using a tool called CyberChef that is really useful for a lot of CTF grunt work. I’m avoiding linking to the recipe or giving any more info on the challenge, of course, given that there’ll be hopefully lots of folks taking a crack at it in early May. I’m now more confident, though, that there may be some folks who solve it AND I better understand a particular kind of encryption approach.
Wireshark lessons learned
My masters classes keep sending us into Wireshark to analyze packet files. I thought I had a decent understanding of how to use Wireshark from some previous experience through work, but I keep finding new tricks as I try to figure out things about unknown protocols. Note that I’m using Wireshark 3.0.3, because that’s what’s installed in the lab infrastructure. I am aware that Wireshark 3.4 is out: my plan is to play with that version on my personal computer to see new goodies.
Copy and Paste
We keep needing to fill out spreadsheets of interesting things learned. We’re running Wireshark through a VDI infrastructure and I’m typically doing my homework on a laptop, so with limited screen real estate, even my touch typing skills aren’t helpful enough. The Copy capability in Wireshark lets me capture just the value for the field – highly useful for things like MAC addresses.
Protocol Hierarchy
Forget about randomly traversing files which including 100K packets – let the protocol hierarchy show likely interesting data points within the file. Filter by said protocol, and data patterns emerge. Worth calling out also the Conversations and Endpoints statistics areas, as well. Nice ways to get a holistic view of what’s going on in the file and what might be worth diving into.
Statistics -> …
We’re looking at SCADA pcap files, including BACnet. Delighted to find a traversal means for BACnet that let me inspect the devices and services seen in the pcap. I was less happy to see that iFix wasn’t in the list, and that Wireshark just treats it as plain TCP (again, with my older version of Wireshark, with its default set of dissectors, etc). Possibilities for expansion.
Expert Analysis
There’s a menu option for ‘Expert Analysis’ that I hadn’t played with before. Add its data, and then allow it to create filters to show just that data – voila. Evidence of TCP retransmissions? Yes, please.
Blast it, I’m going to do it the interesting way…
My masters class had us writing Yara rules for our project lab. Given that I recently gave a talk at DataWorks MD that took a brief foray into describing the use of Yara rules for static malware analysis – well – I was prepared for and looking forward to this particular lab.
The challenging part of the lab: to help us understand how analysts decide which byte(s) to check for hex strings, the lab had use the Linux utility, hexeditor. As instructed, we were to
- sudo hexeditor
- use the keyboard’s arrows to navigate into a particular file
- press Ctl-W to invoke ‘search’
- use the arrows to navigate to the hex search option, as opposed to text search
- type in the appropriate hex string. Note: the hex string could be longer than the editor would show us in its entry window. With a long enough string, we were then working blind with typos
- if the hex string was found, jot down at what byte position so that we could later use that in our Yara rules
Bleah… Too many opportunities for typos. Too slow, as we needed to iterate across five files. _Really_ too slow when you consider we were doing this in a VM hosted on university infrastructure, using its GUI via NoMachine.
Improvement 1: sudo hexeditor filename at least got me into a particular file, and importantly, let my file history show me what files I had already interacted with.
I then looked for command-line options to target hexeditor with a search string. That would at least let me repeat previous commands and edit the filename or the hexstring. Unfortunately, hexeditor doesn’t support anything of that sort. grep would apparently have gotten me to whether the pattern existed in the file, but not given me the byte location.
Long-ish story short, although the lab itself had no reason to cause me to do this, and it certainly took me longer to work this out than to just hand jam it, I now have scripts to iterate over a set of files and a set of hex strings to determine if the hex string is represented in the files, and if so, where. My geek demon is satisfied this evening, and I’m holding onto the files here to help in CTFs or other future geekish fun. Credit to here for the general approach for finding hex data locations in files, and here for helping work out the problem of iterating over lines that contain spaces.
#!/bin/bash
# test_hex_find.sh
# Examine file for hex value
# Argument 1: file name to check
# Argument 2: hex string to look for
position=$(od -v -t x1 $1 | sed 's/[^ ]* * //' | tr '\012' ' ' | grep -b -i -o "$2" | sed 's/:.*//')
if [ ! -z "$position" ]
then
position=$(( position/3 ))
echo "filename: $1, hex value: $2"
printf '%06X\n' $position
fi#!/bin/bash
# find_hex.sh
IFS=$'\n' hex_strings=( $(xargs -n1 <hex_strings.txt) )
for hex_string in ${hex_strings[@]}; do
echo $hex_string
done
for file in *.exe; do
for hex_string in ${hex_strings[@]}; do
./test_hex_find.sh $file "$hex_string"
done
done"C6 45 F4 74 C6 45 F5 6C C6 45 F6 76 C6 45 F7 63 C6 45 F8 2E C6 45 F9 6E C6 45 FA 6C C6 45 FB 73"
"8A 04 17 8B FB 34 A7 46 88 02 83 C9 FF"
"5C EC AB AE 81 3C C9 BC D5 A5 42 F4 54 91 04 28 34 34 79 80 6F 71 D5 52 1E 2A 0D"