NCC Con 2018 iOS CTF Solutions

I just returned from NCC Group’s internal North American conference, a nice respite from the cold East Coast to sunny San Diego.  I’m a remote employee, so it’s always a blast getting to hang out with my New York office coworkers and seeing awesome presentations from colleagues from across the country.  One of the highlights was the mini-CTF put on by Sid Adukia and Dean Jerkovich.

This CTF consisted of an iOS app bundle compiled to run on the iOS Simulator, thus able to run on any Mac with Xcode and not requiring a jailbroken device.  I’ve been doing iOS application pentests for years and it was really cool to see a CTF challenge using this!  This is the first one I’ve seen since DVIA came out years ago.

Perhaps the biggest challenge was the fact that this was a Simulator app.  Had it been an ARM-compiled iOS app that I could put on a jailbroken device, I would’ve solved a lot of these challenges in a few minutes.  Most of my time was spent googling for how to do stuff like dump the keychain or hook methods on the Simulator instead of on a jailbroken device.

I’ve been worried recently just what the future of iOS security is going to look like.  It seems we’ve been thrown a few bones in the last month, with Project Zero’s Ian Beer recently publishing the “tfp0” vulnerability and Jonathan Levin publishing LiberiOS, the first jailbreak for versions of iOS 11.  But fewer and fewer people are publicly releasing jailbreaks.  I don’t blame them either. Due to the enormous sums being offered by exploit brokers, many would argue you’re a moron for giving away million-dollar exploits for free.  Someday soon, those of us in iOS security testing might be forced to have our clients compile x86 versions of their apps for us and run them all in the iOS Simulator.  The good news is that a surprising number of the same tools and techniques you would normally use on a jailbroken device will also work with a Simulator app on macOS!  Some things don’t, but if you’ve ever chased the latest jailbreak and found that half the stuff on Cydia doesn’t yet work for your version of iOS, then you’re already used to life on the bleeding edge. Continue reading


BSides Raleigh 2017 CTF Write-Ups

Taking some inspiration from my friend, Ray, I decided I’d write up some of the solutions to the various challenges I saw at this year’s BSides Raleigh CTF (capture-the-flag) events.  And this time, I actually remembered to save some notes and screenshots!

This isn’t a record of every single challenge I saw, just a few that I thought were particularly interesting or noteworthy.


This was a simple one…which I like, because I suck at CTF crypto challenges.  The page was just these emoji spread out:

😮😮 😮😮😑😮 😑😮😑😑 😑😑😑 😮😮😑 😑😮😑😮 😮😑 😑😮 😮😑😮 😮 😮😑 😑😮😮 😑 😮😮😮😮 😮😮 😮😮😮 😑 😮😮😮😮 😮 😮😮😑😮 😮😑😮😮 😮😑 😑😑😮 😮😮 😮😮😮 😑 😮😮😮😮 😮😮😮😑😑 😮😑 😑😮 😑😮 😮😮 😮😮😮😑 😮 😮😑😮 😮😮😮 😮😮😮😮😑 😮😑😮 😑😮😑😑 😮😮😑 😮😑😑😮 😑😮😑😮 😮😑 😮😮😮 😮 😑😮😮

So I noticed right off the bat that there were only two emoji being used: 😮 and 😑.  My initial thought was maybe this was something in binary, but I was dissuaded from that because of the variable lengths of emoji strings.

The next thought was Morse code!  So I copied the emojis into Sublime, did a find/replace for each character, to get this:

.. ..-. -.– — ..- -.-. .- -. .-. . .- -.. – …. .. … – …. . ..-. .-.. .- –. .. … – …. …– .- -. -. .. …- . .-. … ….- .-. -.– ..- .–. -.-. .- … . -..

Running that through a Morse code translator yielded the message:


So naturally, the flag was TH3ANNIVERS4RY.

Continue reading

My Grand Tour of Pentest Interviews

Late last year, I began looking for a new job.  Earlier this year, I finally got one!  I was interested in branching out into the broader world of penetration testing and red teaming, with more external clients and more broadly-scoped sorts of engagements.  This was something of a sell to prospective employers though.  I do have close to a decade of infosec experience, but only a few years of that is pentesting and I’ve always been an in-house pentester doing mostly web app and mobile stuff.  That means that I am something of a noob when it comes to breaking in from the outside; I’m familiar with a lot of the tech and methodology, just haven’t done a lot of it hands-on (outside of CTFs and stuff like that).  I’ve been in the broader industry for a while, meaning my salary requirements are a little higher, and I absolutely wasn’t going to relocate again so soon after my last move for my old job.

