Last week, for the second time since June, Google warned his Gmail users of possible state-sponsored attacks. According to Mike Wiacek, a manager on Google’s information security team, Google started to alert users to state-sponsored attacks three months ago. Meanwhile the security team has gathered new intelligence about attack methods and the groups deploying them, and that information was used to warn “tens of thousands of new users”, possible targets of the attack.
Apparently this increase in state-sponsored activity comes from the Middle East, although no particular countries have been explicitly quoted.
This is not the first time that Gmail is the target of alleged state-sponsored attacks, unfortunately the secrets hidden inside the mailboxes have proven to be a too tempting target for states without scruples.
June 5, 2012: Eric Grosse, Google VP Security Engineering issues a Security warnings for suspected state-sponsored attacks.The warning seems more a preventive measure than the result of a true campaign.
September 8, 2011: As consequence of the infamous Diginotar Breach by the so-called Comodo Hacker, Google advises its users in Iran to change their Gmail passwords, and check that their Google accounts have not been compromised. Several Iranian users who may have been hit by a man-in-the-middle attack are contacted directly.
June 1, 2011: In an unusual blog post, Google declares to have discovered and alerted hundreds of people victims of a targeted “phishing” scam originating from Jinan, the capital of Shandong province. Hackers aimed to get complete control of the personal Gmail accounts of hundreds of users including, among others, senior U.S. government officials, Chinese political activists, officials in several Asian countries (predominantly South Korea), military personnel and journalists. Google does not rule out the possibility of the attack being state-sponsored, although China firmly denies Gmail hacking accusations.
January 13, 2010: In a blog post, Google discloses the details of the infamous Operation Aurora. A highly sophisticated and targeted attack on its corporate infrastructure originating from China that resulted in the theft of intellectual property from Google. At least twenty other large companies from a wide range of businesses have been targeted, but the primary goal of the attackers was accessing the Gmail accounts of Chinese human rights activists (only two Gmail accounts appear to have been accessed with limited damage). As part of the investigation (but independent of the attack on Google), it turns out that the accounts of dozens of U.S.-, China- and Europe-based Gmail users, advocates of human rights in China, appear to have been routinely accessed via phishing scams or malware placed on the users’ computers.
State-Sponsored attacks or not, setting a complex password and enabling 2-step verification are two effective countermeasures to mitigate the risk.
An Advanced Anti-Malware solution can be really effecive as well, such as Lastline. It is not a coincidence that Wepawet, based on our technology, was the first to detect the Internet Explorer “Aurora” Memory Corruption exploit behind the state-sponsored Operation Aurora.
So Google has acquired Virus Total, the Spanish company which provides the well-known cloud-based free service that analyzes suspicious files and URLs to detect malware, by comparing the results of 42 different antivirus engines and 30 URL scanning services. The news has been given today with a blog post.
Google’s move does not come so unexpected if you consider that Anti-Malware services are moving towards the cloud which is the only way to provide the resources and the holistic perspective needed to analyze the growing number of malware samples (and variants), a task which requires a huge amount of computational resources and a real-time intelligence. To have an idea of the resources needed, try to have a look at the Virus Total Statistics.
On the other hand, the Spanish company has admitted in the blog post that the Virus Total service will undoubtedly benefit from Google’s horsepowers:
- The quality and power of our malware research tools will keep improving, most likely faster; and
- Google’s infrastructure will ensure that our tools are always ready, right when you need them.
Continuing to operate independently, and to maintain the existing partnerships with other antivirus companies and security experts.
And Google? Even if detractors claim that the company will exert a strict control on malware data, the target of the acquisition is a quantum leap in web security, with the possibility to include Virus Total Security Services and Technologies inside the rich service portfolio of Mountain View. Think for instance to real time scanning (with 30 engines) of the URLs in search engine results.
Time will tell who is right, in the meantime keep on submitting malware samples!
It looks like that Christmas approaching is not stopping hackers who targeted a growing number of organizations including several security firms (Kaspersky, Nod 32 and Bitdefender) even if in secondary domains and with “simple” defacements.
Cyber chronicles report of Gemnet, another Certification Authority Breached in Holland (is the 12th security incident targeting CAs in 2011) and several massive data breaches targeting Finland (the fifth this year, affecting 16,000 users), online gambling (UB.com affecting 3.5 million of users), Telco (Telstra, affecting 70,000 users), and gaming, after the well known attacks to Sony, Sega and Nintendo, with Square Enix, which suffered a huge attacks compromising 1,800,000 users (even if it looks like no personal data were affected).
Online Payment services were also targeted by Cybercrookers: a Visa East European processor has been hit by a security breach, but also four Romanian home made hackers have been arrested for a massive credit card fraud affecting 200 restaurants for a total of 80,000 customers who had their data stolen.
As usual, hacktivism was one of the main trends for this first half of the month, which started with a resounding hacking to a Web Server belonging to ACNUR (United Nations Refugees Agency) leaking more than 200 credentials including the one belonging to President Mr. Barack Obama.
But from a mere hactvism perspective, Elections in Russia have been the main trigger as they indirectly generated several cyber events: not only during the election day, in which three web sites (a watchdog and two independent news agencies) were taken down by DDoS attacks, but also in the immediately following days, when a botnet flooded Twitter with Pro Kremlin hashtags, and an independent forum was also taken down by a further DDoS attacks. A trail of events which set a very dangerous precent.
Besides the ACNUR Hack, the Anonymous were also in the spotlight (a quite common occurrence this year) with some sparse attacks targeting several governments including in particular Brazil, inside what is called #OpAmazonia.
Even if not confirmed, it looks like that Anonymous Finland might somehow be related to the above mentioned breach occurred in Finland.
Other interesting events occurred in the first two weeks of December: the 0-day vulnerability affecting Adobe products, immediately exploited by hackers to carry on tailored phishing campaigns and most of hall, a targeted attack to a contractor, Lockheed Martin, but also another occurrence of DNS Cache Poisoning targeting the Republic of Congo domains of Google, Microsoft, Samsung and others.
Last but not least, the controversial GPS Spoofing, which allegedly allowed Iran to capture a U.S. Drone, even the GPS Spoofing on its own does not completely solve the mistery of the capture.
Other victims of the month include Norwich Airport, Coca Cola, and another Law Enforcement Agency (clearusa.org), which is currently unaivalable.
As usual after the page break you find all the references.
Few days ago Juniper Networks has released a report on the status of Android Malware. The results are not encouraging for the Android Addicted since they show a 472% increase in malware samples since July 2011 (see the infographic for details).
This does not surprising: already in May in its annual Malicious Mobile Threats Report, report, Juniper had found a 400% increase in Android malware from 2009 to the summer of 2010. This trend is destined to further grow since the Juniper Global Threat Center found that October and November registered the fastest growth in Android malware discovery in the history of the platform. The number of malware samples identified in September increased by 28%. whilst October showed a 110% increase in malware sample collection over the previous month and a noticeable 171% increase from July 2011.
As far as the nature of malware is concerned, Juniper data show that the malware is getting more and more sophisticated, with the majority of malicious applications targeting communications, location, or other personal information. Of the known Android malware samples, 55%, acts as spyware, 44%, are SMS Trojans, which send SMS messages to premium rate numbers without the user’s consent.
The reason for this malware proliferation? A weak policy control on the Android market which makes easier for malicious developers to publish malware applications in disguise. From this point of view, at least according to Juniper, the model of Cupertino is much more efficient and secure.
Easily predictable Google’s answer came from the mouth of Chris DiBona, open source and public sector engineering manager at Google. According to DiBona, Open Source, which is widely present in all the major mobile phone operating systems, is software, and software can be insecure. But Open Source becomes stronger if it pays attention to security, otherwise it is destined to disappear. In support of this statement he quotes the cases of Sendmail and Apache, whose modules which were not considered enough secure disappeared or came back stronger (and more secure) than ever.
But DiBona’s does not stop here (probably he had read this AV-test report which demonstrates that free Android Antimalware applications are useless): “Yes, virus companies are playing on your fears to try to sell you bs protection software for Android, RIM and IOS. They are charlatans and scammers. IF you work for a company selling virus protection for android, rim or IOS you should be ashamed of yourself.”
From this point of view Google hopes that Ice Cream Sandwich will lead Android Security at the next level even if some features are raising security concerns among Infosec professionals.
Update November 24: New EU directive to feature cloud ‘bridge’. The Binding Safe Processor Rules (BSPR) will ask cloud service providers to prove their security and agree to become legally liable for any data offences.
In my humble opinion there is strange misconception regarding cloud security. For sure cloud security is one of the main trends for 2011 a trend, likely destined to be confirmed during 2012 in parallel with the growing diffusion of cloud based services, nevertheless, I cannot help but notice that when talking about cloud security, the attention is focused solely on attacks towards cloud resources. Although this is an important side of the problem, it is not the only.
If you were on a cybercrook’s shoes eager to spread havoc on the Internet (unfortunately this hobby seems to be very common recent times), would you choose static discrete
resources weapons to carry on your attacks or rather would you prefer dynamic, continuous, always-on and practically unlimited resources to reach your malicious goals?
An unlimited cyberwarfare ready to fire at simple click of your fingers? The answer seems pretty obvious!
Swap your perspective, move on the other side of the cloud, and you will discover that Security from the cloud is a multidimensional issue, which embraces legal and technological aspects: not only for cloud service providers but also for cloud service subscribers eager to move there platforms, infrastructures and applications.
In fact, if a cloud service provider must grant the needed security to all of its customers (but what does it means the adjective “needed” if there is not a related Service Level Agreement on the contract?) in terms of (logical) separation, analogously cloud service subscribers must also ensure that their applications do not offer welcomed doors to cybercrooks because of vulnerabilities due to weak patching or code flaws.
In this scenario in which way the two parties are responsible each other? Simply said, could a cloud service provider be charged in case an attacker is able to illegitimately enter the cloud and carry on attack exploiting infrastructure vulnerabilities and leveraging resources of the other cloud service subscribers? Or also could an organization be charged in case an attacker, exploiting an application vulnerability, is capable to (once again) illegitimately enter the cloud and use its resources to carry on malicious attacks, eventually leveraging (and compromising) also resources from other customers? And again, in this latter case, could a cloud service provider be somehow responsible since it did not perform enough controls or also he was not able to detect the malicious activity from its resources? And how should he behave in case of events such as seizures.
Unfortunately it looks like these answers are waiting for a resolutive answer from Cloud Service Providers. As far as I know there are no clauses covering this kind of events in cloud service contracts, creating a dangerous gap between technology and regulations: on the other hands several examples show that similar events are not so far from reality:
- On June 2, 2011, during the peak of the LulzSec saga, CloudFlare, the (network and cloud) service provider hosting the web server of the infamous hacking group, was targeted with DDoS attacks, after the group decided to publish information obtained from the Sony Pictures’ website;
- On June 22, 2011, FBI seized some servers from DigitalOne as Ryan Cleary, a 19-year-old suspected of involvement in LulzSec, was arrested. In this circumstance several popular, legitimate websites including Pinboard, a bookmarking service, and Instapaper, a tool for saving web articles, were affected. Moreover the CEO of tje Company declared that, although interested in one of the company’s clients, F.B.I. took servers used by tens of clients;
- On August, the 29th 2011, an Italian security penetration tester discovered some flaws in Google’s servers allowing malicious attackers to launch a distributed denial-of-service attack on a server of their choosing;
- On October, the 12nd 2011, Defence Contractor Raytheon revealed it was the victim of a spear phishing cloud-based attack;
- On October, the 28th 2011, Indian authorities seized computer equipment from a data center in Mumbai as part of an investigation into the Duqu malicious software that some security experts warned could be the next big cyber threat.
Is it a coincidence the fact that today TOR turned to Amazon’s EC2 cloud service to make it easier for volunteers to donate bandwidth to the anonymity network (and, according to Imperva, to make easier to create more places and better places to hide.)
I do believe that cloud security perspective will need to be moved on the other side of the cloud during 2012.
A week ago, the Office of the National Counterintelligence Executive published a report to Congress concerning the use of cyber espionage to attempt to gain business and industrial secrets from US companies. Easily predictable, the results present a frightening picture!
With no surprise it turned out that the biggest dangers and perpetrators of cyber-espionage operations against American business are China and Russia.
- Chinese actors are the world’s most active and persistent perpetrators of economic espionage. US private sector firms and cybersecurity specialists have reported an onslaught of computer network intrusions that have originated in China, but the Intelligence Community cannot confirm who was responsible.
- Russia’s intelligence services are conducting a range of activities to collect economic information and technology from US targets.
- Some US allies and partners use their broad access to US institutions to acquire sensitive US economic and technology information, primarily through aggressive elicitation and other human intelligence tactics. Some of these states have advanced cyber capabilities.
Unfortunately the predictions for the near future are not encouraging: the authors of the report judge that the governments of China and Russia will remain aggressive and capable collectors of sensitive US economic information and technologies, particularly in cyberspace.
This is mainly due to three factors: a technological shift with a growing number of devices connected to the Internet (according to a Cisco Systems study, the number of devices connected to the Internet is expected to increase from about 12.5 billion in 2010 to 25 billion in 2015). An economical shift driven by the Cloud Paradigm which requires the information to be ubiquitous and always available and, last but not least, a cultural shift which bring users to a growing use of social media for personal and professional use with a dangerous overlapping.
With these considerations in mind I decided to concentrate on a single table all the attacks with cyber espionage implications reported in 2011 for which China was directly or indirectly (or allegedly) considered responsible. The details (and links) of each single attack can be found on my 2011 Cyber Attacks Timeline Master Index (of course the list does not include the infamous Operation Aurora and the attack to G20 during the French Leadership since these events occurred during 2010).
U.S., Canada, Japan and Korea are among the countries hit by the Cyber Attacks from Far East. The most known attack is for sure the one perpetrated against RSA, whose wake affected several U.S. Contractors. Moreover the same attack was not an isolated episode, but the tip of an iceberg hiding 760 affected organizations worldwide.
Shady Rat and the IMF attack were other noticeable events as also the breach reported against the Cyworld the Korean Social Networks in which 37 million users were affected.
A frightening scenario that also generated some resounding fake attacks during 2011 (do you remember the Renault affair?)
A new cold (cyber)war at the gates?
- Cyber-espionage attempts on US businesses are on rise (arstechnica.com)
Hard times for Information Security and for the authentication models it had been built upon. The inglorious falls of SecureID and Certification Authority Authentication models were not enough in this troubled 2011 and now it looks like the last authentication bastion was breached after Thai Duong and Juliano Rizzo unleashed their BEAST (Browser Exploit Against SSL/TLS) attack.
The attack exploits a well known vulnerability on CBC mode encryption algorythms (such as AES and 3DES) which affects SSL and TLS 1.0. CBC mode encryption divides the plaintext in fixed size blocks (usually 128 bits). In this mode of operation each block of ciphertext is not directly encrypted, rather, before undergoing the operation, is XORed with the previous Ciphertext. Of course the first block of the message may not be XORed with any previous Ciphertext and for this reason an hard-guessable random vector, called IV or Inizialization Vector is chosen to inizialize the encryption process.
During an encryption session (think for instance to an HTTPS session) several TLS messages are transmitted inside the same encryption channel and here come the troubles: unfortunately TLS 1.0 implementation does not use a new IV for each TLS message, that is the ciphertext of the last block of the previous message is used as the Inizialization Vector of the new message. Unfortunately this approach limits the unpredictability of the Inizialization vector: an attacker could in theory try to guess some plaintext somewhere in the encryption stream and inject a crafted plaintext so that if the encrypted output of that block corresponds exactly to the ciphertext of the block in which the guessed original message was encrypted, this means that the attacker’s guess was right. The attack is made possible in theory just because the CBC mode use the output of the previous block as the IV for the next plaintext block.
From a more formal point of view a nice and very clear description is reported at this link which I report in the following lines:
Consider the case where we have a connection between Alice and Bob. You observe a record which you know contains Alice’s password in block i, i.e., Mi is Alice’s password. Say you have a guess for Alice’s password: you think it might be P. Now, if you know that the next record will be encrypted with IV X, and you can inject a chosen record, you inject:
X ⊕ Ci-1 ⊕ P
When this gets encrypted, X get XORed in, with the result that the plaintext block fed to the encryption algorithm is:
Ci-1 ⊕ P
If P == Mi, then the new ciphertext block will be the same as Ci, which reveals that your guess is right.
The question then becomes how the attacker would know the next IV to be used. However, because the IV for record j is the CBC residue of record j-1 all the attacker needs to do is observe the traffic on the wire and then make sure that the data they inject is encrypted as the next record, using the previous record’s CBC residue as the IV.
So apparently nothing new under the sun, except the fact the attack scenario is higly unlikely since the attacker should find a way to guess some patterns and inject some well known patterns inside the encrypted channel unless…
Unless the attacker could inject a large amount of known malicious data at a time (in order to limit the guessable plaintext in each block) and use a Web server side method to inject them.
This is exactly where the two main features of the BEAST attack rely: what if an attacker could guess where the encrypted password is located inside the encrypted channel, and split the original block in several 16 bytes blocks in which a single byte contains the original character of the password and the remaining 15 bytes contain the malicious known padding? Quite Easy! The attacker should try “only” 2^8 (256) possible values in order to guess the first character and obtain the same encrypted output than the crafted plaintext. Once guessed the first character, he could obtain the IV for the next block from the ciphertext, and guess the next character of the password in the next block with the same method: the first byte is known to be the first character of the password, the second byte is the unknown quantity and the other 14 bytes contain the malicious known padding. Shifting up to the last block the attacker could obtain the password.
Of course in theory there is still a big issue consisting in the injection of the known pattern in the encryption channel. In order to overcome it the attackers used a method (for which so far few details were disclosed) leveraging Web Sockets, a technology which provides for bi-directional, full-duplex communications channels, over a single TCP Socket. In a meshed-up world, Web Sockets are used for instance when a Web Server redirects a browser to another server to get a certain content (for instance an embedded Image). In Web Socket models, the browser handshakes directly with the remote server and verify if the connection is ok from the first server (origin based consent).
The same article mentioned above delineates how Web Sockets may be exploited to perpetrate the attack:
Say the attacker wants to recover the cookie for
https://www.google.com/. He stands up a page with any origin he controls (e.g.,
http://www.attacker.com/. This page hosts JS that initiates a WebSockets connection to
https://www.google.com/. Because WebSockets allows cross-origin requests, he can initiate a HTTPS connection to the target server if the target server allows it (e.g., because it wants to allow mash-ups). Because the URL is provided by the attacker, he can make it arbitrarily long and therefore put the Cookie wherever he wants it with respect to the CBC block boundary. Once he has captured the encrypted block with the cookie, he can then send arbitrary new packets via WebSockets with his appropriately constructed plaintext blocks as described above. There are a few small obstacles to do with the framing, but Rizzo and Duong claim that these can be overcome and those claims seem plausible.
Although TLS 1.1 and 1.2 introduce a randomizaton of the IV for each message, the dramatic thing is that TLS 1.1 has been published in 2006 but it is far from being commonly adopted. The funny thing is that in order to mitigate the attack Web Servers should use a cipher which does not involve CBC mode, as for instance RC4 (back to the future).
Google servers already use RC4 while Chrome developers are testing a workaround. Will RC4 be enough to save the infosec world from the fall of authentication?