About these ads

Archive

Posts Tagged ‘RAT’

16-30 September 2012 Cyber Attacks Timeline

October 4, 2012 2 comments

Part One with 1-15 September 201 Timeline Here.

September is over and it’s time to analyze this month from an Information Security perspective with the second part of the Cyber Attack Timeline.

Probably this month will be remembered for the massive outage of six  U.S. Banks (Bank of America, JPMorgan Chase, Citigroup, U.S. Bank, Wells Fargo and PNC ) caused by a wave of DDoS attack carried on by alleged Muslim hackers in retaliation for the infamous movie (maybe this term is exaggerated) “The Innocence of Muslims”.

China has confirmed its intense activity inside the Cyber space. Alleged (state-sponsored?) Chinese hackers were allegedly behind the attack to Telvent, whose project files of its core product OASyS SCADA were stolen after a breach, and also behind a thwarted spear-phishing cyber attack against the White House.

Adobe suffered a high-profile breach which caused a build server to be compromised with the consequent theft of a certificate key used to sign two malware strains found on the wild (with the consequent necessary revoke of the compromised key affecting approximately 1,100 files).

Last but not least, the Hacktivism fever has apparently dropped. September has offered some attacks on the wake of the #OpFreeAssange campaign, and a new wave of attacks at the end of the month after the global protests set for September, the 29th, under the hashtag of #29s.

If you want to have an idea of how fragile our data are inside the cyberspace, have a look at the timelines of the main Cyber Attacks in 2011 and 2012 and the related statistics (regularly updated), and follow @paulsparrows on Twitter for the latest updates.

Also, feel free to submit remarkable incidents that in your opinion deserve to be included in the timelines (and charts).

Read more…

About these ads
Categories: Cyber Attacks Timeline, Security Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

February 2012 Cyber Attacks Timeline

March 5, 2012 1 comment

Find here February 2012 Cyber Attacks Timelime Part I.

With a small  delay (my apologies but the end of February has been very busy for me and not only for Cybercrooks as you will soon see), here it is the second part of my compilation with the main Cyber Attacks for February 2012.

Easily Predictable, the Hacktivism is still the main concern for System Administrators, in particular for the ones of Stratfor who suffered a huge leak of 5 million of emails.

On the same front, the threats of the Anonymous for the Friday actions have come true and as a matter of fact Law Enforcement Agencies suffered other remarkable breaches in this month: Infragard for the second time and also Interpol (a new entry) that was taken down after the arrest of 25 members of the collective. Anti ACTA protest also continue to shake Europe as also the delicate economical and social situation in Greece.

Last but not least, this month has also seen an unforgettable leak, affecting potentially more than 1.000.000 Youporn users.

As usual, the chart does not include the events related to Middle East Cyber War Timeline, that you may find at this link, as they “deserve” a dedicated timeline.

After the jump you find all the references, follows @paulsparrows for the latest updates on a regular basis and also have a look to the 2012 Cyber Attacks Timeline Master Index.

Read more…

Back to The Future of Stuxnet

October 19, 2011 4 comments

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?

Advanced Persistent Threats and Security Information Management

October 13, 2011 3 comments

Advanced Persistent Threats are probably the most remarkable events for Information Security in 2011 since they are redefining the infosec landscape from both technology and market perspective.

I consider the recent shopping in the SIEM arena made by IBM and McAfee a sign of the times and a demonstration of this trend. This is not a coincidence: as a matter of fact the only way to stop an APT before it reaches its goal (the Organization data), is an accurate analysis and correlation of data collected by security devices. An APT attack deploys different stages with different tactics, different techniques and different timeframes, which moreover affect different portion of the infrastructure. As a consequence an holistic view and an holistic information management are needed in order to correlate pieces of information spread in different pieces of the networks and collected by different, somewhat heterogeneous and apparently unrelated, security devices.

Consider for instance the typical cycle of an attack carried on by an APT:

Of course the picture does not take into consideration the user, which is the greatest vulnerability (but unfortunately an user does not generate logs except in a verbal format not so easy to analyze for a SIEM). Moreover the model should be multiplied for the numbers of victims since it is “unlikely” that such a similar attack could be performed on a single user at a time.

