Heartbleed claims British mums and Canadian tax payers as victims

The critical security vulnerability in OpenSSL known commonly as “Heartbleed” continues to raise alarms, with websites now warning that hackers have breached their systems by exploiting the bug, and stolen personal information about users.

For instance, Mumsnet – a phenomenally popular British parenting website with 1.5 million registered users – has reported that its servers were not only vulnerable, but that users’ data had been accessed as a result:

On Friday 11 April, it became apparent that what is widely known as the ‘Heartbleed bug’ had been used to access data from Mumsnet users’ accounts.

Heartbleed is a security hole that existed in OpenSSL, the security framework which most websites around the world use. There’s a summary of Heartbleed and its effects here.

On Thursday 10 April we at MNHQ became aware of the bug and immediately ran tests to see if the Mumsnet servers were vulnerable. As soon as it became apparent that we were, we applied the fix to close the OpenSSL security hole (known as the Heartbleed patch). However, it seems that users’ data was accessed prior to our applying this fix.

So, over the weekend, we decided we needed to ask all Mumsnet users to change their passwords. So, you will no longer be able to log in to Mumsnet with a password that you chose before 5.45pm on Saturday April 12, 2014.

We have no way of knowing which Mumsnetters were affected by this. The worst case scenario is that the data of every Mumsnet user account was accessed. That’s why we’ve required every user to reset their password.

I must admit I was a little puzzled by the statement. One of the “features” of the Heartbleed bug is that it doesn’t leave any clues that systems have been compromised, making it hard for sites to know that they have fallen victim.

However, BBC technology reporter Rory Cellan-Jones got to the bottom of the mystery when interviewing Mumsnet chief executive and founder Justine Roberts about the security scare.

In that report, Roberts says that she became aware that hackers had accessed users’ passwords when her own Mumsnet account was used without permission by a hacker, who subsequently posted a message claiming that they had accessed the account after exploiting the Heartbleed OpenSSL flaw.

A smoking gun and convincing evidence that Heartbleed was involved? Perhaps not. After all, perhaps Roberts was phished or had keylogging spyware on a computer that she had used that grabbed her password.

Mumsnet Heartbleed advisory

However, Mumsnet was perhaps wise under the circumstances to assume the worst and force members (known as Mumsnetters) to reset any password created on or before Saturday.

And I was pleased to see as well that Mumsnet recommended users change their passwords anywhere else on the net where they might be using the same password.

It’s worth everybody realising that you should never use the same password in more than one place – otherwise you could have an account breach on a site which might not be critically important (Mumsnet, for instance) leading to much more serious hacks of your personal information elsewhere.

Meanwhile, in other news from the other side of the great Atlantic pond, the Canadian tax agency has revealed that social insurance numbers of about 900 taxpayers were removed from CRA systems by hackers exploiting the Heartbleed vulnerability.

Regrettably, the CRA has been notified by the Government of Canada’s lead security agencies of a malicious breach of taxpayer data that occurred over a six-hour period. Based on our analysis to date, Social Insurance Numbers (SIN) of approximately 900 taxpayers were removed from CRA systems by someone exploiting the Heartbleed vulnerability. We are currently going through the painstaking process of analyzing other fragments of data, some that may relate to businesses, that were also removed.

Again, it’s not clear how the Canadian authorities determined that the Heartbleed security hole had been the vehicle for stealing the tax payers’ information.

But one thing is obvious. Now it has been publicly proven how easy it is to exploit Heartbleed, we can expect more and more online criminals to try their luck, and see what information they might be able to glean from online companies and websites that have not taken sufficient steps to protect the data on their servers.

by Graham Cluley, ESET We Live Security

Interview: Windigo victim speaks out on the ‘stealth’ malware that attacked his global company

Operation Windigo was one of the biggest operations against a criminal gang of this year – led by ESET with help from law enforcement and scientists from around the world, including Europe’s CERN (the organization behind the Large Hadron Collider). It highlighted a new, dangerous threat, where criminals target UNIX servers to redirect victims – and successfully took over thousands of servers and sites around the world.

Pierre-Marc Bureau, Security Intelligence Program Manager says, “The malicious gang is using these servers to send spam, redirect web traffic to malicious content, and steal more server credentials to widen their operation.” At its height, Windigo sent 35 million spam messages a day and redirected 500,000 web users to malicious sites. A detailed analysis of the malware and techniques used, and the ongoing battle against Windigo, can be found here, written by Bureau. ESET researcher Oliver Bilodeau chronicles the ongoing battle against Windigo here.

The victims often never knew they were infected. Even today ESET blocks thousands of redirects from infected servers – and this arduous research has thrown light on a new, sinister face of cybercrime.

