Yesterday Bloomberg reported the news of a new cyber attack in Middle East targeting an Oil Company. The latest victim is Ras Laffan Liquefied Natural Gas Co., a Qatari LNG producer that has shut down part of its computer systems targeted by an unidentified malware since Aug. 27.
According to the scant official information available, desktop computers in company offices were the only affected, while operational systems at onshore and offshore installations were immune, with no impact on production or cargoes.
Of course it is impossible to avoid a parallelism with the cyber attack targeting Saudi Aramco a couple of weeks ago, and the 30,000 workstations that the company admitted to have been targeted (and restored only few days ago) by this malware outbreak. It is also impossible not to mention the infamous Shamoon, the brand new malware discovered in Middle East that information security community immediately connected to the Saudi Aramco cyber incident, furthermore stating (by literally quoting Symantec’s blog):
W32.Disttrack is a new threat that is being used in specific targeted attacks against at least one organization in the energy sector.
The Ras Raffan cyber attack maybe provides a partial answer to the question regarding who else might have been affected by Shamoon (I wonder if we will soon learn of other companies targeted) and even if security researchers have not confirmed, so far, the connection between Shamoon and this latest attack, the first speculations on regard have already appeared. According to the WSJ, the RasGas information technology department identified the virus as Shamoon, stating that:
Following the virus attack, some “computers are completely dead”.
The Middle East is considered the Cradle of Civilization, but I am afraid that, in this 21st century, it is becoming the “Cradle of Cyber War”. And even if you consider Shamoon just an amateurish copycat (with no cyberwar intentions), you cannot ignore that the latest research according to which even Wiper is a son of the so-called Tilded Platform (the same malware platform that originated Stuxnet, Duqu and Flame).
This cannot be considered a mere coincidence.
Update August 17: More details about Shamoon, the malware targeting Saudi Aramco and other Middle East companies belonging to Energy Sector. Apparently the destructive details unveiled yesterday are confirmed.
Upate August 27: Saudi Aramco Admits 30K workstations affected.
I have just received a couple of tweets from an unknown user @cyberstrikenews providing more details about the latest Cyber Attack in Middle East targeting Saudi Arabian Oil Company (Saudi Aramco).
(@cyberstrikenews) August 16, 2012
The Oil Company declared that “production had not been affected” and even if the virus affected some computers, it did not penetrate key components of the network. The company also said it would return to normal operating mode soon.
From the information I have received (I cannot verify the integrity of the source, so I report the data integrally), the situation appears quite different:
- The company has about 40000 computer clients and about 2000 servers, the destructive virus was known to wipe all information and operation system related files in at least 30000 (75%) of them all data lost permanently.
- Among the servers which (were) destroyed are the company main web server, mail server (smtp and exchange), and the domain controller which as the central part of their network.
- All clients are permanently shut down and they will not be able to recover them in a short period.
- The main company web site ( http://www.aramco.com ) was down during 24 hours and at last they redirected it to an outside country web site called “www.saudiaramco.com”.
Apparently the web site has just been restored to normal operation redirecting the user to Saudi Aramco.
After Stuxnet, Duqu, Flame and Gauss, yet another confirm that there is no cyber peace in middle East!
Irony of fate: not even a day after the publication of a provocative article on the role of Cyber Warfare for maintaining peace, a new cyber threat appears, which is destined to leave an indelible mark on the cyber weapons’ landscape.
Today is one of those days that the Infosec Community will remember for a long time. It looks like the mystery of the malware targeting the Iranian Oil business a month ago has come to a solution, and it is not that kind of conclusion we would have hoped and expected.
Nearly in contemporary Kaspersky Lab, CrySyS Lab and the Iranian Computer Emergency Response Team Coordination Center have unleashed details of what has been defined (arguably) the most complex malware ever found.
The malware, which has been dubbed Flame (Kaspersky), or sKyWIper (CrySyS Lab), or also Flamer (CERTCC), has some unprecedented features that make it one of the most complex threats ever discovered:
Cyber WeaponMalware is a sophisticated attack toolkit, It is a backdoor, a Trojan, and has worm-like features (three in one). According to Kaspersky its development has taken a couple of years and it will probably take year to fully understand the 20MB of code of Flame.
- According to CrySyS Lab Flame has been in the wild since 2007, having been seen in the following geographical regions: Europe on Dec 5 2007, The United Arab Emirates on Apr 28 2008 and the Islamic Republic of Iran on Mar 1 2010;
- Flame is controlled via an SSL channel by a C&C infrastructure spread all around the world, ranging from 50 (Kaspersky) to 80 (CrySyS) different domains;
- Flame owns many capabilities, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard. C&C operators may choose to upload up to about 20 modules, which can expand Flame’s functionality;
- The complete set of 20 modules is 20 MB in size when fully deployed (about 20 times larger than Stuxnet and maybe it is the reason why it wasn’t discovered for so long);
- Flame includes a piece of code (about 3000 lines) written in LUA, a not so common occurrence for malware;
- Top 7 affected countries include Islamic Republic of Iran (189 Samples), Israel/Palestine (98 samples), Sudan (32), Syria (30), Lebanon (18), Saudi Arabia (10), Egypt (5).
- Flame appears to have two modules designed for infecting USB sticks: “Autorun Infector” (similar to Stuxnet) and “Euphoria” (spread on media using a “junction point” directory that contains malware modules and an LNK file that trigger the infection when this directory is opened);
- Flame may also replicate via local networks using the following:
- The printer vulnerability MS10-061 exploited by Stuxnet – using a special MOF file, executed on the attacked system using WMI;
- Remote jobs tasks.
- When Flame is executed by a user who has administrative rights to the domain controller, it is also able to attack other machines in the network: it creates backdoor user accounts with a pre-defined password that is then used to copy itself to these machines.
- So far no 0-day vulnerabilities have been found, despite the fact that some fully-patched Windows 7 installations have been compromised, might indicate the presence of high-risk 0-days.
With no doubt a beautiful piece of malware written with the precise intent of Cyber-Espionage. Besides the resounding features of the malware, I found particularly interesting the same infection mechanism used by Stuxnet, that make me think of (another) possible double agent implanting the first infection.
This (legitimate) suspicion is also reinforced by the disarming conclusions issued by CrySyS Lab:
The results of our technical analysis support the hypotheses that sKyWIper was developed by a government agency of a nation state with significant budget and effort, and it may be related to cyber warfare activities.
Christmas has just gone and here it is my personal way to wish you a Happy New Year: the second part of my personal chart (first part here) of Main 2011 Cyber Attacks covering the time window from August to November 2011 (December is not yet finished, and featuring remarkable events, so expect an update very soon). This memorable year is nearly over and is time, if you feel nostalgic, to scroll down the second part of the list to review the main Cyber Events that contributed, in my opinion, to change the landscape and the rules of the (information security) game. Many events in this period among whom, IMHO, the most noticeable is the one carried on against Diginotar. Since then our trust in conventional authentication models is not (and will not be) the same anymore.
Of course this is my personal selection. Suggestions are well accepted and if you need more details about the cyber events in 2011, feel free to consult my 2011 Cyber Attacks Master Index. As usual after the page break you find all the references…
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.
In few circumstances I happen to deal with my old (and short) career of Astrophysical. Except when I enjoy to tell my friends the history of the Hubble Constant, and my delusion when I discovered that its value is greater than 50 (most precise determination is 72 ± 8 km/s/Mpc implying a forever expanding Universe which will likely die of Entropy), the chances in which my current activity, information security, and my “would-have-been” career of Astrophysics overlap are really rare.
You may imagine how surprised I have been, when I came across this post by F-Secure concerning the Duqu malware and the images hidden inside the traffic generated by the malware and directed to the C&C Server.
Typically keyloggers try to hide the malicious traffic by resembling legitimate traffic, and of course the infamous Stuxnet-based keylogger is not an exception to this schema, by making the transfer look innocent in case somebody is watching network traffic.
Duqu connects to a server (18.104.22.168 a.k.a. canoyragomez.rapidns.com – which used to be in India) and sends an http request. The server will respond with a blank JPG image. After which Duqu sends back a 56kB JPG file called dsc00001.jpg and appends the stolen information (encrypted with AES) to the end of the image file.
Even if somebody is watching outbound traffic, this wouldn’t look too weird.
Nothing new except the fact that Duqu components contain different JPG files. One of them is an image of the Hubble Space Telescope: NGC 6745 also dubbed Bird’s Head (have a deep look to the image and you will discover why).
NGC 6745 (also known as UGC 11391) is an irregular galaxy about 206 million light-years (63.5 mega-parsecs) away in the constellation Lyra. It is actually a triplet of galaxies in the process of colliding.
Why did they decide to insert an astronomical image? And why just an Image representing three galaxies colliding? A possible metaphorical reference to a cyber war between three nations? The curiosity has stimulated a funny contest by F-Secure even if no interpretation, so far, seems convincing (I also tried to brainstorm but unfortunately my residual notions of Astronomy are not enough, so at first Glance I was not able to find any correspondence.
From an information security perspective, I could not help but notice that this is not the only overlapping between Stuxnet and Astronomy. As a matter of fact the original version of Stuxnet is programmed to automatically switch off on June, 24th 2012: even if a remind to the alleged End of the World according to the Mayan Calendar is unavoidable, this date is also linked to the so-called Grand Cross, corresponding to the date that Pluto in Capricorn squares off against Uranus in Aries.
But there is also another funny aspect and coincidence: do you remember the alleged Stuxnet-like worm that Iran claimed to have detected on April 25 2011? Curiously it was called Stars, and although no evidences of the malware (and not even samples as far as I know) were collected, so that many Information Security experts stated Iran was crying wolf, again the malware was dubbed with a term recalling astronomy. At this point I inevitably (and joyfully) wonder if Stars derived its name from hidden stellar images as in case of Duqu.
- Back to The Future of Stuxnet (paulsparrows.wordpress.com)
While the U.S. and U.K. are debating whether to use Cyberwarfare, someone, somewhere, has decided not to waste further time and has anticipated them, developing what appears to be a precursor of Stuxnet 2.0. In a blog post, Symantec explains how it came across the first samples of the malware thanks to a research lab with strong international connections, which, on October 14 2011, alerted the security firm to a sample that appeared to be very similar to Stuxnet.
The brand new threat has been dubbed “Duqu” [dyü-kyü] because it creates files with the file name prefix “~DQ”, and has been discovered in some computer systems located in the Old Continent. After receiving and analyzing the samples, Symantec has been able to confirm that parts of Duqu are nearly identical to Stuxnet, but with a completely different purpose.
Unlike its infamous predecessor Duqu does not target ICS but rather appears to be a RAT developed from the Stuxnet Source Code, whose main features may be summarized as follows (a detailed report is available here):
- The executables [...] appear to have been developed since the last Stuxnet file was recovered.
- The executables are designed to capture information such as keystrokes and system information.
- Current analysis shows no code related to industrial control systems, exploits, or self-replication.
- The executables have been found in a limited number of organizations, including those involved in the manufacturing of industrial control systems.
- The exfiltrated data may be used to enable a future Stuxnet-like attack.
- Two variants were recovered [...], the first recording of one of the binaries was on September 1, 2011. However, based on file compile times, attacks using these variants may have been conducted as early as December 2010.
Of course this event rises inevitably many security questions: although cyberwar is actually little more than a concept, cyber weapons are a consolidated reality, besides it is not clear if Duqu has been developed by the same authors of Stuxnet, or worst by someone else with access to the source code of the cyber biblical plague (and who knows how many other fingers in this moment will be coding new threats from the same source code).
Anyway one particular is really intriguing: only yesterday the DHS issued a Bulletin warning about Anonymous Threat to Industrial Control Systems (ICS), not event 24 hours after the statement a new (potential) threat for ICS appears in the wild… Only a coincidence?