At the end, however, it is clear that an APT affects different components of the information security infrastructure at different times with different threat vectors:

  • Usually stage 1 of an APT attack involves a spear phishing E-mail containing appealing subject and argument, and a malicious payload in form of an attachment or a link. In both cases the Email AV or Antispam are impacted in the ingress stream (and should be supposed to detect the attack, am I naive if I suggest that a DNS lookup could have avoided attacks like this?). The impacted security device produce some logs (even if they are not straightforward to detect if the malicious E-mail has not been detected as a possible threat or also has been detected with a low confidence threshold). In this stage of the attack the time interval between the receipt of the e-mail and its reading can take from few minutes up to several hours.
  • The following stage involves user interaction. Unfortunately there is no human firewall so far (it is something we are working on) but user education (a very rare gift). As a consequence the victim is lured to follow the malicious link or click on the malicious attachment. In the first scenario the user is directed to a compromised (or crafted) web site where he downloads and installs a malware (or also insert some credentials which are used to steal his identity for instance for a remote access login). In the second scenario the user clicks on the attached file that exploits a 0-day vulnerability to install a Remote Administration Tool. The interval between reading the malicious email and installing the RAT takes likely several seconds. In any case Endpoint Security Tools may help to avoid surfing to malicious site or, if leveraging behavioral analysis, to detect anomalous pattern from an application (a 0-day is always a 0-day and often they are released after making reasonably sure not to be detected by traditional AV). Hopefully In both cases some suspicious logs are generated by the endpoint.
  • RAT Control is the following stage: after installation the malware uses the HTTP protocol to fetch commands from a remote C&C Server. Of course the malicious traffic is forged so that it may be hidden inside legitimate traffic. In any case the traffic pass through Firewalls and NIDS at the perimeter (matching allowed rules on the traffic). In this case both kind of devices should be supposed to produce related logs;
  • Once in full control of the Attacker, the compromised machine is used as a hop for the attacker to reach other hosts (now he is inside) or also to sweep the internal network looking for the target data. In this case a NIDS/anomaly detector should be able to detect the attack, monitoring, for instance, the number of attempted authentications or wrong logins: that is the way in which Lockheed Martin prevented an attack perpetrated by mean of compromised RSA seeds, and also, during the infamous breach, RSA detected the attack using a technology of anomaly detection Netwitness, acquired by EMC, its parent company immediately after the event.

At this point should be clear that this lethal blend of threats is pushing the security firms to redefine their product strategies, since they face the double crucial challenge to dramatically improve not only their 0-day detection ability, but also to dramatically improve the capability to manage and correlate the data collected from their security solutions.

As far as 0-day detection ability is concerned, next-gen technologies will include processor assisted endpoint security or also a new class of network devices such as DNS Firewalls (thanks to @nientenomi for reporting the article).

As far data management and correlation are concerned, yes of course a SIEM is beautiful concept… until one needs to face the issue of correlation, which definitively mean that often SIEM projects become useless because of correlation patterns, which are too complex and not straightforward. This is the reason why the leading vendors are rushing to include an integrated SIEM technology in their product portfolio in order to  provide an out-of-the-box correlation engine optimized for their products. The price to pay will probably be a segmentation and verticalization of SIEM Market in which lead vendors will have their own solution (not so optimized for competitor technologies) at the expense of generalist SIEM vendors.

On the other hand APT are alive and kicking, keep on targeting US Defense contractors (Raytheon is the latest) and are also learning to fly though the clouds. Moreover they are also well hidden considered that, according to the Security Intelligence Report Volume 11 issued by Microsoft, less than one per cent of exploits in the first half of 2011 were against zero-day vulnerabilities. The 1% makes the difference! And it is a big difference!

Five Years of Hacking (Updated)

August 3, 2011 8 comments

Strange Days for Information Security, you may watch my July 2011 Attacks Chart for noticing how troubled July has been. August promises to be even worse, but this is not the point…

The point is that in an Interview to Vanity Fair, which is not tipically an Information Security Magazine, Dmitri Alperovitch, Vice President of threat research at McAfee reported that, for at least five years, a high-level hacking campaign, dubbed Operation Shady RAT (like Remote Access Tool), has infiltrated the computer systems of national governments, global corporations, nonprofits, and other organizations. This infiltration has made more than 70 victims in 14 countries for what has been defined “Biggest-ever series of cyber attacks uncovered”, an attack so big that, according to Alperovitch: “It’s been really hard to watch the news of this Anonymous and LulzSec stuff, because most of what they do, defacing Web sites and running denial-of-service attacks, is not serious. It’s really just nuisance.”

Victims included government agencies in the United States, Taiwan, South Korea, Vietnam, and Canada, the Olympic committees in three countries, and the International Olympic Committee. Rounding out the list of countries where Shady rat hacked into computer networks: Japan, Switzerland, the United Kingdom, Indonesia, Denmark, Singapore, Hong Kong, Germany, and India. The vast majority of victims—49—were U.S.-based companies, government agencies, and nonprofits. The category most heavily targeted was defense contractors—13 in all.

Courtesy Of McAfee

In addition to the International Olympic Committee, the only other victims that McAfee has publicly named are the World Anti-doping Agency, the United Nations, and ASEAN, the Association of Southeast Asian Nations (whose members are Indonesia, Malaysia, the Philippines, Singapore, Thailand, Brunei, Burma, Cambodia, Laos, and Vietnam).