ESET researchers have helped many companies identify and neutralize the infection, and this effort goes on today. Francois Gagnon, whose company was targeted, reveals what happened when this novel, emerging threat took hold of his large company.

Bureau says, “ESET has invested months of efforts to analyze, understand, and document Operation Windigo. At the peak of analysis activity, six researchers worked on the investigation.  We are very proud of the current results and we continue to monitor the situation. All servers have not been cleaned and the malicious gang behind the operation is still in control of significant resources. There is still a lot of work to do!” Veteran security researcher, writer and We Live Security contributor Graham Cluley says that at one point half a million PCs were attacked a day. Most victims remained unaware.

Francois Gagnon, owner of a business whose servers in France and Canada fell victim for weeks, explains how a large business can fall prey – and not notice.

Were you aware that this sort of attack was possible?

Like most businesses of our size, we knew criminals ‘sniffed around’, but had never been subject of a serious attack. To begin with, we didn’t realize what it was. But this did not feel like something really offensive. It was running in the background pretty silently. No crash or anything happened. I think that’s why it had infected so many servers before people started to react.

Did the nature of the attack surprise you?

One of the first things you learn in any form of hi-tech business is that anything is possible. But we knew from the start that Windigo was something different. It was subtle. No one stole our database – the first we heard was that suspicious behavior like random redirections in some websites were mentioned by some customers.

When did you realize that something very bad was happening?

We discovered that some of our servers were on Email Blacklists – used to pick out spammers. We knew that our system had sent spam. Our customers also mentioned that some of our sites – we have 2,000 – were randomly redirecting customers. It was customer complaints that helped us realize something was badly wrong. Some suspicious behaviors like random redirections in some websites were mentioned by some customers as well.

Just how ‘stealthy’ is this infection – how long did it take you to realize you were a victim?

I suppose we have been infected a few weeks before we realized what was going on.We pushed our investigation further and realized that most servers had been infected after we had opened tickets with cPanel. Their servers were infected and they infected our servers using SSH connections to us.

How did you react? Did you fear your business was under threat?

We rapidly went from not worrying to the worst worry of all – that it was an advanced threat, targeted specifically at us. We run a dozen servers and 2,000 sites. At the beginning we thought that it could be a targeted attack, but we quickly understood that many other businesses were running through the same issues. Plenty of people were talking about those strange behaviors on many forums.

Did you work closely with researchers on this – when did you realize that there were so many other victims?

We were quickly contacted by ESET and were told about how big this infection was and quickly started to work very closely with the research team. We cleaned infected servers but kept some intact for ESET’s investigation. Marc-Etienne of ESET offered advice – clean the server and reinstall. It’s a harsh cure, but we did it. We have now cleaned almost all of our infected servers and re-installed. We worked closely with ESET’s team, and some servers were used to help the researchers understand the infection. We have now-reinstalled most of them.

Why were you targeted?

That is easy. We have a lot of servers, and many customers in France and Canada.

Why do you think your business was targeted?

Simply because we have many servers, and many customers in France and Canada. Thanks to the quick action of ESET, our company’s reputation was not damaged – we listened to our customers and acted. We did not suffer severe financial loss, either.

What are your feelings towards the gang behind this – and the companies still suffering?

This attack is big. Many web hosting companies were infected and didn’t even know what it was. They were told by cPanel to reinstall – and that was it. That was all the help we got. We were lucky. We worked closely with ESET, who helped put it right, and I hope we helped in turn with the Windigo project.

What is the status of your company now?

We are fully operational. We have always been cautious and took seriously any strange or suspicious behavior. If the government took these kind of attacks more seriously and invested more money to help companies such as ESET it may prevent some attacks.

At his request, We Live Security used a fake name for our interviewee. The gang behind Windigo is still at large and reprisals are a possibility.

‘Heartbleed’ encryption flaw leaves millions of sites at risk

A flaw in an encryption technology used to protect major websites including Yahoo has left a huge amount of private data at risk – researchers advise internet users to change all their passwords.

The bug, known as ‘Heartbleed’ is described as one of the “most serious security flaws ever found” according to the Telegraph’s report. It afffects the open-source encryption software OenSSL – which is used on millions of web servers – and has been undiscovered for more than two years. The Telegraph reports that it could have been used to steal passwords, credit card details and even encryption keys, without trace.

Threatpost says that the vulnerability has affected major sites including password manager LastPass and the FBI’s web presence, and says, “Attacks can leak private keys, usernames and passwords and other sensitive data, and some large sites, including Yahoo Mail and others, are vulnerable right now.” Threatpost says that a proof-of-concept exploit for the bug has already been posted on coding site Github.