All of this and extremely high demand for pentesters at the moment meant I went through A LOT of interviews.  Some of them broke down over salary expectations.  Some of them I quit early because I could tell it wasn’t what I was looking for.  Some of them weren’t budging on relocation.  One I completely hosed myself on because I bluffed too hard during the salary negotiation phase.  At least one of them probably thought I was a complete dumbass.  But in the end, one employer won out and I’m now happily hacking clients, mostly from the comfort of my own home.

Besides having lots of experience being interviewed for pentest jobs, I also have some experience in interviewing people for pentest jobs.  At one of my previous employer, I was involved in telephone screenings and in-person interviews of a dozen or so different candidates to join our team there.

Because I went through so many different interviews recently and have experience trying to assess pentest candidates, I figured that put me in a unique position to grade these different companies and throw in my own opinion on the best way to do it.

My intent is half to just be amusing for those who are curious about how different companies are interviewing people, maybe those trying to find out what to expect the next time they start looking for a new gig; but I’m also writing this and hoping that some recruiters and hiring managers will see this.  I hope this will give you some insight into how your competition might be assessing candidates, what you’re doing right in your own process, what you’re doing wrong, and how you could be doing it better. Continue reading

Running KeepNote on a Mac

During my PWK training, I absolutely fell in love with KeepNote.  I used it extensively for tracking all the different networks, all the hosts in that network, all the different scan results and loot I’d collect on each, and also general notes about attack vectors I had tried, what worked, what didn’t work, what to explore, little code snippets or Linux commands for easy copy-and-paste use later, links to helpful articles…you get the picture.

Unfortunately, KeepNote isn’t very well-maintained.  As of this Fourth of July, the latest versions uploaded to the main site are five years old.  The original developer did put it on Github two years ago, but there haven’t been many pull requests accepted since then and he obviously doesn’t have the time to keep up with it anymore.  Totally understandable, but it sucks because I haven’t found a good, well-maintained replacement for it.

And believe me, I’ve tried!  Evernote, Bear, nvALT, desktop wikis like Zim, the macOS Notes app, and on and on.  No one else is doing, or even offering an option to do, the same kind of UI layout.  I don’t know why, but the three-pane arrangement of KeepNote just hits the spot for me.  The outline on the left side, submenu on top right, and notes section on bottom left; no one else arranges their app like this.


For real, this is my happy place.

Continue reading

OSCP Update

Look what came in the mail a few weeks ago!

For the curious, it took about a month for them to send the paper certificate and a little hard-plastic credit card sized version via DHL courier.  They send you an email asking where you want it mailed, just in case you’ve switched apartments or something in between registering and passing the exam.

Also, I realized in my previous OSCP review that I forgot to mention a few things.  I’ll list them here and also add them as an update to the original review post. Continue reading

My OSCP Experience

**Update (11/4/2016) – added a few bits back in from this post

A few weeks ago, I “tried harder” and was awarded the Offensive Security Certified Professional (OSCP) certification.

As many people before me have done, I decided I’d post a little writeup of my experience with the Pentesting With Kali (PWK) online training and taking the OSCP exam (twice).

As you probably know by now, the OSCP is Offensive Security’s certification for penetration testing using the Linux distribution they maintain, Kali Linux.   The accompanying course, Pentesting With Kali (PWK), gets you a PDF lab guide and a series of instruction videos covering the different topics of the guide, from basic network enumeration to writing buffer overflow exploits.  You’re also purchasing VPN access to their hands-on lab environment of dozens of different vulnerable hosts for you to probe and exploit.  To attain the OSCP certification, you take a hands-on exam in which you’re given VPN access to a special exam network and are alotted 24 hours to compromise as many systems as possible, plus an additional 24 hours to write up and submit your exam penetration test report.

I signed up for the 90-day course, bought a one-month extension after I ran out of time (mostly for going back over machines to write the huge lab report…more on that later), I bombed my first attempt at the exam, purchased a two-week extension in order to bone up on some stuff and get a retest attempt, then passed it on my second try.

The Cost, Signing Up, and Getting your Employer to Pay For It

I’ve wanted to take OffSec’s training for a long time and I should’ve just sucked it up, ponied up the money, and took it years ago.  I fought for over a year at my previous employer to get them to finance it.  I was ready to give up arguing with them and buy it myself before I landed in my current job.  Thankfully, where I work now has a healthy training budget for its pentesters and all I had to do was put it on the corporate card. Continue reading

CNS 320 Lesson 9 – Sniffing

Lesson 9 – Sniffing

Screen Shot 2016-02-06 at 9.59.41 AM.png

