April 17, 2014

Plethora of security updates in iOS 6

(LiveHacking.Com) - Yesterday Apple launched the latest version of its mobile operating system for the iPhone, iPad and iPod Touch. iOS 6 brings new features like Facebook integration and is the default OS for the new iPhone 5 which starts shipping on Friday. The new OS also includes lots of important security fixes.

Included in the fixes is an update to WebKit, the open source HTML rendering engine which Apple created and is also used in Google Chrome. Apple updated iTunes recently with a very similar set of WebKit fixes as those found in iOS 6. Apple describes the WebKit vulnerabilities by saying that “Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution.” Which it explains is due to “multiple memory corruption issues existed in WebKit. These issues are addressed through improved memory handling.”

Other WebKit fixes also include several cross-site scripting fixes and better URL handling. According to Apple the Unicode fonts embedded in Safari could can been used to create a URL which contains look-alike characters. These look-alike characters can be used by a malicious website to direct the user to a spoofed site that visually appears to be a legitimate domain.

Apple also spent some time fixing issues with passcode which can be set from within iOS to stop unwanted access to the device. This included a design flaw in the support for viewing photos that were taken while the screen was locked. Previously to determine which photos should be displayed the passcode lock checked the time at which the device was locked and compared it to the time that a photo was taken. However, by spoofing the current time an attacker could gain access to photos that were taken before the device was locked. To fix this, iOS now explicitly keeps track of the photos that were taken while the device was locked.

Other fixes are:

  • CFNetwork – An issue existed in CFNetwork’s handling of malformed URLs. CFNetwork may send requests to an incorrect hostname, resulting in the disclosure of sensitive information. This issue was addressed through improvements to URL handling.
  • CoreGraphics – Multiple vulnerabilities existed in FreeType, the most serious of which may lead to arbitrary code execution when processing a maliciously crafted font. These issues were addressed by updating FreeType to version 2.4.9. Further information is available via the FreeType site at http://www.freetype.org/
  • CoreMedia – An uninitialized memory access existed in the handling of Sorenson encoded movie files. This issue was addressed through improved memory initialization.
  • DHCP – Upon connecting to a Wi-Fi network, iOS may broadcast MAC addresses of previously accessed networks per the DNAv4 protocol. This issue was addressed by disabling DNAv4 on unencrypted Wi-Fi networks.
  • ImageIO – A buffer overflow existed in libtiff’s handling of ThunderScan encoded TIFF images. This issue was addressed by updating libtiff to version 3.9.5.
  • ImageIO – Multiple memory corruption issues existed in libpng’s handling of PNG images. These issues were addressed through improved validation of PNG images.
  • ImageIO – A double free issue existed in ImageIO’s handling of JPEG images. This issue was addressed through improved memory management.
  • ImageIO – An integer overflow issue existed in libTIFF’s handling of TIFF images. This issue was addressed through improved validation of TIFF images.
  • International Components for Unicode – A stack buffer overflow existed in the handling of ICU locale IDs. This issue was addressed through improved bounds checking.
  • IPSec – A buffer overflow existed in the handling of racoon configuration files. This issue was addressed through improved bounds checking.
  • Kernel – An invalid pointer dereference issue existed in the kernel’s handling of packet filter ioctls. This may allow an attacker to alter kernel memory. This issue was addressed through improved error handling.
  • Kernel – An uninitialized memory access issue existed in the Berkeley Packet Filter interpreter, which led to the disclosure of memory content. This issue was addressed through improved memory initialization.
  • libxml – Multiple vulnerabilities existed in libxml, the most serious of which may lead to an unexpected application termination or arbitrary code execution. These issues were addressed by applying the relevant upstream patches.
  • Mail – A logic issue existed in Mail’s handling of attachments. If a subsequent mail attachment used the same Content-ID as a previous one, the previous attachment would be displayed, even in the case where the 2 mails originated from different senders. This could facilitate some spoofing or phishing attacks. This issue was addressed through improved handling of attachments.
  • Mail – A logic issue existed in Mail’s use of Data Protection on email attachments. This issue was addressed by properly setting the Data Protection class for email attachments.
  • Mail – S/MIME signed messages displayed the untrusted ‘From’ address, instead of the name associated with the message signer’s identity. This issue was addressed by displaying the address associated with the message signer’s identity when it is available.
  • Messages – When a user had multiple email addresses associated with iMessage, replying to a message may have resulted in the reply being sent from a different email address. This may disclose another email address associated to the user’s account. This issue was addressed by always replying from the email address the original message was sent to.
  • Office – Viewer An information disclosure issue existed in the support for viewing Microsoft Office files. When viewing a document, the Office Viewer would write a temporary file containing data from the viewed document to the temporary directory of the invoking process. For an application that uses data protection or other encryption to protect the user’s files, this could lead to information disclosure. This issue was addressed by avoiding creation of temporary files when viewing Office documents.
  • OpenGL – Multiple memory corruption issues existed in the handling of GLSL compilation. These issues were addressed through improved validation of GLSL shaders.
  • Passcode Lock – A logic issue existed with the display of the “Slide to Power Off” slider on the lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A logic issue existed in the termination of FaceTime calls from the lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A design issue existed in the support for viewing photos that were taken at the lock screen. In order to determine which photos to permit access to, the passcode lock consulted the time at which the device was locked and compared it to the time that a photo was taken. By spoofing the current time, an attacker could gain access to photos that were taken before the device was locked. This issues was addressed by explicitly keeping track of the photos that were taken while the device was locked.
  • Passcode Lock – A logic issue existed in the Emergency Dialer screen, which permitted FaceTime calls via Voice Dialing on the locked device. This could also disclose the user’s contacts via contact suggestions. This issue was addressed by disabling Voice Dialing on the Emergency Dialer screen.
  • Passcode Lock Using the camera from the screen lock could in some cases interfere with automatic lock functionality, allowing a person with physical access to the device to bypass the Passcode Lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A state management issue existed in the handling of the screen lock. This issue was addressed through improved lock state management.
  • Restrictions – After disabling Restrictions, iOS may not ask for the user’s password during a transaction. This issue was addressed by additional enforcement of purchase authorization.
  • Safari – Websites could use a Unicode character to create a lock icon in the page title. This icon was similar in appearance to the icon used to indicate a secure connection, and could have lead the user to believe a secure connection had been established. This issue was addressed by removing these characters from page titles.
  • Safari – Password input elements with the autocomplete attribute set to “off” were being autocompleted. This issue was addressed through improved handling of the autocomplete attribute.
  • System Logs – Sandboxed apps had read access to /var/log directory, which may allow them to obtain sensitive information contained in system logs. This issue was addressed by denying sandboxed apps access to the /var/log directory.
  • Telephony – Messages displayed the return address of an SMS message as the sender. Return addresses may be spoofed. This issue was addressed by always displaying the originating address instead of the return address.
  • Telephony – An off-by-one buffer overflow existed in the handling of SMS user data headers. This issue was addressed through improved bounds checking.
  • UIKit – Applications that use UIWebView may leave unencrypted files on the file system even when a passcode is enabled. This issue was addressed through improved use of data protection.
  • WebKit – A cross-origin issue existed in the handling of CSS property values. This issue was addressed through improved origin tracking.
  • WebKit – A cross-origin issue existed in the handling of iframes in popup windows. This issue was addressed through improved origin tracking.
  • WebKit – A cross-origin issue existed in the handling of iframes and fragment identifiers. This issue was addressed through improved origin tracking.
  • WebKit – The International Domain Name (IDN) support and Unicode fonts embedded in Safari could have been used to create a URL which contains look-alike characters. These could have been used in a malicious website to direct the user to a spoofed site that visually appears to be a legitimate domain. This issue was addressed by supplementing WebKit’s list of known look-alike characters. Look- alike characters are rendered in Punycode in the address bar.
  • WebKit – A canonicalization issue existed in the handling of URLs. This may have led to cross-site scripting on sites which use the location.href property. This issue was addressed through improved canonicalization of URLs.
  • WebKit – An HTTP header injection issue existed in the handling of WebSockets. This issue was addressed through improved WebSockets URI sanitization.
  • WebKit – A state management issue existed in the handling of session history. Navigations to a fragment on the current page may cause Safari to display incorrect information in the URL bar. This issue was addressed through improved session state tracking.
  • WebKit – An uninitialized memory access issue existed in the handling of SVG images. This issue was addressed through improved memory initialization.