The researchers who discovered Heartbleed say that it has left private keys, and other secrets exposed “for years”. The researchers tested the vulnerability themselves and were able to, ““We have tested some of our own services from an attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information, we were able steal from ourselves secret keys, usernames and passwords, instant messages, emails and business critical documents and communication.”

The bug was discovered by researchers from Finnnish firm Codenomicon working with Google. A dedicated website helps to explain some of the risks – although the researchers admit they do not know how widely teh bug has been exploited.

“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet,” the firm writes.

“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”

ESET Senior Research Fellow David Harley offers advice on how to deal with problem, “Sites that have never run the 1.0.1 and 1.0.2-beta releases of OpenSSL including 1.0.1f and 1.0.2-beta1 shouldn’t be panicking about this, but those that are running them need to upgrade to 1.0.1g or recompile -DOPENSSL_NO_HEARTBEATS, as recommended by the OpenSSL security advisory. However, they should also be looking for and revoking (and reissuing) compromised keys, and changing user passwords. This applies even to sites that ran a vulnerable version for a while but have upgraded since, as the bug has been around since 2011. While I haven’t checked all the links and resources listed there, this site looks like an excellent starting point for sites that need to know more about the problem and its remediation, as well as the heartbleed.com page. It’s worth remembering that some embedded devices also use OpenSSL: it isn’t just a server issue.”

Open SSL wrote on their site, “A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64kB of memory to a connected client or server. This issue did not affect versions of OpenSSL prior to 1.0.1.”

by Rob Waugh, ESET We Live Security

Monthly Threat Report: March 2014

Top_10_ELG_marz_14_1200x627eng

The Top Ten Threats

1. Win32/Bundpil

Previous Ranking: 1
Percentage Detected: 2.88%

Win32/Bundpil.A is a worm that spreads via removable media. The worm contains an URL address, and it tries to download several files from the address. The files are then executed and the HTTP protocol is used. The worm may delete the following folders:
*.exe
*.vbs
*.pif
*.cmd
*Backup.

2. LNK/Agent.AK

Previous Ranking: 2
Percentage Detected: 1.87%

LNK/Agent.AK is a link that concatenates commands to run the real or legitimate application/folder and, additionaly runs the threat in the background. It could become the new version of the autorun.inf threat. This vulnerability was known as Stuxnet was discovered, as it was one of four that threat vulnerabilities executed.

3. Win32/Sality

Previous Ranking: 3
Percentage Detected: 1.66%

Sality is a polymorphic file infector. When run starts a service and create/delete registry keys related with security activities in the system and to ensure the start of malicious process each reboot of operating system.
It modifies EXE and SCR files and disables services and process related to security solutions.
More information relating to a specific signature: http://www.eset.eu/encyclopaedia/sality_nar_virus__sality_aa_sality_am_sality_ah

4. INF/Autorun

Previous Ranking: 4
Percentage Detected: 1.57%

This detection label is used to describe a variety of malware using the file autorun.inf as a way of compromising a PC. This file contains information on programs meant to run automatically when removable media (often USB flash drives and similar devices) are accessed by a Windows PC user. ESET security software heuristically identifies malware that installs or modifies autorun.inf files as INF/Autorun unless it is identified as a member of a specific malware family.

Removable devices are useful and very popular: of course, malware authors are well aware of this, as INF/Autorun’s frequent return to the number one spot clearly indicates. Here’s why it’s a problem.

The default Autorun setting in Windows will automatically run a program listed in the autorun.inf file when you access many kinds of removable media. There are many types of malware that copy themselves to removable storage devices: while this isn’t always the program’s primary distribution mechanism, malware authors are always ready to build in a little extra “value” by including an additional infection technique.

While using this mechanism can make it easy to spot for a scanner that uses this heuristic, it’s better to disable the Autorun function by default, rather than to rely on antivirus to detect it in every case.

5. Win32/Qhost

Previous Ranking: 5
Percentage Detected: 1.51%

This threat copies itself to the %system32% folder of Windows before starting. It then communicates over DNS with its command and control server. Win32/Qhost can spread through e-mail and gives control of an infected computer to an attacker.

6. HTML/ScrInject

Previous Ranking: 6
Percentage Detected: 1.36%

Generic detection of HTML web pages containing script obfuscated or iframe tags that that automatically redirect to the malware download.

7. Win32/Conficker

Previous Ranking: 8
Percentage Detected: 1.28%

The Win32/Conficker threat is a network worm originally propagated by exploiting a recent vulnerability in the Windows operating system. This vulnerability is present in the RPC sub-system and can be remotely exploited by an attacker without valid user credentials. Depending on the variant, it may also spread via unsecured shared folders and by removable media, making use of the Autorun facility enabled at present by default in Windows (though not in Windows 7).

Win32/Conficker loads a DLL through the svchost process. This treat contacts web servers with pre-computed domain names to download additional malicious components. Fuller descriptions of Conficker variants are available at http://www.eset.eu/buxus/generate_page.php?page_id=279&lng=en.

While ESET has effective detection for Conficker, it’s important for end users to ensure that their systems are updated with the Microsoft patch, which has been available since the third quarter of 2008, so as to avoid other threats using the same vulnerability. Information on the vulnerability itself is available at http://www.microsoft.com/technet/security/Bulletin/ms08-067.mspx. While later variants dropped the code for infecting via Autorun, it can’t hurt to disable it: this will reduce the impact of the many threats we detect as INF/Autorun. The Research team in San Diego has blogged extensively on Conficker issues: http://www.eset.com/threat-center/blog/?cat=145.

It’s important to note that it’s possible to avoid most Conficker infection risks generically, by practicing “safe hex”: keep up-to-date with system patches, disable Autorun, and don’t use unsecured shared folders.

8. Win32/Ramnit

Previous Ranking: 7
Percentage Detected: 1.27%

It is a file infector. It’s a virus that executes on every system start.It infects dll and exe files and also searches htm and html files to write malicious instruction in them. It exploits vulnerability on the system (CVE-2010-2568) that allows it to execute arbitrary code. It can be controlled remotley to capture screenshots, send gathered information, download files from a remote computer and/or the Internet, run executable files or shut down/restart the computer.
9. Win32/Dorkbot

Previous Ranking: 9
Percentage Detected: 1.07%

Win32/Dorkbot.A is a worm that spreads via removable media. The worm contains a backdoor. It can be controlled remotely. The file is run-time compressed using UPX. The worm collects login user names and passwords when the user browses certain web sites. Then, it attempts to send gathered information to a remote machine. This kind of worm can be controlled remotely.

10. JS/FBook

Previous Ranking: n/a
Percentage Detected: 0.95%

JS/FBook is a trojan used for delivery of unsolicited advertisements. The trojan does not create any copies of itself, and the program code is usually embedded in HTML pages.

ESET’s technical dissection of Win32/Sality trojan

code_breaking-623x432

Win32/Sality is a family of malware that has been using a peer-to-peer botnet since at least 2003. It is a file infector and a trojan downloader, the latter of which is mainly used to send spam, although it has been used for different purposes such as faking advertising network traffic, Distributed Denial of Service or VoIP account cracking. All commands and files exchanged through Sality’s P2P network are digitally signed, making it resistant to protocol manipulation. Its modular architecture and the longevity of the botnet show good programming practice and an efficient software design.

We’ve been tracking the Win32/Sality network for quite some time now and we’ve seen more than 115,000 IP addresses reachable from the Internet. Those peers are called “super peers”, which keep the botnet alive and propagate commands to regular peers.

We have seen the same components downloaded over the years with little change to their underlying behavior. Lately, a new component has appeared with some novel characteristics: the ability to change a residential broadband gateway router’s primary DNS address, which differs from the usual FTP password stealer or spambot deployed by Win32/Sality. According to our telemetry data, this component was dropped for the first time at the end of October 2013. It was first publicly discussed by Dr. Web, which has published a technical analysis of one component, the IP address scanner. They named it Win32/RBrute.

This blog will contain

  • An overview of the infrastructure supporting the primary DNS changer component
  • A technical analysis of the two binaries that support the operation
  • A brief analysis of the spread of the operation
  • A review of the similarities between the DNS changer component and the other components dropped by Win32/Sality

A new purpose: changing a router’s primary DNS

This feature adds a new dimension to the Win32/Sality operation. The first component, detected by ESET as Win32/RBrute.A, scans the Internet for router administration pages in order to change the entry for their primary DNS server. The rogue DNS server redirects users to a fake Google Chrome installation page whenever they are trying to resolve domains containing the words “google” or “facebook”. The binary distributed through this installation page is in fact Win32/Sality itself, providing a way for the Sality botnet’s operators to increase its size further by infecting other users behind this router.

The IP address used as the primary DNS on a compromised router is part of the Win32/Sality network. In fact, another malware, detected by ESET as Win32/RBrute.B, is installed by Win32/Sality on compromised computers and can act either as a DNS or a HTTP proxy server to deliver the fake Google Chrome installer.

The Operation

Far from being a new technique, changing the primary DNS on a router is quite in vogue right now for everything from the theft of bank credentials to blocking communications with security vendors, especially with recent reports of vulnerabilities in different routers’ firmware.

Win32/RBrute.A tries to find the administration web pages for routers by downloading a list of IP addresses from its C&C server to scan and then reporting back its findings. At the time of our investigation, Win32/RBrute.A targeted the following routers:

  • Cisco routers matching “level_15_” in the HTTP realm attribute
  • D-Link DSL-2520U
  • D-Link DSL-2542B
  • D-Link DSL-2600U
  • Huawei EchoLife
  • TP-LINK
  • TP-Link TD-8816
  • TP-Link TD-8817
  • TP-Link TD-8817 2.0
  • TP-Link TD-8840T
  • TP-Link TD-8840T 2.0
  • TP-Link TD-W8101G
  • TP-Link TD-W8151N
  • TP-Link TD-W8901G
  • TP-Link TD-W8901G 3.0
  • TP-Link TD-W8901GB
  • TP-Link TD-W8951ND
  • TP-Link TD-W8961ND
  • TP-Link TD-W8961ND
  • ZTE ZXDSL 831CII
  • ZTE ZXV10 W300

If a web page is found, the C&C sends a short list of about ten passwords to the bot and instructs it to perform a brute force password guess attack against the router. If the bot is able to log in to the router, it will then proceed to change the router’s primary DNS server settings. It is interesting to note that only brute force attack is used to gain access to the router’s administration portal; no exploit code is used. The authentication is done with usernames of “admin” and “support”, although previous versions also tried “root” and “Administrator”. Below is a list of passwords we have observed being transmitted from the C&C:

  • <empty string>
  • 111111
  • 12345
  • 123456
  • 12345678
  • abc123
  • admin
  • Administrator
  • consumer
  • dragon
  • gizmodo
  • iqrquksm
  • letmein
  • lifehack
  • monkey
  • password
  • qwerty
  • root
  • soporteETB2006
  • support
  • tadpassword
  • trustno1
  • we0Qilhxtx4yLGZPhokY

In the event of a successful login, the malware changes the primary DNS server to a rogue one, reports a successful infection to the C&C, and continues with scanning the Internet.

Once a router’s primary DNS address is compromised, all DNS queries made by users will go through the rogue DNS server, modifying them to point to the fake Chrome installer page whenever “facebook” or “google” domains are resolved.

Figure 1 This example shows a successful redirection for a domain that is not registered but contains the word “google”.

This operation is somewhat similar to DNSChanger, which drove users to install fake software to further spread malware using a rogue DNS service.

Once a computer is infected by running the fake Google Chrome installer, its primary DNS server will be changed to “8.8.8.8” by updating the following registry key:

HKLM/SYSTEM/ControlSet001/Services/Tcpip/Parameters/Interfaces/{network interface UUID}/NameServer = “8.8.8.8”

It should be noted that the IP address “8.8.8.8″ belongs to Google Public DNS, a legitimate domain name service operated by Google, and it is not involved with Win32/RBrute.

Since infected PCs will no longer be using the router’s DNS server, they will cease to be affected by its bogus redirections. On the other hand, the router is still compromised and will nag each computer trying to resolve “facebook” or “google” domains through its DNS service until they are infected with Win32/Sality. This tactic is far from stealthy and in fact tries to goad the user into infecting its system or simply breaking “google” and “facebook” domains for operating systems that are not targeted (e.g. Linux).

Currently, the goal of this operation appears to be solely to increase Sality’s botnet size.

Technical Analysis

Win32/Sality’s DNS changer component is composed of two binaries: a router scanner and a DNS / HTTP server. Both malware are dropped by Win32/Sality.

Router Scanner Binary – Win32/RBrute.A

At the beginning of the execution, the malware creates a mutex with the name “19867861872901047sdf” to avoid running multiple instances.

It then checks a hard-coded IP address every minute to fetch a command; that command is either a scan instruction or a request to try to log onto an IP address to change the primary DNS.

A scan instruction comes with an IP address to start and the number of addresses to try. Win32/RBrute.A will try to do a HTTP GET on TCP/80, hoping to receive a HTTP Error 401 – Unauthorized. The router model is extracted from the realm attribute of the HTTP authentication schemes. If a targeted router is found, the malware sends back its IP address to the C&C.

Figure 2 Win32/RBrute.A flowchart

The C&C will then issue a request to login to the router using a password provided by the C&C. If the login is successful, the primary DNS server is changed in the router to a host running the Win32/RBrute.B malware.

DNS and HTTP Server Binary – Win32/RBrute.B

This component is divided in three parts: the control thread, the DNS server thread, and the HTTP server thread.

Although both the DNS and the HTTP server thread can be used at the same time, the malware will choose, based on a random value, to be either a DNS or a HTTP server. A constant in the formula ensures that 80% of the infections will act as DNS servers, although we’ve seen this constant set to 50% at the beginning of the operation.

Figure 3 Choosing the DNS or HTTP server thread randomly.

If the chosen server thread would not start, the malware will fall back to the other mode:

