Connect with us


Warning Issued For Apple’s 1.4 Billion iPad And iPhone Users



Apple is having a bad month. To date, the company’s “user-hostile” iPhone battery practices were exposed, Face ID hacked, iOS code exploited (twice) and the iPhone 11’s final secrets revealed. And now things just got a lot worse. 

Every iPhone ever made faces a Catch-22 security problem, including Apple’s headlines iPhone XS, XS Max and iPhone XR APPLE

Today researchers have publicized the ‘KNOB Attack’ which impacts billions of iOS and Android devices around the world. But while Google has already patched the problem and started the rollout out to devices, iPhone and iPad users are not so lucky because a bizarre mistake by Apple has left them with nowhere to go. 

KNOB stands for ‘Key Negotiation of Bluetooth’ (terrible acronym, I know) and what it amounts to is a clever, “brute force” attack on “any standard-compliant Bluetooth device”. It works remotely by exploiting a flaw in the Bluetooth encryption key protocol to force through small packets of data which give the hacker access to your device. And because its a flaw inherent to Bluetooth, everyone is vulnerable.

“We conducted KNOB attacks on more than 17 unique Bluetooth chips (by attacking 24 different devices),” explained the researchers. “At the time of writing, we were able to test chips from Broadcom, Qualcomm, Apple, Intel, and Chicony manufacturers. All devices that we tested were vulnerable to the KNOB attack.”

But here’s why it’s so much worse for iPhone and iPad users: in its security notes Apple confirmed the “iPhone 5s and later, iPad Air and later, and iPod touch 6th generation and later” (aka every iOS 11 and iOS 12 compatible device dating back to 2013) are vulnerable to it and a patch was issued in iOS 12.4 (bug code CVE-2019-9506). But, in case you have been living under a rock, iOS 12.4 contains a staggering exploit which allows hackers to remotely jailbreak your iPhones and install malicious code. 

Major publicly known exploits mean iPhone and iPad users are not currently safe on any version of Apple iOS 12 APPLE

Consequently, every supported iPhone or iPad is vulnerable to the KNOB Attack if they are not running iOS 12.4 and every device which has upgraded to it is vulnerable to a remote attack which is just as bad. 

Are you running a very old iPhone or iPad and feeling smug? Don’t. Not only is every iOS device ever made running standard-compliant Bluetooth, making them all vulnerable to KNOB, old devices are no longer supported meaning they are unlikely to be patched. So when, in January, Tim Cook statedthere are 1.4BN active iOS devices around the world, that’s how many are vulnerable to this Catch-22 situation right now. 

For Apple, releasing iOS 12.4.1 must now be their top priority to give users an escape route, as well as emergency upgrades for iOS 9 and 10 (it has happened before). That said, so far Apple has remained silent about the iOS 12.4 exploit and iOS 12.4.1 has not been seen in beta testing so there is currently no timeframe for a fix. Meanwhile, iOS 13 will arrive next month and it drops support for multiple generations of devices, which means it’s time for the company to step up. 

Your move, Apple. 


Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Malicious Android apps containing Joker malware set up shop on Google Play




A new malware campaign has managed to infiltrate the official Google Play store to deploy the Joker Trojan to Android devices in a bid to conduct ad fraud. 

Last week, security researcher Aleksejs Kuprins from cybersecurity threat intelligence firm CSIS Security Group said the surge of malicious activity has been tracked in recent weeks, leading to the discovery of 24 Android applications containing the malware. 

In total, the applications — made available through Google Play — have been installed over 472,000 times by unwitting Android handset owners. 

The malicious applications contained a Trojan dubbed Joker by the cybersecurity firm, a name that references one of the domain names connected to the operator’s command-and-control (C2) server. 

Joker attempts to remain silent and undetected on infected devices by making use of as little JavaScript code as possible and locking down its code through obfuscation techniques. In many cases, the malware has been integrated within advertising frameworks linked to its malicious apps. 

