android
What a dreadful week this one has been for the infosec industry, my friends. Following an amusing week of discovering bugs, zero-days and other researcher-coveted curios, here comes the painful hangover of seeing all of this infiltrate into the vulnerable software. This is important, but often boredom inducing. Every time our news blog, Threatpost, feeds me the freshly baked digest of infosec news with three headlining articles telling stuff about patching, this digest is pretty hard to digest.
Well – anyway, this stuff is important! One cannot simply find a vulnerability, they say, but what is more difficult is patching it without wrecking it all. One can find a number of reasons why this very bug cannot be patched right now, or this quarter, or, like, ever. Yet, the problem has to be solved.
Today’s hit parade features three stories covering bugs which remain woefully unpatched. Once, again, the rules of the road: every week Threatpost’s team hand-picks three important news which I would restlessly comment. All previous editions can be found here.
Another Android bug, now in Google Admin
The Threatpost story. Research by MWR.
What was found?
Have you ever noticed those love letters from bugs are delivered in piles lately? Gee, a car got hacked? Let’s find a dozen more holes in cars! The same pattern is easily noticeable with regard to the latest news around Android. First Stagefright, then a couple of smaller bugs, now this Google Admin and Shawshank redemption an escape from sandbox.
Google Admin, one of Android’s system-level apps, may accept URLs from other apps and, as it turned to be, any URLs would be fine, even those starting with ‘file://’. As a result, a simple networking stuff like downloading web pages starts to evolve into a whole file manager kind of thing. Aren’t all Android apps isolated from each other? Heck no, Google Admin enjoys higher privileges, and by luring it into reading some rogue URL, an app can escape sandbox and access private data.
How was that patched?
First, allow me to brief you on the way independent researched disclosed the vulnerability. It was discovered as far back as March, with a corresponding report submitted to Goggle. Five months later, the researchers once again checked out what was going on only to find the bug remained unpatched. On the 13th of August the information on the bug was publicly disclosed, prompting Google to finally issue the patch.
By the way, Google does have an in-house research team that devotes time and effort to hunting bugs everywhere, not limited to its own software. Google Project Zero usually allows for 90 days before going public with the bug, which makes one wonder whether Google is able to patch itself in 90-days’ time, after all.
But with Google Admin, something went terribly wrong: first, something, indeed, was definitely wrong; second, we all know that patching would not necessarily solve the issue on all vulnerable Android devices. Monthly security updates, you say? How about working on a patch for half-year, heh? Hear, hear.
Open vulnerability in Schneider Electric’s SCADA
The Threatpost story. ICS-CERT Advisory.
Welcome to the fascinating world of critical infrastructure! Please be seated, make yourself comfortable, don’t touch that scary red switch and hands off those wires weirdly sticking out of that thing. Yes, they are meant to stick out. That’s fine. Yep. They’ve been like that for ages. Once you touch them, we are all screwed.
SCADA systems are a part of critical infrastructures that are responsible for handling important stuff like boilers in your apartment building or even nuclear plants. Such systems are not meant to be tampered with, switched off, or reset. Don’t horse around with any parameters, simply, don’t you touch anything!
#Security Week 34: new unpatched #vulnerabilities in #Android, Mac #OSX, Schneider Electric #SCADA and more
Tweet
Should you have questions, God forbid to try it on your own, better read our article on this topic. Meanwhile, let us just admit that, despite of those systems being uber-critical, quite frequently are they deployed on regular PCs running good old Windows. Unlike typical enterprises, which update or replace their hardware and software at least once in five years or so, some industrial facility robot or centrifuge that serves to keep some deadly chemicals apart, might operate 24/7 for decades on the same hardware.
What was found?
Well, a pile of bugs was found in one of such systems — Schneider Electric’s Modicon M340 (ah, so romantic!) PLC Station P34 CPU. In a nutshell, this series of vulnerabilities would allow an outsider to gain control over… well, basically, anything the system would be governing. A quite mainstream flaw was found there (by the way, it is frequently found in a number of routers and IoT stuff), which we call hard-coder credentials.
Risky Schneider Electric SCADA Vulnerabilities Remain Unpatched https://t.co/2oGDTbr7qE via @threatpost pic.twitter.com/eyPAY6Aikn
— Kaspersky (@kaspersky) August 17, 2015
Whatever was hard-coded in the industrial SCADA system, remains secret (for obvious reasons, though), but we’d make a brave assumption it was a default login credentials which a vendor provides in order to simplify servicing, or a vendor might have simply forgotten to take a test password out from the code. Or whatever other excuse you want to add.
How was it patched?
It wasn’t. Two solid weeks has gone by since the researcher Aditya Sood presented the vulnerability at DEF CON, yet the patch is nowhere near. It’s quite understandable: a vendor faces a very uneasy task, since a challenging job of patching vulnerable software becomes even more challenging due to the fact that a customer would be up for significant losses any down time would mean, and at times downtime is simply not possible.
So, how much time would the deployment of the patch take? For how long would the operations be suspended? Will it work then, anyway? Were all the peculiarities of end-point devices taken into consideration? All in all, that’s a royal pain, which, nevertheless, is a lame excuse for not patching the bugs. It was proven a bunch of times that disconnecting critical infrastructure from Internet or protecting it by means of a firewall is not a solution.
Developers at the disclosure presentation
An unpatched bug in Mac OS X
Once again we are touching upon the subject of responsible disclosure. Talking about the Google bug, the researchers were on a stand-by for five months before going public, even though Google itself limits this time to 90 days. How long should one wait, anyway? How much time would one spare to the developer to close an eye-watering hole?
Wouldn’t sufficient amount of time soften up the developers, so they keep postponing the patch for whatever time necessary? Wouldn’t the immediate publication of the vulnerability motivate the developer to be swift with the patch? Anyway, there is no standard lead-in time, yet everyone agrees that going public with a bug without prior notice to the developer sucks.
What was found?
Here’s one good example of the case when the developer was whether notified, or not, or was, after all, but with a too short notice, so they had no proper time to react…. An 18-year old researcher Luca Todesco published details of a serious vulnerability in Mac OS X Yosemite and Mavericks (10.9.5 — 10.10.5), which allows an attacker to gain root privileges on the exposed machine.
Inside the unpatched OS X vulnerabilities https://t.co/4mUVYrtVwa
— Eugene Kaspersky (@e_kaspersky) August 19, 2015
The bug is not exploitable remotely: the culprit should lure the user to download and execute an exploit — something they definitely would be able to succeed at. There’s also a proof of concept available — just take it and use it.
How was it patched?
Well, it wasn’t yet. According to the researcher, he got no feedback from Apple, hard as he tried many times. The fact of going public with such vulnerability does not worry him: as he says, he just explored a new way of jailbreaking, and that’s it. Not a big deal.
Well, that’s a lousy comparison: jailbreak is something users, who are aware of what exactly they are doing, are voluntarily signing up for. One cannot simply make an iPhone user jailbreak their device, unless the user wants to. As for Todesco’s bug, that’s not always the case. No wonder he was under harsh criticism from his peers:
Developer reveals Mac security hole without telling Apple http://t.co/siVCVIP3Ff pic.twitter.com/UUrECGbwJu
— Engadget (@engadget) August 17, 2015
It remains unclear whether the newly discovered bug affects the new Mac OS X El Capitan. I’m looking forward to the patch.
What else?
Microsoft patched a bug in Internet Explorer (well, at least someone patched something) by issuing an urgent out-of-band patch, the second in this month.
Private data of the Ashley Madison matching website for married people, previously stolen by hackers, now are online, as promised by the group who claimed responsibility for the breach.
https://twitter.com/kaspersky/status/634349398198218752
Kaspersky Lab discovered Blue Termite, a major cyberintelligence campaign that already claimed a number of victims in Japan. It does not go unnoticed that the cyberspies who have been in action for over two years suddenly intensified their activities this summer as soon as they could lay hands on a Flash exploit which had been leaked as part of a data dump stolen from The Hacking Team.
#BlueTermite #APT exploits #Flash CVE-2015-5119 exploit to further infection https://t.co/Fj0eAJkCTH
— Kaspersky (@kaspersky) August 20, 2015
Oldies:
“Justice”
Quite dangerous; affects .COM files when called by DOS 43h, 4Bh, 3Dh, 56h functions. The malware is written at the end of the files and alters 5 bytes in the beginning (NOP; NOP; JMP Loc_Virus). The process of compromising COMMAND.COM uses the same method as in the Lehigh virus. Regularly snatches data written on the drive, writing it onto a different sector. Contains the text: “AND JUSTICE FOR ALL”. Hijacks int 13h and int 21h.
Quoted from “Computer viruses in MS-DOS” by Eugene Kaspersky, 1992. Page 72.
Disclaimer: this column reflects only the personal opinion of the author. It may coincide with Kaspersky Lab position, or it may not. Depends on luck.
Tips