Figure 4 Fallback to the other mode if the thread couldn’t start.

The operator can also force a thread to start by sending a specially crafted DNS or HTTP request. A mutex with the name “SKK29MXAD” ensures that only one instance can run on the host.

Control Thread

The control thread is used to report back to the C&C and to reconfigure the server instance.

Every two minutes, the malware will send a packet to a hard-coded IP address containing information about the machine on which it is running. The C&C will then answer with an IP address that will be used to deliver the infected Chrome installation. If the malware is in DNS mode, the IP address served by the C&C will be that of a rogue HTTP server installed on a Sality-compromised machine. In the other case, the C&C will send the IP address of a server outside of Sality’s P2P network, which will be serving the fake Chrome installation page.

Listed below is the host information sent by the control thread to the C&C:

  • Computer name – GetComputerName()
  • Local time – GetLocalTime()
  • Country – GetLocaleInfoA()
  • Windows directory – GetWindowsDirectoryA()
  • Windows product name – from the registry key “HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Product Name”
  • CPU names – from the registry keys
    “HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/<CPU #>/         ProcessorNameString”
  • Memory stats – GetMemoryStatusEx()
  • Result of IsDebuggerPresent()
  • Memory usage of the malware – GetProcessMemoryInfo()
  • Uptime of the malware – in minutes
  • Number of threads n use

The information packet has the format:

0×00   DWORD         Checksum (CRC32)
0×04   WORD          Payload length
0×06   BYTE          Unused
0×07   BYTE          Mode (HTTP – 0×32 or DNS – 0×64)
0×08   BYTE[]       Host information

The screenshot below shows an information packet sent to the C&C.

Figure 5 Host information packet sent to the C&C.
In blue: payload checksum, in red: payload length, in black: encrypted server mode, in green: encrypted host information

The host information, green in the previous example, is the following string encrypted with RC4:

9BC13555|24.03.2014 21:56:27|United States|C:\WINDOWS|Microsoft Windows XP|proc#0 QEMU Virtual CPU version 1.0|1|358|511|1117|1246|0|2|0|0|

The C&C will then answer with a packet with the service IP address to use:

0×00   DWORD         Checksum (CRC32)
0×04   WORD          Payload length
0×06   BYTE          Unused
0×07   BYTE          Command (start – 0×02 or stop – 0×03 the service)
0×08   DWORD         Service IP address (Win32/RBrute.B HTTP server or rogue HTTP server)

DNS Server Thread

The DNS server looks for requests that contain “google” or “facebook” in the domain name. If it finds one, the DNS response it will send back will contain the IP address of a Win32/RBrute.B HTTP server on the Sality network. If the query doesn’t contain “facebook” or “google”, it will relay the query to Google’s DNS servers (“8.8.8.8” or “8.8.4.4”) and will forward the response to the client.

Sending a packet to the server on UDP/53 with “0xCAFEBABE” as the payload will set the “udme” flag in the Windows registry key “HKEY_CURRENT_USER/SOFTWARE/Fihd4″. This flag ensure that the DNS server thread will start at the next reboot, overriding the random process. The server will reply “0xDEADCODE” to confirm the command.

HTTP Server Thread

When receiving a browser request by a user that has been redirected, the HTTP server thread will first look at the browser User-Agent and will have a different behavior consequently.

If the User-Agent contains “linux” or “playstation”, the server will silently drop the connection (how rude!). If the User-Agent makes reference to a mobile (matching one of the following words: “android”, “tablet”, “Windows CE”, “blackberry” or “opera mini”), the server will serve Win32/Sality (!) malware 5% of the time even though these are mobile devices User-Agent; otherwise, the request is dropped. Finally, if the User-Agent contains “opera”, “firefox”, “chrome”, “msie” or anything else, the user will be served the Win32/Sality.

The User-Agent will affect the port on which the query is made on the rogue HTTP server distributing the malware.

User-Agent Port used
Android, tablet, Windows CE, Blackberry, Opera mini 8979
Linux, Playstation None
Opera 4979
Firefox 5979
Chrome 6979
MSIE 7979
Others 6979

 

Any HTTP GET request sent to these ports will serve the fake Chrome installation page… even if you’re browsing with Chrome!

Akin to the DNS server thread, the botmaster can affect the HTTP server behavior by sending a specially- crafted HTTP packet. Specifically, sending a GET or POST request with the User-Agent “BlackBerry9000/5.0.0.93 Profile/MIDP-2.0 Configuration/CLDC-2.1 VendorID/831” will set the “htme” flag in the registry key “HKEY_CURRENT_USER/SOFTWARE/Fihd4″, effectively ensuring that malware will start the HTTP server thread upon reboot, overriding the random process. The server will send “<html>kenji oke</html>” to confirm a successful execution.