The malicious code contains the usual list of Trojan functions including the theft of SMS messages, contact information, and device data, and constantly pings its C2 for commands. However, Joker goes further by attempting to generate profit for its operator through fraudulent advertising activity. 

Joker is able to interact with ad networks and websites by simulating clicks and silently signing up victims for premium services. In one example, Joker signed up users in Denmark for a premium website service costing roughly 7 euros a week by simulating clicks on the website, automatically entering the operator’s offer codes, and extracting confirmation codes from SMS messages sent to the target device. These codes are then submitted to the ad website to complete the process. 

In other cases, the malware may simply send SMS messages to premium numbers. 

Each fraudulent ‘job’ is received from the C2 and once premium service signups are complete, Joker informs the C2 and awaits further instructions. 

Joker’s operators focus on 37 specific countries as targets, including China, the UK, Germany, France, Singapore, and Australia. Many of the infected apps found by the researchers contain a list of Mobile Country Codes (MCC) and the SIM card on an infected device has to relate to acceptable MCC for Joker to execute. 

Most of these applications will not deploy the malware if users are in the United States or Canada; however, a handful of them do not contain any country restrictions. 

When it comes to Joker’s attribution, nothing has been set in stone, but the interface of the C2’s administration panel and some of the bot’s coding indicate that the developers of the malware could be Chinese. 

While the number of installs is relatively high, without the need for disclosure from the researchers, Google has detected and removed all of the malicious apps from Google Play. Malware creeping into official app repositories is a constant challenge, but in this case, the CSIS Security Group says the tech giant “seems to be on top of this threat as much as it is possible.”


Continue Reading


How Safari and iMessage Have Made iPhones Less Secure




The security reputation of iOS, once considered the world’s most hardened mainstream operating system, has taken a beating over the past month: Half a dozen interactionless attacks that could take over iPhones without a click were revealed at the Black Hat security conference. Another five iOS exploit chains were exposed in malicious websites that took over scores of victim devices. Zero-day exploit brokers are complaining that hackers are glutting the market with iOS attacks, reducing the prices they command.

As Apple prepares for its iPhone 11 launch on Tuesday, the recent stumbles suggest it’s time for the company to go beyond fixing the individual security flaws that have made those iPhone attacks possible, and to instead examine the deeper issues in iOS that have produced those abundant bugs. According to iOS-focused security researchers, that means taking a hard look at two key inroads into an iPhone’s internals: Safari and iMessage.

While vulnerabilities in those apps offer only an initial foothold into an iOS device—a hacker still has to find other bugs that allow them to penetrate deeper into the phone’s operating system—those surface-level flaws have nonetheless helped to make the recent spate of iOS attacks possible. Apple declined to comment on the record.

“If you want to compromise an iPhone, these are the best ways to do it,” says independent security researcher Linus Henze of the two apps. Henze gained notoriety as an Apple hacker after revealing a macOS vulnerability known as KeySteal earlier this year. He and other iOS researchers argue that when it comes to the security of both iMessage and WebKit—the browser engine that serves as the foundation not just of Safari but all iOS browsers—iOS suffers from Apple’s preference for its own code above that of other companies. “Apple trusts their own code way more than the code of others,” says Henze. “They just don’t want to accept the fact that they make bugs in their own code, too.”

Caught in a WebKit

As a prime example, Apple requires that all iOS web browsers—Chrome, Firefox, Brave, or any other—be built on the same WebKit engine that Safari uses. “Basically it’s just like running Safari with a different user interface,” Henze says. Apple demands browsers use WebKit, Henze says, because the complexity of running websites’ JavaScript requires browsers to use a technique called just-in-time (or JIT) compilation as a time-saving trick. While programs that run on an iOS device generally need to be cryptographically signed by Apple or an approved developer, a browser’s JIT speed optimization doesn’t include that safeguard.

As a result, Apple has insisted that only its own WebKit engine be allowed to handle that unsigned code. “They trust their own stuff more,” Henze says. “And if they make an exception for Chrome, they have to make an exception for everyone.”