All the signs of the attack point to China. If confirmed this would be the third attack discovered by McAfee originating from China, after Operation Aurora and the Night Dragon.

One thing is clear: if Vanity Fair is dealing with Information Security, there is really something strange. At least let us hope this is not the sign Information Security is simply becoming a matter of fasion.

Meanwhile, after the Vanity Fair preview, McAfee has released its report on Shady RAT. McAfee was able to gain access to one specific Command & Control server used by the intruders, collecting logs that reveal the full extent of the victim population since mid-2006 when the log collection began. The results are described inside the documents and Curiously China, which was reported by the press as the alleged author of the attack, is never expressely quoted.

Courtesy Of McAfee

Interesting to say, this report raised several doubts on McAfee Competitors. As an example, Sophos, on a dedicated post, considers that there’s nothing particularly surprising in McAfee’s report since companies get often targeted by hackers, who install malware to gain remote access to their computers and data, sometimes driven by motivations for hacking which extend beyond purely financial (for instance, IP theft, economic, political, etc motivations).

Moreover, Sophos wonders why McAfee did not disclose what kind of information was stolen from the targeted organisations, and how many computers at each business were affected.

In any case I noticed with pleasure that, like I did, Sophos was also surprised from the fact the preview was first released on Vanity Fair…

Some Random Thoughts On RSA Breach

April 10, 2011 15 comments
Security tokens from RSA Security designed as ...

Image via Wikipedia

June 7 Update: RSA admits some stolen seeds were used to attack Lockeed Martin and will replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks.

May 31 Update: Wired reports that L-3, a Second Defense Contractor, has been targeted by an attack using information stolen during the RSA Breach

May 28 Update: Other Random Thoughts after Several Sources reported that Lockeed Martin the “largest U. S. Defense contractor” was presumably hit by an alleged attack led by mean of compromised seeds.

Some days have passed since the RSA breach, but the echo has not yet gone. Maybe RSA did not contribute efficiently to suppress rumors as, in the meantime, has continued to issue ambiguous advices to its customers, and, more in general to the infosec community. Only few days ago a post from the Company has explained some more details about the breach. According to the above mentioned post written by Uri Rivner, RSA Head of New Technologies, the breach was due to an APT (Advanced Persistent Threat) exploiting a zero-day Adobe Flash vulnerability (CVE-2011-0609) embedded into an excel spreadsheet attached to an email from an appealing subject “2011 Recruitment Plan”. The poisoned file injected a RAT (Remote Access Tool) used by the attackers to gain privileges and move freely into the network up to the final target.

Curiously, the subject was so appealing to convince some users to recover it from the quarantine folder: to lure victims through pecuniary topics is a consolidated method of cyber scam at all levels, and RSA has not made exception in this circumstance.

This attack deserves much attention from the infosec community as we are used to think to multi-layer protection technologies but too often forget that the individuals are the first (and weakest) layer of defense, hence also the best technology, even that from a primary manufacturer as RSA is, risks to be very little useful, or even useless, if not supported by an adequate education of users. Phishing is considered an old attack method, mainly used in the past to lure individuals. Today its combination with 0-day vulnerabilities is proving to be a devastating weapon for Cybercrime targeting enterprises. (It is not a combination that also the Night Dragon Attack, maybe amplified by McAfee Marketing in response to the attention gained by its eternal competitor Symantec for the role played in the identification of Stuxnet, was initiated by a some phishing emails). Is this the reason why, on April the 1st, RSA decided to acquire NetWitness, a company whose technology, as stated in the press release:

provide precise and pervasive network visibility, enabling security teams to detect and remediate advanced threats while automating the incident investigation process.

Without invoking philosophical considerations, the main question is: are secureID users really safe or do they need to worry about their level of security after the breach?

My opinion is that the RSA breach was conceived as the final stage of a large scale attack to a wide organization making use of RSA tokens, since in most cases (we should hope in all cases), the alleged stolen information, alone, is not enough to perpetrate a successful attack unless the RSA breach was not preceded by other attacks perpetrated by the same author(s) aimed to steal the missing piece of the puzzle.

Taking a step back, on March, the 17th when the breach was announced, the open letter on the RSA web site, stated that:

Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

Of course the “potentially be used to reduce the effectiveness” sounds a little bit ambiguous. Anyway a subsequent bulletin for RSA customers was released on March, the 21th 2010, stating that:

RSA SecurID technology continues to be a very effective authentication solution. Whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers.