Will Apple fix SMS spoofing flaw before iOS 6 is released?

(LiveHacking.Com) – As demonstrated many times, social engineering is a key method used by hackers to solicit personal information from victims and now, due to a new SMS spoofing flaw which has been discovered on the iPhone, users need to be extra careful about trusting text messages they receive on their phones.

Security researcher “pod2g” has found a serious flaw in the way iOS processes SMS messages that leaves iPhone users open to spoofing.

This means that an attacker can spoof messages from a victim’s bank asking them for some private information, or linking to phishing website and, because of the flaw, the message look genuine. Also false messages can be sent to a device and used as false evidence. In fact, pod2g writes that the spoofing can be use to do “anything you can imagine that could be utilized to manipulate people, letting them trust somebody or some organization [that] texted them.”

This flaw has existed since 2007, when the first iPhone was released, and still hasn’t been addressed with iOS 6  beta 4.

SMS messages are converted to complex PDU (Protocol Description Unit) packets  for delivery. As part of the payload, a section called UDH (User Data Header) allows the sender to add a reply-to number. If included, any replies written by the receiver will be sent to that number rather than the original number.

The problem with the iPhone SMS app is that the reply-to address is displayed rather than the genuine originator number. This means a message can be sent from one device and made to look like it came from another. What should happen is that if the reply-to and originator numbers are different both should be shown or a warning displayed.

Tools exist for smartphones and even online for sending raw PDU messages meaning that these fake messages are relatively easy to generate.

“Apple takes security very seriously,” representatives from the Cupertino, Calif.-based company told The Verge on Saturday. “When using iMessage instead of SMS, addresses are verified which protects against these kinds of spoofing attacks.”

“Now you are alerted. Never trust any SMS you received on your iPhone at first sight,” wrote pod2g.

The question now remains, will Apple fix this before iOS 6 is released?

iOS 5.1.1 Fixes Address Bar Spoofing Vulnerability and WebKit Bugs

(LiveHacking.Com) – Apple have released iOS 5.1.1 for the iPhone, iPad and iPod Touch to add improvements and bug fixes while fixing a number of critical security vulnerabilities.

The first vulnerability fixed is the address bar spoofing bug which we reported on back in March. David Vieira-Kurz of MajorSecurity discovered an address bar spoofing vulnerability in WebKit  that allows an attacker to manipulate the address bar in the browser and take the user to a malicious site with a fake (but genuine looking) URL showing. The vulnerability is caused due to an error in the handling of URLs when using javascript’s window.open() method.

The next vulnerability fixed by Apple is the cross-site scripting issue found by Sergey Glazunov that earned him $60,000 from Google under its Pwnium: rewards for exploits contest. Details of the exact nature of Sergey’s exploit are still unavailable but it is known that WebKit doesn’t properly handle history navigation, which allows remote attackers to execute arbitrary code by leveraging a “Universal XSS (UXSS)” issue.

The final fix is also shrouded in mystery. CVE-2012-0672, which was found by Adam Barth and Abhishek Arya of the Google Chrome Security Team, is a memory corruption issue in WebKit that, if exploited, would allow an attacker to create a malicious website that could crash Safari or execute arbitrary code. However that is all that is known!

iOS 5.1.1 is available for the  iPhone 3GS, iPhone 4, iPhone 4S, iPod touch (3rd generation) and later, iPad and iPad 2.

Has Skype for iOS Vulnerability Been Fixed?

(LiveHacking.Com) - A new version of Skype (3.5.84) for the iPhone and iPad appeared in the App Store yesterday with lots of new features like Bluetooth support and image stabilization. But the “What’s New” section also mentions “Bugfix for security vulnerability.” Currently Skype are keeping quiet about exactly which “security vulnerability” has been fixed, however it is most likely to be the Cross-Site Scripting vulnerability found in the “Chat Message” window which could allow an attacker to download a copy of the phone’s address book.