“They should assume their own code has bugs.”


The problem with making WebKit mandatory, according to security researchers, is that Apple’s browser engine is in some respects less secure than Chrome’s. Amy Burnett, a founder of security firm Ret2 who leads trainings in both Chrome and WebKit exploitation, says that it’s not clear which of the two browsers has the most exploitable bugs. But she argues that Chrome’s bugs are fixed faster, which she credits in part to Google’s internal efforts to find and eliminate security flaws in its own code, often through automated techniques like fuzzing.

Google also offers a bug bounty for Chrome flaws, which incentivizes hackers to find and report them, whereas Apple offers no such bounty for WebKit unless a WebKit bug is integrated into an attack technique that penetrates deeper into iOS. “You’re going to find similar bug classes in both browsers,” says Burnett. “The question is whether they can get rid of enough of the low hanging fruit, and it seems like Google is doing a better job there.” Burnett adds that Chrome’s sandbox, which isolates the browser from the rest of the operating system, is also “notoriously” difficult to bypass—more so than WebKit’s—making any Chrome bugs that do persist less useful for gaining further access to a device.

Shady References

Another specific element of WebKit’s architecture that can result in hackable flaws, says Luca Todesco, an independent security researcher who has released WebKit and full iOS hacking techniques, is its so-called document object model, known as WebCore, which WebKit browsers use to render websites. WebCore requires that a browser developer keep careful track of which data “object”—anything from a string of text to an array of data—references another object, a finicky process known as “reference counting.” Make a mistake, and one of those references might be left pointing at a missing object. A hacker can fill that void with an object of their choosing, like a spy who picks up someone else’s name tag at a conference registration table.

By contrast, Chrome’s own version of WebCore includes a safeguard known as a “garbage collector” that cleans up pointers to missing objects, so they can’t be mistakenly left unassigned and vulnerable to an attacker. WebKit by contrast uses an automated reference counting system called “smart pointers” that Todesco argues still leaves room for error. “There’s just so many things that can potentially happen, and in WebCore the browser developer has to keep track of all these possibilities,” Todesco says. “It’s impossible not to screw up.”

To Apple’s credit, iOS has for more than a year implemented a security mitigation called isolated heaps, or “isoheaps,” designed to make errors in reference counting impossible to exploit, as well as newer mitigations in the hardware of the iPhone XS, XS Max, and XR. But both Todesco and Burnett note that while isolated heaps significantly improved WebCore’s security and pushed many hackers towards attacking different parts of WebKit, they didn’t entirely prevent attacks on WebCore. Todesco says there have been multiple exploiting reference counting errors since isoheaps were introduced in 2018. “You can’t say they’re eliminated,” Ret2’s Burnett agrees.

Despite all those issues, and even as WebKit’s flaws have served as the entry point for one iOS attack after another, it’s debatable whether WebKit is measurably less secure than Chrome. In fact, a price chart from Zerodium, a firm which sells zero-day hacking techniques, values Chrome and Safari attacks equally. But another zero-day broker, Maor Shwartz, told WIRED by contrast that WebKit’s insecurity relative to Chrome contributed directly to top prices for an Android exploit surpassing those for iOS. “Chrome is the most secure browser today,” Shwartz says. “The prices are aligned with that.”

Getting the Message

Hackable flaws in iMessage are far rarer than those WebKit. But they’re also far more powerful, given that they can be used as the first step in a hacking technique that takes over a target phone with no user interaction. So it was all the more surprising last month to see Natalie Silvanovich, a researcher with Google’s Project Zero team, expose an entire collection of previously unknown flaws in iMessage that could be used to enable remote, zero-click takeovers of iPhones.

More disturbing than the existence of those individual bugs was that they all stemmed from the same security issue: iMessage exposes to attackers its “unserializer,” a component that essentially unpacks different types of data sent to the device via iMessage. Patrick Wardle, a security researcher at Apple-focused security firm Jamf, describes the mistake as something like blindly opening a box sent to you full of disassembled components, and reassembling them without an initial check that they won’t add up to something dangerous. “I could put the parts of a bomb in that box,” says Wardle. “If Apple is allowing you to unserialize all these objects, that exposes a big attack surface.”


