Firefox 0day in the wild is being used to attack Tor users

Enlarge

There's a zero-day exploit in the wild that's being used to execute malicious code on the computers of people using Tor and possibly other users of the Firefox browser, officials of the anonymity service confirmed Tuesday.

Word of the previously unknown Firefox vulnerability first surfaced in this post on the official Tor website. It included several hundred lines of JavaScript and an introduction that warned: "This is an [sic] JavaScript exploit actively used against TorBrowser NOW." Tor cofounder Roger Dingledine quickly confirmed the previously unknown vulnerability and said engineers from Mozilla were in the process of developing a patch.

According to security researchers who analyzed the code, it exploits a memory corruption vulnerability that allows malicious code to be executed on computers running Windows. The malicious payload it delivers, according to an independent researcher who goes by the Twitter handle @TheWack0lian, is almost identical to one that was used in 2013 to deanonymize people visiting a Tor-shielded child pornography site. The FBI ultimately acknowledged responsibility for the exploit, which was embedded in Web pages served by a service known as Freedom Hosting.

Read 5 remaining paragraphs | Comments

San Francisco transit ransomware attacker likely used year-old Java exploit

Enlarge (credit: Zboralski)

The attacker who infected servers and desktop computers at the San Francisco Metropolitan Transit Agency (SFMTA) with ransomware on November 25 apparently gained access to the agency's network by way of a known vulnerability in an Oracle WebLogic server. That vulnerability is similar to the one used to hack a Maryland hospital network's systems in April and infect multiple hospitals with crypto-ransomware. And evidence suggests that SFMTA wasn't specifically targeted by the attackers; the agency just came up as a target of opportunity through a vulnerability scan.

In an e-mail to Ars, SFMTA spokesperson Paul Rose said that on November 25, "we became aware of a potential security issue with our computer systems, including e-mail." The ransomware "encrypted some systems mainly affecting computer workstations," he said, "as well as access to various systems. However, the SFMTA network was not breached from the outside, nor did hackers gain entry through our firewalls. Muni operations and safety were not affected. Our customer payment systems were not hacked. Also, despite media reports, no data was accessed from any of our servers."

That description of the ransomware attack is not consistent with some of the evidence of previous ransomware attacks by those behind the SFMTA incident—which Rose said primarily affected about 900 desktop computers throughout the agency. Based on communications uncovered from the ransomware operator behind the Muni attack published by security reporter Brian Krebs, an SFMTA Web-facing server was likely compromised by what is referred to as a "deserialization" attack after it was identified by a vulnerability scan.

Read 6 remaining paragraphs | Comments

Shamoon Rebooted?

We have recently received notifications and samples from impacted organizations in the Middle East that have hallmarks of the Shamoon campaign from 2012. The main component of these attacks was the usage of a wiper component that, once activated, destroyed the hard disks of infected machines.

The initial infection vector for the recent attacks is unknown. Analyzing the submitted files, we started to recognize similar tactics and procedures that we discovered in 2012.

When the initial executable is run, it creates a copy of itself in the %SystemRoot%\System32 folder using the name trksrv.exe and starts itself as a new service.

After the trksvr service has starts, it drops files, in either a 32- or 64-bit version, depending on the system of the victim. Reverse engineering one of the binaries, we discovered the following random-name examples that could be used for these 32- or 64-bit binaries:

  • ntdsutl.exe
  • power.exe
  • rdsadmin.exe
  • regsys.exe
  • sigver.exe
  • routeman.exe
  • ntnw.exe
  • netx.exe
  • fsutl.exe
  • extract.exe

Some of these filenames are the same as those used in the first Shamoon attack; other filenames are new.

This dropped executable is the wiper module and is responsible for overwriting various files on the hard disk and also the master boot record and boot sector.

The wiper module also drops the file drdisk.sys, which is a standard component from a commercial application (Eldos) that allows programs low-level access to hard disk drives. This driver was used in the first Shamoon attack, and again in this new campaign.

The wiper module initiates an enumeration of files on the victim’s disk and writes the results to a file with the extension “.pnf,” the file that the wiper module will use as an input for which files to wipe.

We are continuing our investigation into this campaign, and intend to publish further analyses.

McAfee Labs detects samples with the following names:

  • W32/DistTrack
  • Artemis detection
  • DistTrack!sys
  • Trojan-FKIQ![hash]
  • Trojan-FKIR![hash]

 

 

The post Shamoon Rebooted? appeared first on McAfee Blogs.