The vulnerability, which was found last week, can be exploited by simply sending a specially crafted chat message to a Skype user. Skype uses a locally stored HTML file to display chat messages from other users, however it doesn’t properly encode the incoming users “Full Name”. The result is that an attacker can create some  malicious JavaScript code that runs when the victim views the message.

Skype has a published a blog post about the new iOS version where it explains the new anti-shake feature and the support for Bluetooth, however it mentions nothing about the security fix.

It is recommended that every iPhone/iPad Skype user updates to this new version but it is also worth noting that there have been reports of problems with the new version including 1) Skype Credit not showing 2) Contacts slow to sync 3) Account settings (e.g. photo, name, profile) not appearing.

To remedy these, Skype suggest deleting your Skype app and starting a new installation from scratch. To delete the app, press and hold the app icon on your iPhone, and click the ‘X’. To re-install, return to the AppStore, and install.

iOS 4.3.5 Patches X.509 Certificate Validation Vulnerability

(LiveHacking.Com) – Less than two weeks ago Apple released iOS 4.3.4 to fix a PDF vulnerability and now it has issued iOS 4.3.5 to patch a X.509 certificate validation vulnerability.

According to Apple the vulnerability allows an attacker with a privileged network position to capture or modify data in sessions protected by SSL/TLS.

A certificate chain validation issue existed in the handling of X.509 certificates. This issue is fix through improved validation of X.509 certificate chains.

iOS 4.3.5 is available for the iPhone 3GS & iPhone 4 (GSM model), the iPod touch (3rd generation and later) and the iPad & iPad 2.

Apple Releases iOS 4.3.4 to Fix Vulnerabilities – Jailbreakers Quick to React

(LiveHacking.Com) — Apple has released iOS 4.3.4 for the iPhone 3GS, the iPhone 4 (GSM model), the iPod touch (3rd generation and later) and for the iPad. The main purpose of iOS 4.3.4 is to close a hole in the PDF viewer which is used by JailBreakMe.com. It allowed users to jailbreak any iDevice (including iPad 2) through the website.

Specifically iOS 4.3.4 deals with the following security issues:

  • Viewing a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution. – A buffer overflow exists in FreeType’s handling of TrueType fonts. Viewing a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution.
  • Viewing a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution. – A signedness issue exists in FreeType’s handling of Type 1 fonts. Viewing a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution.
  • Malicious code running as the user may gain system privileges. – An invalid type conversion issue exists in the use of IOMobileFrameBuffer queueing primitives, which may allow malicious code running as the user to gain system privileges.
The update renders the JailBreakMe.com jail break useless. However users running 4.3.3 can still use the site to jailbreak their devices. However the Redmond Pie web site has posted details on a tethered jailbreak for iOS 4.3.4 using the PwnageTool. A tethered jailbreak means that if your device loses power or restarts then you would have to boot it into the jailbroken state again while connected to your desktop computer.

Top 10 Passcodes to Avoid Using on Your iPhone

Daniel Amitay, the developer of Big Brother Camera Security, added some code his app to anonymously record common user passcodes and the results are quite interesting. The app collected 204,508 passcodes and Daniel discovered that 10 common passcodes were used in over 15% of the cases. This means that you have a greater than 1 in 10 chance of breaking into someones cell phone by just trying the ten most common passcodes listed below.

  1. 1234 – 8,884 uses or 4.34%
  2. 0000 – 5, 246 or 2.5%
  3. 2580 – 4,753
  4. 1111 – 3,262
  5. 5555 – 1,774
  6. 5683 – 1,425
  7. 0852 – 1,221
  8. 2222 – 1,139
  9. 1212 – 944
  10. 1998 – 822

As expected, 1234 is the most common passcode and the other passcodes follow typical formulas, such as four identical digits (0000,1111,5555,2222) or moving in a line up or down the pad (2580 & 0852). 5683 isn’t instantly clear, but if you look carefully at the letters on the numbers you will see it spells “love”.