How Safari and iMessage Have Made iPhones Less Secure
The WIRED Guide to the iPhone

More fundamentally, iMessage has innate privileges in iOS that other messaging apps are denied. In fact, non-Apple apps are cordoned off from the rest of the operating system by rigorous sandboxes. That means that if a third-party app like WhatsApp is compromised, for instance, a hacker still has to break through its sandbox with another, distinct technique to gain deeper control of the device. But Project Zero’s Silvanovich noted in her writeup of the iMessage flaws that some of iMessage’s vulnerable components are integrated with SpringBoard, iOS’s program for managing a device’s home screen, which Silvanovich writes has no sandbox at all.

“What I personally can’t understand is why they don’t sandbox it more,” Linus Henze says of iMessage. “They should assume their own code has bugs, and make sure their code is sandboxed in the same way they sandbox the code of other developers, just as they do with WhatsApp or Signal or any other app.”

Apple, after all, built the iPhone’s sterling reputation in part by carefully restricting what apps it allowed into its App Store, and even then carefully isolating those apps within the phone’s software. But to head off these high-profile incidents, it may need to reexamine that security caste system—and ultimately, to treat its own software’s code with the same suspicion it has always cast on everyone else’s.


Continue Reading


Security hole opens a billion Android users to advanced SMS phishing attacks




Check Point Research has revealed a security flaw in Samsung, Huawei, LG, Sony and other Android-based phones that leaves users vulnerable to advanced phishing attacks.

The affected Android phones use over-the-air (OTA) provisioning, which allows mobile network operators to deploy network-specific settings to a new phone joining their network. However, researchers found that the industry standard for OTA provisioning, the Open Mobile Alliance Client Provisioning (OMA CP), includes limited authentication methods. This can be exploited, enabling hackers to pose as network operators and send deceptive OMA CP messages to users.

Android advanced phishing attacks

An unauthenticated CP message as it appears to a Samsung user

The message tricks users into accepting malicious settings that can, for example, route all their Internet traffic through a proxy server owned by the attacker and enable the attacker to read emails.

Samsung phones are the most vulnerable

Researchers found that certain Samsung phones are the most vulnerable to this form of phishing attack because they do not have an authenticity check for senders of OMA CP messages. The user only needs to accept the CP and the malicious software will be installed without the sender needing to prove their identity.

“Given the popularity of Android devices, this is a critical vulnerability that must be addressed,” said Slava Makkaveev, Security Researcher at Check Point Software Technologies. “Without a stronger form of authentication, it is easy for a malicious agent to launch a phishing attack through over-the-air provisioning. When the user receives an OMA CP message, they have no way to discern whether it is from a trusted source. By clicking ‘accept’, they could very well be letting an attacker into their phone.”

Huawei, LG, and Sony phones do have a form of authentication checking, but hackers only need the International Mobile Subscriber Identity (IMSI) of the recipient to ‘confirm’ their identity.

Attackers can obtain a victim’s IMSI in a variety of ways, including creating a rogue Android app that reads a phone’s IMSI once it is installed. The attacker can also bypass the need for an IMSI by sending the user a text message posing as the network operator and asking them to accept a pin-protected OMA CP message. If the user enters the PIN number and accepts the OMA CP message, the CP can be installed without an IMSI.

Android advanced phishing attacks

A USERPIN-authenticated CP message as it appears to a Huawei user

Some fixes are available

The researchers disclosed their findings to the affected vendors in March 2019:

  • Samsung included a fix addressing this in their Security Maintenance Release for May (SVE-2019-14073)
  • LG released their fix in July (LVE-SMP-190006)
  • Huawei is planning to include UI fixes for OMA CP in the next generation of Mate-series or P-series smartphones
  • Sony stated that its devices follow the OMA CP specification.


Continue Reading


%d bloggers like this: