iOS Phishing Security Vulnerability
I recently stumbled upon this video depicting a security vulnerability that could result in a phishing attack: http://www.youtube.com/watch?v=XQXFO9NNO8g
While the demo is quite simple and shows how an image of address bar can be positioned at the top of the screen to fake an actual address-bar. This only applies to iPod’s and iPhone’s because the iPad handles the address-bar differently.
Now I wanted to take this a little further and incorporate some javascript and css to make this even better. First, We scroll to the top to hide the “real” address bar. Then we catch the “touchmove” event and use the HTML5 event.preventDefault() to stop scrolling up to the “real” address bar. Then we set an interval to autoscroll to the “real” address bar in case the user taps the status bar. This creates a very convincing effect.
Now I’ve done this all and a bare-bones demo is available here.
Now I didn’t put the time into this to make these ideas into proof of concepts, but I’d like to list them to show how powerful this could be if desired.
- Make the page auto-correct for landscape and portrait.
- Make the address bar appear to be usable, but instead proxy all connections and store the passwords.
- Make the page appear to act as safari does.
- Prevent the back button from actually going back using HTML 5 pushState.
This is just the beginning of the possibilities. Most importantly this is a dangerous vulnerability to even the most experienced of users as it can only be seen in the first second of the page loading and could be dismissed as a graphics bug in Mobile Safari. Lets hope Apple can figure out a way to patch this without removing window.scrollTo().
iOS Password Cracking
A video, since removed, by Micro Systemation has gone recently gone viral depicting a employee using their security software, XRY, to break the passcode on an iOS device.
So naturally I decided to demonstrate how it works. But first, we must figure out what is correct and what is mis-information. The firm’s marketing director said that XRY “works much like the jailbreak ‘hacks’.” This is actually not exactly correct. XRY works the same as jailbreak hacks. In fact every exploit used in the video was discovered by jailbreak developer and is publicly available for dissection on theiphonewiki.com.
So the way XRY gets access to the device is no secret. But how does it break the passcode? Well that’s no secret either. It’s nothing special is just brute-force. With a mere 10,000 possibilities this makes this a somewhat slow but possible option. Now here’s the important part. This method deteriorates the second you start using a “complex” passcode of any large length.
Now to the technical part of how all of this works. Everything done by XRY can be done with open-source tools. In fact, here’s the link: http://code.google.com/p/iphone-dataprotection/
The iphone-dataprotection project does exactly what XRY does (and more) in a less user-friendly way. They both revolve around publicly available iOS boot exploits to load a custom ramdisk. The XRY ramdisk starts by calling a method to load their logo in img3 format. The open-source version simple lets the code load verbosely. The ramdisk’s load the bare-bones system to mount the data partition and run a basic ssh server to allow remote access. Using usbmux they connect to the ssh server over usb. After that they open the keychain and attempt to guess the passcode. The open-source version of this passcode guessing is available here.
Once the passcode is extracted is is written to stdout in the open-source version or sent to the XRY security app in the proprietary software.
Now the other important part about this is the dependance on a bootrom exploit. There are no public bootrom exploits for the iPhone 4S, iPad 2, and the iPad 3. Yet. These devices are safe. Temporarily. Exploits will be discovered and they will be implemented in these tools and ones like them.
So the most important thing to take away from this is the following:
- Everything done it that video can be done by anybody with access to the internet
- It can be prevented the same way all brute-force attacks can be, increasing the possible permutations.
- Although certain devices ar currently safe, they won’t always be.
Thanks for reading!
Theos with MAS XCode.
I’ve noticed a few people trying to figure out how to get theos working on Lion using the latest XCode install from the Mac App Store. The issue stems from the fact that with the new way XCode is built everything is self-contained in XCode.app. Hence references to locations such as /Developer no longer exist and are instead located at /Applications/XCode.app/Contents/Developer. So applications and utilities that have yet to be updated will struggle to handle this new location. Thankfully, the solution is a simple one:
Run `sudo ln -s /Applications/Xcode.app/Contents/Developer /Developer` to link /Developer to the new location.
Then run `sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/` to tell xcode-build where xcode really is.
An analysis of iOS 5 OTA updates by @innoying
With iOS 5 Apple added some interesting new technology, over the air updates. Although they are not the first to do this, they happen to have done it very well. Or so it would appear from the outside. Actually, the truth offers a somewhat different story. Here is my attempts at reversing the OTA update process and my explanation of one of the exploits I found as a result.
First, we must find out who, what, and how the iOS devices checks for and downloads OTA updates. Unfortunately, as is becoming alarmingly common, the OTA updates components in iOS ignore the system-wide proxy settings. These settings allow easy access to debug connections made by a device and begin the process of reversing it. It’s seems as though Apple is making it’s system Applications ignore these settings more and more often. If this is intentional or not, it forces us to find another way analyze the internal workings.
So I turned to DNS Spoofing. DNS Spoofing is a method of returning modified DNS information to devices with the intent to re-direct traffic. In this case I used dnsmasq to redirect all requests to any site to my mac which was acting as a server. I then used a combination of Apache with custom logging enabled and a node.js debugging server to find the protocols and locations of the required resources.
As it turns out, it’s just HTTP requests. The alarm bells should be going off now. So you’re telling me that the part of the O.S. that runs as root and replaces system files is downloaded via unsecured, unauthenticated HTTP? Yup.
So in my reversing of the connections made by the OTA updates software I discovered the internal URLs used for all OTA update files. So lets start with the basics, the “documentation.” The documentation files are what the user is presented with during the course of the OTA update files. This includes the license, description, title, etc.
The OTA update components get this information from http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/com_apple_MobileAsset_SoftwareUpdateDocumentation.xml which contains the list of documentation files linked to firmware versions. The file is a Apple plist served using the xml mime-type (a plist is a type of xml file). The structure of the file is this:
Root (plist)>
Assets (array)>
Device (string)
OSVersion (string)
_DownloadSize (integer)
_MasteredVersion (string)
_Measurement (base 64 encoded data)
_MeasurementAlgorithm (string)
_UnarchivedSize (integer)
__BaseURL (string)
__RelativePath (string)
Certificate (base 64 encoded data)
FormatVersion (integer)
LastRefreshed (date)
Signature (base 64 encoded data)
SigningKey (string)
I have attempted to explain, to the best of my knowledge, each of these keys below:
Device: The device "model" being either "iPad", "iPod" or "iPhone"
OSVersion: The version number of the new OS.
_DownloadSize: The size of the zipped downloaded in bits
_MasteredVersion: Unknown. Probably a internal marker of which revision of some type.
_Measurement: The checksum value of the downloaded zip file. Checksum type is dictated by _MeasurementAlgoritm
_MeasurementAlgorithm: The algorithm used to calculate _Measurement
_UnarchivedSize: The rough estimate size of the download after un-zipped. This is used to check that enough free-space is available before download.
__BaseURL: The first half of the URL. It is prepended to __RelativePath to create the full download URL.
__RelativePath: The second half of the URL. It is appended to __BaseURL to create the full download URL. It is also used to define the download location on device.
Certificate: The OTA certificate. I believe it is here to use as a check against the on-device copy to verify that is has not changed.
FormatVersion: The version of the format used in the file.
Signature: The signature of the entire file that is checked using the certificate on-device defined by SigningKey
SigningKey: The name of the certificate used to create the Signature that is used to verify the authenticity of the file
After some more research I concluded it was not possible to modify that file nor to spoof a fake download due to the measurement checksum checks. Next I began to look at the documentation file itself. By combining the __BaseURL and __RelativePath manually one can create the url needed to download a documentation file. After downloading a iPod documentation file, I was pleased to find it was a simple, un-encrypted zip file.
Within the file I found this file tree:
AssetData/*.lproj/documentation.strings
AssetData/*.lproj/License.html
AssetData/*.lproj/ReadMe.html
AssetData/*.lproj/ReadMeSummary.html
Info.plist
version.plist
The * represents the different Apple language codes/names. The documents within that folder contain the translations in the language described in the folder title. Now, to analysis the files. I’d like to start with version.plist. It’s structure is the following:
Root (plist)>
BuildVersion (string)
CFBundleShortVersionString (string)
ProjectName (string)
SourceVersion (string)
From what I can tell this file is unused on-device and appears to be left there for convenience or another purpose. So we move on the Info.plist. It’s structure is the following:
Root (plist)>
CFBundleIdentifier (string)
CFBundleName (string)
CFBundleDevelopmentRegion (string)
CFBundleInfoDictionaryVersion (string)
CFBundleShortVersionString (string)
MobileAssetProperties (dictionary)>
OSVersion (string)
Device (string)
The file would appear to be a standard Info.plist with the addition of the MobileAssetProperties dictionary. This dictionary appears to have the same values containing the new software version number and device. So I looked at AssetsData/*.lproj/documentation.strings next. It is in standard .strings format and contains 1 definition. The file sets the “HumanReadableUpdateName” which is displayed at the header of the OTA settings panel. The remaining files serve a similar purpose and are pretty self-explanatory.
Now here’s a little trick I figured out to help me understand what exactly was happening during OTA update install. Due to filesystem checks (which are explained later) it is difficult to install an OTA update while jailbroken. To get around this annoying check, one can download a OTA update, not install, then jailbreak and examine the files. This was the method used to do a good portion of the research within…
Using the above method one can also modify certain files once jailbroken. As a little experiment you can edit files within /var/mobile/Library/Assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/ to produce OTA updates for iOS 6 or whatever one may desire.
Also using the above method I discovered that the file is initially downloaded /var/mobile/Library/Assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/com_apple_MobileAsset_SoftwareUpdateDocumentation.xml then stripped of all information not pertaining to the current device and re-saved to com_apple_MobileAsset_SoftwareUpdateDocumentation.plist
I then moved on to the OTA updates themselves. They are fetched from http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml for use. The structure is very similar to the documentation file with a few modifications:
Root (plist)>
Assets (array)>
Build (string)
InstallationSize (string)
MinimumSystemPartition (integer)
OSVersion (string)
PrerequisiteBuild (string)
PrerequisiteOSVersion (string)
SUProductSystemName (string)
SUPublisher (string)
SupportedDevices (array) >
Device (string)
SystemPartitionPadding (dictionary) >
16 (integer)
32 (integer)
8 (integer)
_DownloadSize (integer)
_Measurement (base 64 encoded data)
_MeasurementAlgorithm (string)
_UnarchivedSize (integer)
__BaseURL (string)
__RelativePath (string)
Certificate (base 64 encoded data)
FormatVersion (integer)
LastRefreshed (date)
Signature (base 64 encoded data)
SigningKey (string)
Unless otherwise stated the definitions are the same as the documentation file:
Build: Build name/id
InstallationSize: Finished installation size
MinimumSystemPartition: The required partition size before continuing.
PrerequisiteBuild: The needed Build for install
PrerequisiteOSVersion: The needed OS version for install
SU*: Standard Apple plist stuff
SupportedDevices: The devices this update supports
SystemPartitionPadding: No clue. Maybe space on flash that root is padded
The rest is self explanatory if not mentioned above. So now the final important part. The actual update. I’ll start with the file. Using the combined __BaseURL and __RelativePath we can construct the URL to download. If we download one of theses files we will find it i a un-uncrypted zip file. Now this is interesting. Apple tends to avoid un-encrypted system stuff as it can make exploiting stuff easier. They must have decided against this to keep files size and processing intensity down.
Once we decrypt this file, which is saved (once unzipped) to /var/mobile/Library/Assets/com_apple_MobileAsset_SoftwareUpdate/*.asset, we can discover how OTA updates work. The unzipped file follows the following structure:
Root>
AssetData>
Info.plist
boot>
*.dmg
BuildManifest.plist
Firmware>
all_flash>
(standard ipsw format files)
dfu>
(standard ipsw format files)
usr>
(standard ipsw format files)
kernelcache.release.*
payload>
patches>
(actual path on device)/*.patch
replace>
(actual path on device)/(actual new replacement file)
added>
(actual path on device)/(actual new file)
payload.bom
payload.bom.signature
post.bom
pre.bom
Info.plist
The root Info.plist file appears to be the same as the documentation Info.plist in use. The Info.plist file within AssetData contains the information about specifics of the update.
Now the boot folder very closely resembles the folder within ipsw firmware files. It contains applelogo and similar files.
The payload folder contains the filesystem modifications to make. The patches folder contains patches in BSDiff format. The added and replace sub-folders contain the new files instead of BSDiffs.
The authenticity of the payload folder is checked by payload.bom. The file is in the Mac OSX bill of materials format. Using a Mac one can list the contents of this file using the `lsbom` utility. It contains checksums, permissions, etc that are checked. It also checks the authenticity of pre.bom and post.bom.
The authenticity of payload.bom is verified by payload.bom.signature which is the signature of the payload.bom file that is checked against the internal certificates.
The pre.bom and post.bom contain snapshots of how the root filesystem should look before and after installation. This is what prevents users from installing OTA updates with a jailbroken device.
I hope this helps anybody who was or is interested in how OTA updates work. Use this knowledge for good not evil. If you do find any security bugs as a result of this research I would suggest you send those bugs to a jailbreak development team (either chronic-dev or iphone-dev) to help further jailbreaks that make research like this possible.
An update on node.js on iOS
“Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. ” Node.js is becoming an increasingly popular language that is just bursting with potential. One of the possibilites that I see with great potential is node on embedded devices. Specifically smartphones such as the iPhone. So naturally when I saw @TooTallNate’s post about node.js on iOS I got really excited. And I began using @TooTallNate’s port and playing around with stuff. It was pretty cool. Until the node project underwent quite a few core changes that had a large impact on running node.js on embedded devices. As a result, node for iOS went un-updated for a very long time. As this happened, modules began to loose backwards compatibility. This became extremely frustrating. Just recently @TooTallNate updated his node port to 0.6.5, the latest version of node at the time. Then, a few days later, @rpretrich the infamous iphone dev forked his own copy of node and patched it to cross compile to iOS from a mac. This got me wondering about macs. Not all people who do jailbroken iphone development have one. So I set out to make it possible to use node without having a mac. First, I built a pre-packaged binary for node and @TooTallNate submitted it to the BigBoss Cydia repo. Next, I began to work on a fork that would easily compile on iOS without needing headers from a Mac. Here it is: https://github.com/innoying/node It it currently the latest stable branch from the joyent master. I intend to keep it updated whenever possible. It should run just fine on any (armv7) iOS device. Thanks to projects like these node has a lot of potential on embedded devices. Now the question is… Who will be the first to make use of it?
Hello World
I decided to move away from the old blog.innoying.com written in wordpress. The main reasoning behind this decision, is that I will begin to slowly migrate all of my sites to node.js and I do not wish to re-write my blog from scratch when great services like tumblr are available for free. I will also begin using the blog in an entirely different manner than the old blog was used. It will now simply contain whatever happens to come to my mind, and project updates. This is the proper use for a blog.
Update: The old blog is now available at blogarchive.innoying.com
Update 2: I will be re-posting the content that I feel is important. All other content will be removed and will no longer be available.