The HTTP server also keeps a list of allowed files to be served. If a browser makes a HTTP query on a domain matching “google” or “facebook” to a file not in the list, the server will reply with a HTTP 200 OK, with the following payload:

<html><meta http-equiv=”refresh” content=”0; url=/”></html>
This redirects the browser to the front page — hence serving the fake Chrome installation page. For example, if the user browses to “http://google.com/does-not-exist” and “does-not-exist” is not in the allowed files list, the user will be redirected to “http://google.com” instead of having the usual HTTP 404 error.

We should also note that every HTTP GET query made on the HTTP server that contains the string “.exe” will be forwarded to the rogue HTTP server, regardless of the allowed files list. The rogue server will always answer with an infected binary.

Similarities with other Sality components

Based on the following observations, we believe that the main file infector and all the components previously described are all developed by the same group of people. By looking at each of the components binaries, they all share the same technical details and coding style.

No persistence needed

None of the dropped Sality components, including those discussed before, needs a way to be persistent across system reboot, although some modules might store configuration in the registry. They are always downloaded and launched by the persistent layer: the file infector.

Buffer Initialization

The operators have the standard practice of initializing their buffers with the ‘0’ value. The compiler “visual-c++” doesn’t optimize the following C code when the operators compile a software:

char buf[4096] = {0};

This is compiled into the code displayed in the following screenshots.

Figure 6 Un-optimized initialization of a buffer of size 4096 bytes.

This assembly stub is seen in every component dropped by Win32/Sality.

Bypassing the Firewall

All components that need to receive connections from the Internet share the same code to add a specific rule in the Windows Firewall authorizing incoming requests to go through. It will add the value “[malware file name]:*:Enabled:ipsec” to the following registry key “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/SharedAccess/Parameters/FirewallPolicy/StandardProfile/AuthorizedApplications/List” to achieve this goal. The following screenshot shows a subset of the “add_to_firewall_exception()” function.

Figure 7 A subset of “add_to_firewall_exception()” function, shared by almost all components of Win32/Sality.

In Win32/RBrute.B, this function is called at the beginning of the malware execution:

Figure 8 Calling add_to_firewall_exception() before creating the mutex in the WinMain() function of Win32/RBrute.B.

Same thing found in the Win32/Sality’s spambot component:

Figure 9 Win32/Sality’s spambot component calling the add_to_firewall_exception() function

Infection Statistics

Our data show that the detection for Win32/Sality is currently decreasing or at least staying stable since 2012. We believe that the reduced number of detections is due to the reduced efficiency of the current infection vectors. This might explain why the operators are looking for new ways to spread Win32/Sality.

If we take a look at the detections for the last year, we can see a small increase, around December 2013, in Win32/Sality detections that coincides with the date where the DNS changer component was released in the wild, although those numbers should be taken with a grain of salt since other factors could contribute to variation in its spreading, like being dropped by another botnet.

We’re not sure about the effectiveness of the Win32/Sality router DNS changer operation, since a lot of router configuration portals listen only on the private address space (e.g., 192.168.0.0/16) — making them non-accessible from the Internet. Also, the router password brute force is not very aggressive, only trying a list of about ten passwords.

Conclusion

The usual infection vectors of Win32/Sality might not be sufficient to keep the botnet alive; hence the botnet controllers are deploying new component to grow the botnet. DNS hijacking on routers can be quite effective if done correctly. It can reach a lot of users behind a single router, especially on public access points. As routers are not commonly protected by security solutions, it provides an unrestricted environment to attackers allowing them to try several techniques to steal users’ information. An existing technology that could fix the problem is DNSSEC, since the result of a DNS request is cryptographically signed and hence not prone to tampering. A good security practice that would reduce the scope of the problem is to change the default password on router’s web interface.

by Benjamin Vanheuverzwijn

5 Tips for protecting Windows XP machines after April 8, 2014

Microsoft will cease providing security updates for this operating system on April 8, 2014. Microsoft will release its final security updates for Windows XP, and stop providing support and fixes for it. The operating system will still function the same way it has, and all old updates and fixes will still be available, but regular system updates are used to repair exploits and patch existing security vulnerabilities.