Screen Shot 2016-02-06 at 9.59.45 AM.png

  • In the old days, most LANs used hubs.  When a packet would come into the LAN, the hub would send it to everyone.  If the packet said its destination was your network card’s MAC address, you would take it and process it.  If it *didn’t* have your MAC, you were supposed to politely ignore it.  Yeah…you can guess how this ends.
  • Nowadays, LANs use “switches” instead of hubs.  Switches are smarter and keep track of which MAC address is hooked into which port on the switch.  That way, it only sends the packet to the computer it’s intended for.  This makes sniffing other people’s traffic more difficult…but we’ll see how attackers can get around this.
  • NOTE: later, we’ll talk more in depth about wireless networks.  Since they use radio signals that propagate out in all directions, they inherently have many of the same problems as hubs do.

Screen Shot 2016-02-06 at 9.59.46 AM.png

  • Rlogin or rsh is an old remote access protocol for logging into Linux/Unix servers.  It and telnet are both plain-text and have mostly been replaced by SSH, which is encrypted.  Rlogin/rsh usually operates on TCP port 513.
  • NNTP = Network News Transfer Protocol, the protocol used for sharing Usenet posts.  TCP 119 is reserved for it.

Screen Shot 2016-02-06 at 12.36.20 PM.png

  • Network taps sit inline between switches, routers, and/or hosts and listen in on the packets being sent.  Troubleshooting tools and intrusion detection systems (IDS) are two types of tools that often employ taps in order to monitor the network.
  • Port mirroring (SPAN as it’s called in Cisco products) is a feature of the router or switch itself and can more intelligently filter what data to intercept

Screen Shot 2016-02-06 at 9.59.49 AM.png

Screen Shot 2016-02-06 at 9.59.50 AM.png

Screen Shot 2016-02-06 at 9.59.51 AM.png

Screen Shot 2016-02-06 at 9.59.52 AM.png

Screen Shot 2016-02-06 at 9.59.53 AM.png

Screen Shot 2016-02-06 at 10.00.06 AM.png

Screen Shot 2016-02-06 at 10.00.07 AM.png

Screen Shot 2016-02-06 at 10.00.08 AM.png

Screen Shot 2016-02-06 at 10.00.10 AM.png

  • Intranet Spoofing: Acting as a device on the same internal network
  • Internet Spoofing: Acting as a device on the Internet
  • Proxy Server DNS Poisoning: Modifying the DNS entries on a proxy server so the user is redirected to a different host system
  • DNS Cache Poisoning: Modifying the DNS entries on any system so the user is redirected to a different host

Screen Shot 2016-02-06 at 10.00.11 AM.png

Screen Shot 2016-02-06 at 10.00.12 AM.png

Screen Shot 2016-02-06 at 10.00.16 AM.png

  • Ping method: if you suspect a certain IP address is a sniffer, send it a ping packet with its valid IP addresses but the wrong MAC address.  If it responds anyway, it’s the sniffer.
  • ARP method: send out a non-broadcast ARP message. Next, we send a broadcast ping packet with our IP address but a different MAC address. Only a machine that has our correct MAC address from the sniffed ARP frame will be able to respond to our broadcast ping request.
  • Source-route method: send out a ping, but with a loose-source route so that it will be routed through another machine on your network segment. Most computers won’t route packets like this, but if you get a response, it’s like the machine is running in promiscuous mode.
  • Decoy method: this method involves sending false information over the wire (such as fake username/password combos) and seeing if anyone acts on it.
  • Reverse DNS method: many sniffer programs will automatically perform reverse DNS lookups of the addresses we sniff. If you start seeing two machines have remarkably similar DNS traffic, one could be sniffing the other.
  • Latency method: flood the network with traffic.  The sniffer will start to creak under the strain.  If you see a machine on the network suddenly having very high latency when responding to requests, it might be the one sniffing.
  • TDR: TDRs are tools for testing electrical cables.  They are capable of detecting hardware taps and sniffers.

Screen Shot 2016-02-06 at 10.00.17 AM.png

  • Port security, or MAC filtering, will lock a specific MAC address to a specific port on a switch.  This way, it prevents ARP spoofing.
  • You could also go to the trouble of making a static ARP table and ignoring any spoofers sending out unsolicited APR replies.
  • The most common method is to use network IDS/IPS products that look for suspicious traffic, like floods of unsolicited ARP replies or large volumes of DNS traffic.
  • The best way to deal with sniffers is to make them pointless.  If you use public-key encryption (like TLS), it won’t matter if you’re being sniffed; the eavesdropper won’t be able to read your packets anyway.

Screen Shot 2016-02-06 at 10.00.18 AM.png

  • In the labs for this lesson, I would have my students work through a tcpdump tutorial ( Most of them were already very familiar with Wireshark, but few had used tcpdump on the command line.
  • After that, we’d pair up and play with sniffing traffic.  I would start them out with the relatively-simple arpspoof utility and then start using the more advanced ettercap.