Said in few words according to the Company, the stolen information, alone, may not be used to perform a successful attack. Even if the RSA algorithm (in its post-2003 implementation using AES hash with 128 bit ECB blocks) is not public, RSA statements sound true since some quantities used in the hash are neither related to the 128 bit random seed nor to the 64 bit standard ISO representation of Current Time: they are a 32-bit token-specific salt (supposedly the serial number of the token, which may have been subtracted in the breach, and a 32 bits padding). Today this quantities are not used for security purposes, but simply to shape the blocks to 128 bits as requested by AES hash (enjoy the math of AES hash algorithm at this link).

Courtesy of Wikipedia

Of course, together with the PIN known only by the user, there is, in theory, enough stuff to make an attack unsuccessful in case a (organized) gang of cybercrooks come in possess of the database mapping a SecurID token with its seed. But unfortunately, as often happens, reality is much worse than theory, so one discovers that someone reversed the RSA algorithm and developed Cain & Abel, which, by mean of an RSA SecurID Token Calculator is able to retrieve the One Time Password from an RSA token, provided the malicious user owns the file contained in the RSA Authentication Server (mapping the token serial number with the seed) and knows the User PIN. Small “negligible” detail: from version 4.9.10 (released in 2007), Cain & Abel supports AES-128 of post-2003 securID implementation.

So at the end, supposed the information stolen from RSA is comparable, or could be brought in some manner to be comparable (in form and content) with that contained in each RSA Authentication Server (and it should be since each RSA token must be synchronized with its own authentication server), Cain & Abel (or a similar tool) could be applied to successfully obtain the password for each token whose seed was stolen, provided the attacker come somehow in possess of the only missing information: the user PIN.

There are several ways to steal a user PIN, from Social Engineering to sniffing. Often social engineering leverages the shallowness of the user or the lack of policies of the organization (yes… In my life I have also seen some SecurID tokens with attached a post-it containing the PIN). Of course when I mention sniffing I do not mean network sniffing since both in case of an organization adopting SecurID tokens either in native ACE mode or RADIUS mode, the PIN is never transmitted in clear, anyway we have not to forget that many organizations adopt software tokens (also in mobile devices), so one might not exclude a priori that a large scale attack had deserved the development and the deployment  of a Trojan tailored to steal PIN from RSA software tokens.

This is the reason why I expect that the target of the attackers was not RSA but an important organization making use of RSA securID authenticators. As a consequence I would not be surprised if a malicious tool to sniff PINs from RSA Software authenticators were discovered.

Seeds on the Black Market?

If I fly with my imagination I do not feel to completely exclude that the stolen information one day could be available in the black market to target other major organizations besides the presumed original victim: in fact do not forget that Banks worldwide are among the bigger customers of RSA). This is the reason why, RSA users should take in serious consideration the recommendations provided by the Company the day after the breach.

Personal Note 1

The Italian Security Professional group on Linkedin dedicated an interesting post to the RSA affaire (in Italian) which is continuously updated as new information is released. Today the last controversial advice: it looks like RSA will provide hack data in exchange of customer secrecy (thanks to Andrea Zapparoli Manzoni for reporting this information). This advise comes in the same day in which I discovered a further controversial article (actually dating back to a couple of weeks ago) reporting a possible (unconfirmed) backdoor in the SecurID tokens requested by the NSA in exchange of the authorization to export the technology…  Very strange the temporal proximity with the breach, as much strange the fact that this information is passed nearly unnoticed…

Personal Note 2

I must confess I was really intrigued on better understanding how the SecureID algorithm works for understanding which is the missing part “to make the successful attack complete” (to use the same words in the RSA bulletin).

Since, as already mentioned, the RSA algorithm is not public (even if the first version pre-2003 was reversed in 2000) I only may perform some kind of speculations. In these days I searched all the possible documentation and probably in this link I found a scenario which might be quite close to reality. Please notice that what follows is a mere speculation.

Since the beginning of 2003, SecurID performs an AES hash operation, in standard ECB mode, to hash

  • a 128-bit token-specific true-random seed;
  • a 64-bit standard ISO representation of Current Time in the following format: year/month/day/hour/min/second;
  • a 32-bit token-specific salt (the serial number of the token);
  • another 32 bits of padding, which can be adapted for new functions or additional defensive layers in the future.

The latter two are not a specific security feature but are needed since the AES-Hash operation needs 128 bit multiples. The 64 bit standard ISO representation is derived from a 32-bit representation of the current time (GMT) in seconds since midnight on 01/01/86, from which, only 22 bits are used from the original value, leaving 222 or 4,194,304 total possible time values. These inputs, conflated and hashed by the AES, generate the series of 6-8 digit (or alphanumeric) token-codes that are continuously displayed on the SecurID’s LCD as a “one-time password.” Rolled over every 30 or 60 seconds. In order to implement a pure two factor authentication, the user must insert a known PIN in order to complete the authentication process (but this is configured by the administrator).

Follow

Get every new post delivered to your Inbox.

Join 2,707 other followers