In 2010 Imperva released a study analyzing 32 million passwords and found that the 10 most commonly used passwords for computers and Internet accounts were:

  • 123456
  • 12345
  • 123456789
  • Password
  • iloveyou
  • princess
  • rockyou
  • 1234567
  • 12345678
  • abc123

ElcomSoft Breaks iOS 4 Encryption – Offers New Forensic Service

ElcomSoft have succeeded in decrypting the iPhone’s encrypted file system under iOS 4 and are making it available exclusively to law enforcement, forensic and intelligence agencies.

This is a major feat as since the launch of the iPhone 3GS, Apple have included hardware encryption in all of its devices (including the iPhone 4 and iPad). iOS 4 enabled this hardware-based encryption to encrypt all user data stored using AES-256. This encryption was thought to be strong enough to resist even the best equipped adversaries, including forensic analysts and law enforcement agencies.

ElcomSoft have found a way to decrypt bit-to-bit images of iOS 4 devices. Decrypted images are perfectly usable, and can be analyzed with forensic tools. But decryption is only possible with the actual device available because the decryption relies on getting the keys that are stored on it.

Analysis
What is interesting (and worrying) is what ElcomSoft found stored inside the iPhone. According to them “iPhone devices store or cache humungous amounts of information about how, when, and where the device has been used. The amount of sensitive information collected and stored in Apple smartphones is beyond what had previously been imaginable. Pictures, emails and text messages included deleted ones, calls placed and received are just a few things to mention. A comprehensive history of user’s locations complete with geographic coordinates and timestamps. Google maps and routes ever accessed. Web browsing history and browser cache, screen shots of applications being used, usernames, Web site passwords and the password to iPhone backups made with iTunes software, and just about everything typed on the iPhone is being cached by the device.”

Apple Releases iOS 4.3.3 to Fix Locationgate Bugs

iOS 4.3.3 has been released to fix the so-called Locationgate tracking bugs that have caused Apple so much recent controversy. This update fixes the bugs which caused iPhones to store up to a years worth of cell tower information which is then synced with iTunes.

A few weeks ago Alasdair Allan and Pete Warden released a proof-of-concept application for Mac OS X that demonstrates how the iPhone is tracking its location.

Apple responded with a press release saying that the iPhone is not logging its location. Rather, it’s maintaining a database of Wi-Fi hotspots and cell towers to help the phone rapidly and accurately calculate its location when requested. In other words a cache. They also promised a software update which is what has been released today.

The update contains changes to how iOS manages this crowd-sourced location database cache. Specifically the update:

  • Reduces the size of the cache
  • No longer backs up the cache to iTunes
  • Deletes the cache entirely when location services is turned off

Apple to Issue Software Update to Clear Cell Tower Cache

In the continuing controversy, that has now been dubbed Locationgate, about iPhones storing up to a years worth of cell tower information and syncing this with iTunes, Apple has now issued a press release to try and clarify the situation. In summary Apple is saying that the iPhone is not logging its location. Rather, it’s maintaining a database of Wi-Fi hotspots and cell towers to help the phone rapidly and accurately calculate its location when requested. In other words a cache.

The press release also deals with why this cache contains entries for more than a year. Apples answer, “the reason the iPhone stores so much data is a bug.” According to ZDNet, Scott Forstall (the senior vice president of iOS Software) has revealed that the problem is actually the size of the cache and not explicitly how long it holds entries for, “we picked a size, around 2MB, which is less than half a song. It turns out it was fairly large and could hold items for a long time.”

OK, but when a user turns off Location Services, why does the iPhone sometimes continue updating its Wi-Fi and cell tower data?  Apple says, “It shouldn’t. This is a bug, which we plan to fix shortly.”

Apple’s argument is that it is legitimate to store cell tower information on a short term basis n the phone but because of bugs in iOS too much data is being stored. Apple is promsing an update to iOS in the near future which will

  • reduce the size of the crowd-sourced Wi-Fi hotspot and cell tower database cached on the iPhone,
  • cease backing up this cache, and
  • delete this cache entirely when Location Services is turned off.

Apple is also promising that in the next major iOS software release (4.4? 5.0?) the cache will also be encrypted on the iPhone.

So is this the end of Locationgate? Please comment below.