I just finished reading this interesting article that seems to offer a different view for the attack at Lockheed Martin (actually, a lone voice which does not consider the attack related to compromised seeds), that here it is another bolt from the Blue. As a matter of fact Wired reports that a second Defense Contractor, L-3, has been targeted with penetration attacks leveraging information stolen from the infamous RSA Breach. This information was contained into an E-mail, dated April 6, sent to the 5000 group’s employees. t’s not clear from the e-mail whether the hackers were successful in their attack, or how L-3 determined SecurID was involved.
Protecting our network is a top priority and we have a robust set of protocols in place to ensure sensitive information is safeguarded. We have gotten to the bottom of the issue.
Is the only comment of the company.
This revelation occurs few days after the explosive news pertaining the attack led with similar methods to another Defense Contractor, Lockeed Martin.
Maybe all the defense contractors should have followed the wise example of Raytheon (another Defense Contractor) which declared to have taken immediate companywide actions in March when incident information was initially provided to RSA customers, to prevent a widespread disruption of their network.
If confirmed, this event is a further corroboration of the fact the real target of the Hackers was not RSA but their customers, event if at this point I wonder if military contractors are the only targets or if they have been the only ones capable to detect the attempts because of their strict security protocols and policies.
- Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks (wired.com)
- More Random Thoughts on the RSA Breach (paulsparrows.wordpress.com)
- Some Random Thoughts On RSA Breach (paulsparrows.wordpress.com)
There is a new nightmare on the Android Market, and again many Android devices are not going to have a good awakening.
The last security advice for the Google Mobile OS comes from Lookout, which has discovered a new variant of the infamous DroidDream, the first malware conveyed by the Official Android Market capable of infecting at the beginning of March, according to Symantec, between 50.000 and 200.000 devices.
This time the brand new version, dubbed DroidDreamLight, was found in 26 repackaged applications from 5 different developers distributed in the Android Market. According to Lookout DroidDreamLight is no less than is “noble” predecessor, since was able to affect between 30.000 and 120.000 users.
According to Lookout, the malicious components of DroidDream Light are invoked on receipt of an android.intent.action.PHONE_STATE intent (e.g. an incoming voice call). As a consequence DroidDream Light does not depend on manual launch of the installed application to trigger its behavior. The broadcast receiver immediately launches the <package>.lightdd.CoreService which contacts remote servers and supplies the IMEI, IMSI, Model, SDK Version and information about installed packages. It appears that the DDLight is also capable of downloading and prompting installation of new packages, though unlike its predecessors it is not capable of doing so without user intervention.
The list of the infected applications (already removed from Google) is available at the original link. I must confess I could not help noticing the rich amount of “hot” applications, which confirm (unfortunately) to be a lethal weapon for carrying malware.
This event will raise again the concerns about the security policies on the Android Market, and about the apparently unstoppable evolution of the mobile threat landscape which has brought for the Android a brand new malware capable of sending data to a remote server. A further step closer to a mobile botnet even if, at least for this time, with limited capabilities of auto-installing packages,.
I will have to update my presentation, meanwhile do not forget to follow the guidelines for a correct mobile behavior:
- Avoid “promiscuous” behaviours (perform rooting, sideloading or jaibreaking with caution, most of all in case of a device used for professional purpose);
- Do not accept virtual candies from unkown virtual individuals, i.e. only install applications from trusted sources, always check the origin and their permissions during installation;
- Beware of unusual behavior of the phone (DroidDream owes its name to the fact that he used to perform most of its malicious action from 11 P.M to 8 A.M.);
- Beware of risks hidden behind social Network (see my post of yesterday on mobile phishing);
- Use security software;
- Keep the device updated.
- DroidDreamLight malware hits dozens of Android apps (venturebeat.com)
- Malicious apps removed from Android Market (news.cnet.com)
- Malicious apps removed from Android Market (news.cnet.com)
- Lookout Teams Pegs 25 Android Market Apps Infected With DroidDreamLight Malware (androidpolice.com)
- 30,000 to 120,000 Android Users Affected by New Variant of Droid Dream Malware (readwriteweb.com)
- New Android malware spotted: DroidDream Light (intomobile.com)
One of the most surprising things I noticed concerning the Lockheed Martin Affair, was the affirmation contained in the Reuters Article, made by Rick Moy, president of NSS Labs, indicating that the initial RSA attack was followed by malware and phishing campaigns seeking specific data to link tokens to end-users (an indirect evidence of the same authors behind the infamous RSA breach and the Lockheed Martin attack.
My initial surprise only lasted few seconds, since, this year is showing us a brand new role for the phishing attacks which are more and more targeted to steal corporate sensitive data, and constitute the first level of attack for Advanced Persistent Threats.
At first sight could be quite difficult to believe that users are still tricked by old-school phishing techniques, but a deeper analysis could show in my opinion, a possible (in part psychological) explanation relying on the fact that the users themselves are still used to think to phishing as something targeted to steal personal information (often with pages crafted with gross errors), and seems to be unprepared to face the new shape of phishing which targets corporate information with cybercrime purposes and industrial methods, which definitively means to perpetrate the attack with plausible and convincing methods, and most of all leveraging arguments the user hardly doubts about (I could doubt of an E-mail from my bank asking me to provide my account and credit card number, maybe, most of all in case I am not an infosec professional, I could feel more comfortable in providing my username to a (fake) provisioning portal of my Company).
But my information security beliefs are falling one after the other, and after reading this really interesting article by Adrienne Porter Felt and David Wagner of the University of California (the marvelous LaTeX layout!) I can only confirm that mobile devices will be next frontier of phishing.
According to this paper the risk of a success of a phishing attack on mobile devices is dramatically greater than traditional devices due to some intrinsic factors such as the smaller size of the screen, the fact that many applications embed or redirect to web pages (and vice versa some or web pages redirect to applications), the fact that mobile browsers hide the address bar, and most of all the absence of application identity indicators (read the article and discover how easily a fake native application can resemble completely a browser page) which makes very difficult to discover if a certain operation is calling a fake application on the device or it is redirecting the user to a fake application resembling a legitimate login form.
Moreover, the intrinsic factors are worsened by (as usual) the user’s behavior: as a matter of fact (but this is not a peculiarity of mobile devices), users often ignore security indicators, do not check application permissions and are more and more used to legitimate applications continuously asking for passwords with embedded login forms and. Last but not least I would add the fact that they are not still used to think to mobile applications as targets of phishing (Zitmo Docet).
Guess what are the ideal candidates for Mobile Phishing attacks? Easy to say! Facebook and Twitter since they are the most common linked applications used by developers to share their creations (the power of free viral marketing!).
Given the speed with which these devices are spreading in the enterprise (see for instance this GigaOM infographic), there is much to worry about in the near future. An interesting solution could be the operating system to support a trusted password entry mechanism. Will SpoofKiller-like trusted login mechanisms be our salvation as the authors of the paper hope?
- More Random Thoughts on the RSA Breach (paulsparrows.wordpress.com)
- Mobile Phones Are Great for Phishers, Researchers Find (pcworld.com)
Probably it was a quite easy prediction, however it looks like what I suggested on my random thoughts on the RSA Breach has definitively come true: RSA was not the target, probably its customers were.
On this front, the last two days were quite turbulent, and what seemed initially a simple speculation of an attack using compromised SecureID seeds targeted to “a very large U. S. defense contractor”, is revealing to be one of several attacks towards military contractors of U.S. Defense, using the data stolen during the famous breach of March.
According to a source with direct knowledge of the attacks, quoted in the above linked Reuters article:
The hackers learned how to copy the security keys with data stolen from RSA during a sophisticated attack that EMC disclosed in March, according to the source.
In any case EMC, the parent company of RSA, and the other main U.S. defense contractors possibly involved refused to comment.
I was not surprised by these details, more than one month ago I delineated a possible attack scenario which seems to be very close to what happened, at least for Lockheed Martin. Since the token on its own it is not enough to carry on a successful attack (it must be linked to the owner and very often the real password is also combined with a PIN), other combined actions must be performed to obtain the missing pieces of the puzzle.
I suggested a possible scenario of exploiting the weakness of software tokens, for instance by mean of specific keylogger malware to grab user details and the PIN. It is not exactly what happened in case of Lockheed Martin, but the real attack scenario is quite close since a keylogger was involved as well and used to access the intranet and consequently to get access to the internal network: as a matter of fact, for security reasons many companies use a double layer of authentication for remote access and internal resources. In this case the company forced 100.000 users to reset their passwords.
In reality, as stated by Rick Moy, president of NSS Labs, the initial RSA attack was followed by malware and phishing campaigns seeking specific data that would link tokens to end-users, suggesting that the current attacks may have been carried out by the same hackers. And the game is not over.
Unfortunately the use of phishing to lure the users (and to attack an organization for cybercrime purposes) is not surprising as well. Nowadays this technique, to initially target the users with phishing, leading them to download malware, is the “main engine” of APTs (Advanced Persistent Threats) and it is revealing to be the common denominator of the main breaches and huge scale attacks of this annus horribilis for Information Security. The fact that in this circumstance it was used in combination with the duplicated key of SecureID is only the last unedited variant, and I am afraid it will not be the last.
Fortunately, in any serious situation there is always a flash of humor: according to this article of NYT, the intruders had been detected as they were trying to transfer data by security software provided by NetWitness Corporation, a company that provides network monitoring software. Does NetWitness Corporation sound familiar to you? Of course It does indeed! In April, just after the breach, NetWitness was acquired by RSA’s parent company, EMC.
As Morpheus stated: “Fate, it seems, is not without a sense of irony”, and this is worthwhile for Information Security as well.
A bolt from the blue! Source report some details of the alleged first attack to a very large U. S. Defense contractor perpetrated by mean of compromised RSA seeds.
Late on Sunday all remote access to the internal corporate network was disabled. All workers were told was that it would be down for at least a week. Folks who regularly telecommute were asked to come into nearby offices to work. Then earlier today (Wednesday) came word that everybody with RSA SecureID tokens would be getting new tokens over the next several weeks. Also, everybody on the network (over 100,000 people) would be asked to reset their passwords, which means admin files have probably been compromised.
It seems likely that whoever hacked the RSA network got the algorithm for the current tokens and then managed to get a key-logger installed on one or more computers used to access the intranet at this company. With those two pieces of information they were then able to get access to the internal network.
Fortunately the contractor was able to detect the breach and to manage it, avoiding worst consequences.
But many questions remain unsolved: was this the first attempt? Were all the seeds compromised during the famous breach? For Sure it will not be the last and my sixth sense and one half thinks we will have to get used to this kinds of attacks.
As I told in previous post I am more and more convinced that the final target of the attack was not RSA…
- Some Random Thoughts On RSA Breach (paulsparrows.wordpress.com)
- What do RSA, Epsilon and Sony breaches have in common? (paulsparrows.wordpress.com)
The Google Chromebook (that is the first Chromium OS powered devices) was presented few days ago (and is ready to reach our shelves for the half of June), but only yesterday I accidentally came across an interesting article (which I had already reported in yesterday’s post) which led me to several thoughts concerning the future of endpoint security, or better, how endpoint protection technologies will adapt themselves to the rapidly mutating landscape, which is shifting from an endpoint-centric to a cloud-centric model. My personal confessions of a dangerous mind derive from Google’s assertion that: Chromebooks have many layers of security built in so there is no anti-virus software to buy and maintain. Moreover, the fact that data reside mainly on the cloud moves the data protection requirements towards the cloud rather than on the endpoint. If this is true many security giants (such as
Intel McAfee, Symantec, Trend Micro, etc.) focalized on endpoint would seriously have to worry about.
The core of the Chromium OS is represented by the Chrome web browser. Through a Web Interface, and most of all thanks to HTML5, Open Web Platform APIs and Google Chrome Extensions, the users will be able to access virtually any kind of applications from the cloud.
What does it mean from a security perspective? The Security Overview document describing the Security Mechanisms adopted by the Chromium OS is clear: the operating system has been designed from the ground up with security in mind, security as an iterative process focused on for the life of the operating system. As a matter of fact, since the OS is browser-centric, the security design efforts have been concentrated on this aspect starting from the foundation, that is the Operating Systems. Several of the weapons adopted by Chromium OS include:
- OS Hardening through techniques of Process sandboxing (at OS and browser level), toolchain hardening, Kernel hardening and configuration paring, Additional file system restrictions (Read-only root partition, tmpfs-based /tmp, user home directories without executables, privileged executables, or device nodes;
- Modular browser with sandboxes for media and HTML parsers;
- Protection for Phishing, XSS and other Web vulnerabilities;
- Secure autoupdate protecting itself from attacks by mean of Signed updates downloaded over SSL, checking of Version numbers of updates and verification of the integrity of each update on subsequent boot, by man of Verified Boot process;
That said, is really true that Chromium OS will be the death knell for antivirus?
Before answering this 10 million Dollars question (rigorously Monopoly Dollars) there is a due premise that must necessarily be done: classifying an endpoint protection technology as Antivirus is maybe a little bit reductive and anachronistic. The new generations of threats (the so called blended threats or APTs) make use of several combination of attack vectors ranging from malicious phishing web sites to 0-day OS or application vulnerabilities. This has implied in the last two/three years that the concept of multi-layered protection has found fertile ground in the endpoints as well (as previously done in the network with UTM/XTM technologies) since the new threats are not simple malware but complex combinations of attack vectors which need different layers of protections. A simple antivirus does not exist anymore in a corporate context, but has been substituted by a set of protection technologies combining Anti-Malware, Personal Firewall, Host Intrusion Prevention, Encryption, Data Leackage Prevention, Compliance.
With this premise in mind there are some points for which, in my opinion, endpoint protection technologies will be still needed (at least for version 1.0);
- Some Critical voices stress the fact that Google will provide an SDK dedicated to write native applications. Although Google has probably done everything to secure those apps with their double sandbox design, in theory will be possibility to install malicious code or simply bugged code, unaware vector of vulnerabilities in the system (or in the cloud).
- There is also another important point: the security overview document identifies two possible kinds of adversaries: opportunistic adversaries and dedicated adversaries. The first kind just tries to compromise an individual user’s machine and/or data, the second kind may target a user or an enterprise specifically for attack. According to Google version 1.0 will be focuses on dangers posed by opportunistic adversaries. This means that, at least for the first version, the Chromium OS will not offer countermeasures targeted to mitigate network-level attacks.
So what are the conclusions? Maybe the death knell for Antivirus technologies (or would be better to say endpoint protection technologies) is still far, rather I believe more realistically that endpoint security technologies will have to be redefined (or better tailored) to better fit the new scenario in which the endpoints act as web-centric gates for the cloud. Maybe antivirus will be no more necessary, but security efforts on the endpoints will have to be directed to protect this new role from OS and web application vulnerabilities (see authentication tokens in clear), malicious web sites, phishing, data loss/leakage (even if the Chromium OS already offers some native features in this direction), and, last but not least, compliance issues (for an enterprise usage). How this will be achieved? Simple, by mean of cloud based security services…
- Google Chromebooks: How Will They Impact the Antivirus Industry? (webpronews.com)
The title of this post is not a subset of the famous Peter Weir’s Movie “The Year Of Living Dangerously“, featuring Mel Gibson and Sigourney Weaver, but rather refers to the dangerous months which the Android is living, from the second half of 2010 to this first half of 2011, which saw a dramatic increase in Android Malware.
I enjoyed in summarizing in a single picture the mobile malware which affected Google Mobile OS from August 2010 to the present day. As shown the results are not encouraging and seems to confirm, in a qualitative form, the 400% increase in mobile malware (in six months) recently stated by Juniper Networks: un the second half of 2011 we assisted mainly to variants of the first Trojan. In the first half of 2011 the landscape has become much more complicated with mobile malware tailored “for different needs”.
So far the threats are can be divided essentially into two categories:
- Malware capable of stealing data, sending them to a remote C&C, which in a mobile platform may have worst consequences since it may send remote data to a C&C Server);
- Malware capable of sending SMS to premium rate numbers without the user permission (and awareness).
In many cases the malware was downloaded by parallel markets (most of all from China and Russia), with often the pornography acting like a decoy for the unfortunates, hence showing the risks connected with sideloading, that is the practice to enable installation of applications downloaded from external markets.
Two examples were particularly meaningful: the example of Geinimi, which showed all the features of a Botnet. And the example of DroidDream which bypassed all the security control of Android Market and infected something between 50.000 and 200.000 users according to Symantec and were remotely removed by Google, thus prefiguring a new security model which remotely manages the security functions of endpoint (and everything suggests that this trend will soon spread to more traditional endpoints: just today I stumbled upon this really interesting article).
By the way… Just today, three German security researchers discovered a serious flaw on the ClientLogin Authentication Protocol affecting almost all the Android powered devices… Ok it is not a malware, but the security concerns for the Google Mobile Operating System are more relevant than ever…
- 400 Percent Increase In Android Malware; Mobile Security Threats At Record High (techcrunch.com)
- If The Droid Gets The (China’s) Flu (paulsparrows.wordpress.com)
- Chronicles Of The Android (paulsparrows.wordpress.com)