If you cannot get away from Windows XP just yet, there are still a few things you can do to defend your XP machines:

  1. The first thing is to make sure that you back up your computer’s files regularly, and periodically test your backup strategy by restoring backups, preferably on a different computer, a few times a year. This helps ensure that in the event of a catastrophe, you will still have access to the information on your computer. The time to worry about your backups is not when faced with a virus, fire, earthquake or other calamity.
  1. The next thing to do is to make sure that your copy of Windows XP is up-to-date. Although Microsoft will stop making new updates for Windows XP after April 8, 2014, all of the old updates from before then will still be available, and should be applied! This also applies to the device driver software (a device driver is a computer program that allows the operating system to communicate with a particular kind of hardware), which may be available from your computer manufacturer or Microsoft’s Windows Update web site.
  1. In addition to the operating system and drivers, you should also make sure you have the latest versions of your application software on the computer, and that those are fully-patched and updated. Programs like Adobe Flash, Adobe Reader and Oracle Corp.’s Java are frequently targeted by the criminal gangs that develop and use malware, so keeping these up-to-date is just as important as looking after the operating system. Other software that you use, such as Microsoft Office, web browsers and so forth, should be on the latest version and have the latest patches applied as well.
  1. If the computer does not have to be connected to the Internet, disconnect or disable the connection so that the PC can only connect to other machines on the same non-Internet network. This will ensure that Internet-borne threats cannot directly attack your XP PC, and will make it harder for an attacker to steal data off the computer.
  1. Make sure your security software is up-to-date, as well. There are lots of security programs available for Windows XP, and most of their authors have committed to supporting Windows XP for years to come. Some are free, while others are sold as a subscription. A discussion of the features needed to protect Windows XP is outside the scope of this article, but at the very least, I would recommend looking for a security program that combines signature-based and heuristic detection, includes a firewall, and has some kind of host intrusion protection system. Vulnerability shielding and exploit blocking will be useful as well, as Windows XP will no longer be updated by Microsoft to protect against these types of attacks.

While these tips will help, your main goal should be figuring out how to move away from Windows XP. If it is simply a matter of replacing a critical application, work out the cost and build that into your operating budget, likewise for computer upgrades or even replacement computers. That may be a capital expense, and an unwanted one in this economy, however, it is still better than going out of business because outdated computers failed or critical data was stolen.

Having to replace working computers every few years is not fun, but, like other mechanical equipment, computers do wear out and need to be replaced. Software, too, gets updated periodically, not just with security patches, but new features and functionality as well, that can improve your bottom line.

For readers who are using ESET for their anti-malware protection, ESET is committed to supporting the Microsoft Windows XP operating system for 32-bit and 64-bit versions of ESET products at least until the end of April, 2017.

by Aryeh Goretsky

ESET will not end Windows XP products support

windows-xp-54321-623x420

After 8th April 2014, Microsoft will no longer provide system updates for Windows XP.
ESET will support the Microsoft Windows XP versions of ESET products at least until the end of April 2017.

Q: What exactly happens on April 8, 2014? Will Windows XP stop working?
A: On April 8, 2014, Microsoft will release its final security updates for Windows XP, and stop providing support and fixes for it. The operating system will still function the same way it has, and all old updates and fixes will still be available. Regular system updates are used to repair exploits and patch existing security vulnerabilities.

Q: Will ESET products and virus definitions on Windows XP still be updated?

A: Yes. At least until the end of April, 2017 ESET will maintain support for customers with ESET products installed on the Windows XP operating system and will continue to offer the following services during that period:

  • Regular virus signature updates for the latest threats
  • Consistent updates to other parts of the antivirus engine
  • ESET Customer Care support requests

Currently, ESET still supports and provides updates for endpoint products that work with Windows NT 4.0 and Windows 2000, both of which reached end of life (EOL) status in 2004 and 2010, respectively.

Q: Will all versions of Windows XP cease being supported by Microsoft after April 8, 2014?
A: No, not all. Windows XP Professional for Embedded Systems, a special version of Windows XP used in devices such as cash registers, ATMs and ticket machines, etc., will be supported until December 31, 2016. However, that date is fast approaching and if you have devices running XP Embedded you will eventually need to replace or update them.

Q: Are other Microsoft programs going to cease being supported?
A: Microsoft Office 2003 will no longer be supported after April 8, 2014. The next major end of life date is July 14, 2015, which is for Windows Server 2003. If your office has any servers left running Windows server 2003, you should be planning on updating or replacing them as well.

Q: I have to run Windows XP and cannot upgrade or replace my PC. Is there anything I can do to protect myself?
A: Make sure that your copy of Windows XP is fully patched and all your applications are on the latest versions with the latest patches as well. Please note that while your service from ESET will not change, your system could become more vulnerable to threats because it will no longer receive regular system updates from Microsoft.

We recommend that you use the latest version of your ESET product to maintain the highest degree of protection possible with the non-updated Windows XP operating system.

To maintain the highest level of security, we recommend that you upgrade your operating system or move your important data onto a computer with a more current operating system.

by Urban Schrott and Aryeh Goretsky

Follow

Get every new post delivered to your Inbox.

Join 65 other followers