This post is only one of the writeups I wrote about SunshineCTF 2020. To check out more posts from this CTF, check out my profile.
TSA Techie (150 points)
On a regular flight between NRT and MCO, Customs and Border Protection seized a suspicious iPhone from someone's luggage, along with a sticky note with a mysterious URL to some sort of device registration page. The phone doesn't boot into iOS and, upon further inspection, was stolen from the factory.
That's where you, the contractor, come in! Take a look at the report the TSA gave you to investigate. It should include everything you need to bust this prototype iPhone smuggling ring!
challeng author: Jeffrey D.
Initial analysis
A suspicious, stolen iPhone has been seized and we're tasked with busting the smuggling ring. We are given two documents: the investigation report, and a note found with the phone.
The investigation report mentions that the suspect is believed to be smuggling smartphones out of Foxconn factories.
We are given some details on the stolen iPhone, namely some parts of the serial number, the WiFi and Bluetooth MAC addresses, the ECID and the iPhone model name.
The note found with the phone comes with a URL: http://device-registration.web.2020.sunshinectf.org
We are also given the flight history of the suspect. To note here, his first flight originates in Zhengzhou, in the third week of november.
Taking a look at the website
We are presented with a registration page that says our device model and the device's UDID will be used to verify we are indeed in possession of a smuggled iPhone.
Upon pressing the register button, we are sent a file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<dict>
<key>URL</key>
<string>https://device-registration.web.2020.sunshinectf.org/udid/verify</string>
<key>DeviceAttributes</key>
<array>
<string>UDID</string>
<string>PRODUCT</string>
</array>
</dict>
<key>PayloadOrganization</key>
<string>TotallyNotASmugglingRing</string>
<key>PayloadDisplayName</key>
<string>Device Registration</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadUUID</key>
<string>2fe6ebd9-a281-4d46-8094-9468b6d6e701</string>
<key>PayloadIdentifier</key>
<string>sunshinectf.udid</string>
<key>PayloadDescription</key>
<string>This configuration is a device enrollment challenge that verifies your device using its UDID and model name.</string>
<key>PayloadType</key>
<string>Profile Service</string>
</dict>
</plist>
The content-type of this file is application/x-apple-aspen-config. This, coupled with the free hint we are given that links us to the apple developer page to a configuration profile service, leads us to believe we have to spoof a response to this file using the details we were given from the smuggled iPhone.
To go into a little detail; a configuration profile is essentially an XML file that can be distributed to iOS devices to easily configure some settings. This is very common for WiFi settings, especially for universities that require authentication via student/personnel email for security reasons.
The important data from the server request is within the key DeviceAttributes:
<key>DeviceAttributes</key>
<array>
<string>UDID</string>
<string>PRODUCT</string>
</array>
Our payload needs to contain these attributes. Looking around a bit on the apple developer page, we find config examples (here), and we're able to find a minimal iOS response example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>UDID</key>
<string></string>
<key>VERSION</key>
<string>7A182</string>
<key>MAC_ADDRESS_EN0</key>
<string>00:00:00:00:00:00</string>
</dict>
</plist>
Apparently all we need to do is provide a dictionary with the keys and the corresponding values that need to be in the payload, so here's what our response would need to look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>UDID</key>
<string>...</string>
<key>PRODUCT</key>
<string>iPhone10,1</string>
</dict>
</plist>
So here comes the hard part. We don't have the UDID.
Calculating the UDID
We can calculate the UDID??? Yup:
So we have the ECID, wifiMac and bluetoothMac values, but not the full serial number.
The good thing is that we have all the information we need to complete the serial number:
Our current serial number looks like this: ##T##621J##H.
The first two digits are the assembly plant id, we know our iPhone probably came from Zhengzhou, given the flight history of the suspect. This gives us FK as digits 1 and 2.
Digits 4 and 5 correspond to the production date. The previous source also includes an assembly date table, and since we know that the suspect left China in the third week of november, we assume that the iPhone was assembled the previous week, giving us digits DP.
The remaining digits denote the phone model. We know we have an iPhone 8. This gives us the remaining digits: C6.
The full serial number: FKTDP621JC6H.
To calculate the UDID I wrote a quick python script:
from pwnlib.util.hashes import sha1sumhex
# serial number decoding: https://en.tab-tv.com/?p=18929
SERIAL = "FKTDP621JC6H"
ECID = "2843135617639718"
WIFI = "14:88:e6:ac:63"
BLUETOOTH = "14:88:e6:ac:64"
print(sha1sumhex(SERIAL + ECID + WIFI + BLUETOOTH))
Running this sript gives us:
Note here that we were given the last 4 digits of the UDID, which match the calculated UDID. Neat sanity check.
Solving
From there, we just have to complete our spoofed iPhone response:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>UDID</key>
<string>1d87930059bad8eab14bebb81d7680c02a299ac6</string>
<key>PRODUCT</key>
<string>iPhone10,1</string>
</dict>
</plist>
and send it to the server:
and there's the flag!
Here's the flag: sun{2de17cd306bcb1606f2ee23f05bf1504a537d}
Conclusion
That's it for the TSA Techie challenge. A nice introduction into iOS configuration profiles, some iPhone spec internals and a bit of OSINT. Fun challenge!
If you're interested in other writeups for this CTF, check out my profile as they might keep popping up if I find the time! 👋
Top comments (0)