2016 Security Predictions

As the year comes to a close and winter sets in, we like to look back at the year that was and do our best to prepare for the year ahead. What would the holiday season be without yuletide cheer, excessive commercialization and of course…security predictions? Yes, it’s time to join my colleagues in the security industry, peer into my magical crystal ball and provide a glimpse of what is to come. Grab a nice hot beverage, curl up next to the fire and enjoy!

PII is the new hotness

2015 continued the trend of major retail data breaches resulting in bulk debit and credit card theft, but it also marked a shift that will accelerate in 2016. In the coming year, expect attackers to move away from targeting financial information and instead target personally identifiable information (PII). In 2015, we continued to see credit/debit card theft at the likes of America’s Thrift Stores, The Trump Hotel Collection, Hilton Hotel properties, Service Systems Associates, Hershey Park, Harbortouch and White Lodging, but in 2015 we also learned of major breaches in the healthcare (Anthem and CareFirst BlueCross BlueShield) and government (Office of Personnel Management) sectors that targeted PII. The quest for PII is being driven by two separate groups of attackers. While nation states desire PII for espionage, criminals are also shifting to PII as it is generally more valuable than credit and debit cards, which are getting more challenging to harvest in bulk due to greater awareness of the problem and new technology. Why would a social security number be of greater value than a credit card number, which can be used directly to procure goods and services? PII is highly sought after in the underground as it can be leveraged to commit financial fraud such as applying for credit, submitting false medical/insurance claims or filing fraudulent tax refunds. Whereas credit cards can be easily cancelled, changing one’s name, address and social security number generally isn’t an option, so the stolen data remains valuable for a longer period of time. The shift will be motivated in part by the push to move to Chip and PIN (aka EMV) debit and credit cards, which combat RAM scraping malware with tokenization. Don’t however expect credit and debit card fraud to disappear entirely as EMV technology has seen slow adoption in the US, despite an October 2015 deadline and the technology does nothing to combat card not present (online) theft. In 2016, attackers will increasingly target sectors known to store bulk PII including finance, healthcare and government entities to harvest valuable PII.

Trusted Partner Attacks 

Breaking in through the front door isn’t always the best option as it tends to be be well defended. The same is true in cyber attacks. A head on assault is expected, but companies rely on a plethora of technology partners and often communicate with them through trusted digital channels. History suggests that enterprises aren’t doing enough to ensure that trusted partners maintain their security to the same standards that would be demanded if those services were delivered internally. In the past we have seen this with the Target breach which occurred when Fazio Mechanical, an HVAC vendor was compromised. Likewise, the OPM breach began with a compromise at KeyPoint Government Solutions. Compromised partner networks aren’t always used to directly access another network but can also play an indirect role in a broader attack. For example, attackers that ultimately targeted JPMorgan Chase, Scottrade and E-Trade for money laundering also compromised G2 Web Services LLC, which specialized in monitoring and blocking fraudulent banking transactions. Once inside the G2 network, they could ensure that their money laundering schemes went undetected. Enterprises are increasingly outsourcing technology to streamline costs in areas that are not a core focus. For attackers targeting a supplier that often has lesser security controls than the larger entity that it serves, a successful compromise can be a gold mine. Not only does the breach provide a backdoor into the original target, but it also opens doors to other enterprises being serviced by the same vendor. Hackers have learned from successful attacks exploiting such relationships and will accelerate their focus in this area in 2016. Enterprises need to extend security policies and procedures beyond their own systems and personnel. Trusted partners should be expected to adhere to the same security controls and be subjected to audit and penetration tests to ensure that they are adhering to agreed upon standards.

Ransomware 2.0 goes corporate

Ransomware has managed to hit a sweet spot. Users are all too willing to begrudgingly pay an expensive but not excessive ransom in exchange for the return of their precious data. Even the FBI are recommending that it’s easier to pay than fight. The wildly profitable CryptoLocker has attracted many clones since it was largely knocked offline following Operation Tovar. Many of these clones, including more popular variants such as CryptoWall and TorrentLocker largely followed the proven formula but we’re starting to see variations such as ransomware focused on Linux and mobile platforms. The former is especially important as it’s more likely to impact the websites and code repositories of enterprises, who in our experience are also very willing to pay up rather than risk losing critical intellectual property. Expect ransomware to become increasingly corporate focused in 2016 and as it does, enterprises won’t get away with paying consumer rates. The criminals behind the ransomware campaigns are savvy and once they realize that they’ve locked up source code and financial documents that haven’t been properly backed up, you can expect prices to skyrocket…and be paid.

The extortion data breach

The Sony Pictures, Ashley Madison and Hacking Team breaches all share a common theme – the goal of the attacks was to humiliate the respective companies and perhaps inflict financial damage. There did not however appear to be a profit motive in any of the attacks. Sony Pictures, after already having proven to be a vulnerable target after two successful attacks against the Play Station Network, had it’s dirty laundry aired by hackers allegedly backed by the North Korean government as retaliation for producing a satirical movie about their leader. Ashley Madison and Hacking Team are believed to be the victims of hacktivists that disagreed with their corporate philosophies. Despite what has been stated by the media, there is little to suggest that these were sophisticated attacks. Rather, once the attackers were able to gain access to the internal network, they were able to roam freely and collect troves of sensitive data from email and file servers, which was then dumped online. Criminals have no doubt taken notice of the extreme damage that small teams have been able to achieve and know all too well that some would be willing to pay millions to stay out of the headlines. This is one prediction that is likely already taking place but we’ve yet to hear about it as the attackers have held up their part of the bargain to remain quiet in exchange for the hush money.

No AV? No problem.

Foreshadowing the death of antivirus (AV) is hardly a bold prediction. Even AV executives are calling for it. While you won’t see a sudden wholesale move away from AV, as it remains the first line of defense for corporate PCs, we’re now hearing with some regularity, CTOs shifting away from paid AV solutions to ‘good enough’ free AV or solutions baked in at the O/S level, such as Microsoft’s Windows Defender or Apple’s File Quarantine (aka XProtect). As enterprises adapt to the Post-PC era, running an end user device without AV is no longer seen as a risky bet. OS X machines rarely run AV in a corporate environment and on iOS devices it’s not even an option. Enterprises realize that AV is focused on known vulnerabilities and they must free budget dollars to shift to more dynamic security controls capable of identifying and protecting against 0day and targeted attacks. With limited budgets, expect fewer enterprises to open the checkbook for host based AV, instead reallocating the funds to solutions such as network/cloud based sandboxing solutions.

Android finally cleans up it’s act

Android is well on it’s way to becoming the Windows of the mobile malware world. With 99% of mobile infections, Android is the only game in town when it comes to infected tablets and smartphones. Love it or hate it, Apple’s walled garden and refusal to allow downloads from third party app stores has paid security dividends. Sure, Google Play has Bouncer and he’s done a fine job of keeping the miscreants out, but that’s of limited value when users are willing to go to shady Chinese app stores to save a buck on Candy Crush. Google clearly knows that this will hurt them in the long run, especially in the enterprise space and began making changes with Marshmallow, the latest Android flavor when they switched to Granular App Permissions to make it more clear what control an app ultimately gains when installed. This however was a small step and Google will need to get much more aggressive going forward. Not wanting to lose ground in the enterprise, where Apple has now pivoted, they have little choice. While cutting off third party app store access altogether would alienate too much of the user base, expect the next iteration of Android to to start cracking down on third party app stores. Since Jelly Bean 4.2, embedded cloud based anti-virus scanning was added through the Verify Apps feature. While yet another improvement, this is clearly not enough as we regularly identify and blog about apps from alternate Android app stores that are malicious in nature. Google will need to take more drastic steps and a likely change is restricting the permissions available to apps not vetted through the Google Play submission process.  Expect side-loaded apps requesting Administrator permissions to become a thing of the past.  Some developers will push back, but Google will have little choice if they want to get malware under control. Google will also begin to mandate acceptable timeframes for patches and firmware upgrades, which are now largely under the control of the OEM partners. It does little good when new security features are added, but they’re unavailable to users with non-Nexus devices. These steps won’t eliminate Android malware, especially with Android’s slow O/S upgrade cycle, but they will raise the bar for third party app stores, just as Bouncer did for Google Play.

Terrorists catch the hacking bug

This last prediction is one that saddens me to write, but I feel is inevitable and one that can’t be ignored. Terror organizations are continually searching for new avenues to instill fear and they require significant funding to further their hateful agendas. Skilled hackers can aid on both fronts. Cyber attacks can clearly be used by terrorists to obtain intelligence for future attacks and we’re already seeing early signs of cyber attacks being used to cause physical damage. Last year, hackers caused significant damage to a German steel mill when they disabled systems responsible for controlling a blast furnace. This wasn’t just kids playing around either, as the attacks reportedly required substantial knowledge of industrial control systems in order to succeed. With almost all industries reliant on computerized systems, the potential attack surface is enormous. Hacking is also extremely lucrative. The CrytoLocker ransomware authors for example were able to make millions in just a few short months. Such potential is surely in the sights of terror organizations, especially those such as ISIS, which have shown a new affinity for being tech savvy when it comes to recruiting and propaganda. Sadly, terrorists won’t necessarily need to acquire the necessary skills themselves as there are no shortage of cyber criminals all too willing to rent their skills out to the highest bidder and look the other way.

Password reuse attacks decline

And now for some good news. Password reuse attacks will begin to decline. Attackers are quite happy to compromise virtually any site even if it’s not the endgame as they can generally recover information and resources that will aid in other attacks. It’s always of great benefit for an attacker when they’re able to uncover a database of unencrypted usernames and passwords, because human nature suggests that those same credentials are used at many, many other sites. Most people use a handful of passwords at best, therefore attackers will write scripts to attempt automated logins at popular social networking, banking, etc. sites to see if the credentials can be reused. This presents a real challenge for end users as they have no control over how their credentials are stored or secured once they’re turned over and in the event of a compromise, changing passwords to every site where those same credentials were used is generally an impossibility. Think of your favorite password that you’ve used over the years. How many sites have you used it on? You lost count, didn’t you. Fortunately, this is starting to change thanks in large part to the smartphone. Smartphones can be many things but they make for a handy secure, always with you, data repository. As such, people are starting to adopt password managers such as 1Password, LastPass, etc., as they have user friendly smartphone apps that present a convenient option for always having sensitive data such as passwords within easy reach. Advancements in biometrics are also helping the cause with consumer grade fingerprint scanners now becoming a standard feature on modern smartphones. This not only makes accessing that password repository quicker and more user friendly, but also finally makes it an option to do away with passwords altogether. While not as user friendly, most major Internet layers are also adding two-factor authentication as a standard option. Finally, the average user has realistic authentication options that don’t involve sticky notes.

Say goodbye to browser plugins

The love affair with browser plugins has been on the decline and we’re finally at a point where the average user can do away with them once and for all. Flash had a particularly tough year after Firefox disabled the plugin by default after the Hacking Team breach revealed the existence of new Flash 0days. Facebook’s Security Chief also piled on asking “Adobe to announce an end-of-life date for Flash”. This after Steve Jobs famously refused to include Flash on iOS, claiming that it had been the “number one reason Macs crash” and had “one of the worst security records”. The bashing certainly isn’t unfounded with browser plugins remaining the number one way that Exploit Kit authors target PCs, primarily targeting Java, Flash and PDF vulnerabilities. At least for websites, Flash is on life support, Java died a couple of years ago and PDF plugins are no longer required as bowser vendors have baked in native support. Competitors like SilverLight never fully caught on and web apps that would historically have used custom plugins for playing video or screen sharing, have now migrated to HTML5. Not supporting plugins was one things that mobile browsers got right from the get go. In 2016, expect all major browsers to get serious about finally killing off plugin support by default.

The encryption showdown

Encrypted communications have long been the bane of law enforcement and those in the intelligence communities. As privacy concerns mount, thanks in part to the Snowden revelations, leveraging strong encryption for messaging and data storage is no longer the realm of geek speak. It is an expected feature and is quickly becoming a differentiating feature. iOS now encrypts data by default and Android while lagging behind, is fighting to get there. Popular chat applications like WhatsApp tout encryption as a key feature and Apple’s iMessage app, which features end-to-end encryption and no central key store, is often referenced by law enforcement when arguing for a ‘back door’. 2016 will be the year this battle comes to a head. While politicians used to dance gingerly around the topic given the privacy abuses exposed by the Snowden revelations, recent terrorist attacks have brought this issue front and center. Multiple pieces of legislation are sure to be introduced that will propose weakened encryption protocols or procedures to grant law enforcement access to decrypted communications as needed. As we’ve learned however, you can’t be ‘mostly secure’ any more than you can be ‘kind of pregnant’. Weakening encryption to benefit law enforcement will also reduce security for everyone and if the US government mandates a ‘backdoor’, you can be rest assured that China, Russia, [pick a country] will be demanding the same for their citizens. This is one battle that will have serious repercussions for years to come. Here’s to hoping that Apple, Google, Microsoft, Yahoo! and the like manage to prevail.

Should be another action packed year on the cyber security front. See you next year!

Michael Sutton
CISO
Zscaler

Crypto-Ransomware Running Rampant

There's no doubt that ransomware is one of the most popular malware threats of 2014. Zscaler is not alone in this opinion, as other security firms have observed up to a 700% increase in infection rates to ransom-like malicious activity on victim PCs.  It's no wonder the attacks are so effective when for example, the delivery mechanism is designed to impersonate a legitimate service such as a harmless eFax.

This link is seen from a phishing e-mail.

Ransomware attacks can be monetized quickly and efficiently without the need to create a large scale botnet or expose the attacker's affiliate ID via click-fraud schemes. We've seen multiple attack vectors leveraged to target end users. Some vectors we have monitored include phishing email links or a malvertising campaign which leverages exploit kit distribution. Attackers will often pose as legitimate services, such as a law enforcement agency or a mass media outlet, in order to lure the unsuspecting victim into their scheme.

We recently encountered a ransomware campaign leveraging phishing e-mails purporting to be from the Australian Postal Services. The spam campaign themes used by the attackers involve tracking services or mobile invoices containing a link to the malicious content.  Upon completion of a CAPTCHA, the user is provided a zip file which contains a malicious executable posing as a PDF document.

At the time of research, this particular file shows a a detection rate of 16/53 antivirus engines on Virustotal. Before the victim even has a chance to realize their mistake, they are greeted by a message informing them of just how impacted they are.

It's rare for a piece of malware to name itself to the victim...

The goal of Cryptolocker or any other Crypto-Ransomware attack is to encrypt personal files and hold them hostage. The attacker encrypts the files using a specific key which is either obtained during the phone home request to a Command & Control (C2) server, or hard-coded within the malicious executable. In  this case, the malicious executable itself is falsely presenting itself as a valid executable for AQQ IM. 

AQQ is a popular IM application

Cryptolocker's encryption has been an evolving piece of this threat, often relying on asymmetric encryption to lock the victim's files.  In this particular version, the Cryptolocker variant targeted the following folders for encryption:

•  C:\MSOCache\All Users\
•  C:\Users\[Public/Username]\

The ".encrypted" files can only the key controlled by the attacker can release them.

The threat will also drop a file in the Windows directory and an associated registry key to launch the file upon boot.  This will ensure that the threat will remain persistent if the victim attempts to reboot their system.

The autostart value is randomly generated.

Cryptolocker will phone home to a hard-coded malicious domain via SSL. The SSL certificate is signed using the printable string 'debian'. This transaction is the secure communication which will provide the specific key needed to encrypt the victim's files.

Viewing the C:\Windows\uhjrajyj.exe in this case will reveal the hardcoded domain used to phone home.

The phone home address is hard-coded within the malicious payload.

Decrypted SSL traffic reveals the initial call back attempt that contains a POST request with victim's machine name and unique ID as seen below:

Decrypted call back attempt

This variant was found to be using a Domain Generation Algorithm for the C2 server communication, similar to the phone home method of Zeus.GameOver.

DGA activity

These domains are largely returning 504 errors now as they have either not yet been registered or have already been shutdown.  A few do were still live at the time of the research.  Zscaler inspected the associated IP addresses and found them to be hosted in the Russian Federation. The two server IP addresses of note at the time of the blog are 46.161.30.20 and 46.161.30.19.  Active ransomware URLs leading to these servers include:

• usygoseqowapadoh[.]com:443
• usygoseqowapadoh[.]com/topic.php
• octoberpics[.]ru:443
• octoberpics[.]ru/topic.php

Conclusion

Administrators should be on the lookout for the above connections as they likely indicate a compromised system. Given how prevalent this threat is, the U.S. Government recently released an associated alert on the US-CERT site. 

Taking regular backups of your personal files remains a user's best chance at mitigating the threat if they have been hit by this attack. It is also important for system administrators to enforce  strict file-type access control policies surrounding the download of archive and executable files from unknown sources.

The Story of a Trojan Dropper III

Introduction:

In previous posts (story of Trojan dropper part I, II) we performed both static and dynamic analysis on the threat and also developed a broad idea of what the malware was doing in it’s initial stages. We now set out to investigate the reason behind the crash of the dropped file (“Adobe.exe”) and at the same time we want to retrieve the payload from this particular malware sample.

Analysis:

Let’s go ahead and debug the file. This file (“Adobe.exe”) was found to be packed (custom variant) and the unpacking routine is similar to the approach detailed in part II of this post, so let’s skip all the gory details and dive right into it.

After unpacking the entire binary in memory, control is transferred to a newly unpacked region at the address "0x401634". Now the action begins from here and we get our first decryption routine, which is a simple 1-byte XOR with a static key as seen in the image below which reveals more code

Figure 1: Decrypt code

If we carefully look at the new code below, we can observe that it is riddled with JMP instructions and occasionally we find a few garbage values. The code is crafted in such a way that it resists disassemble attempts which makes reverse engineering the sample more difficult and somewhat painful.

Hidden in between these JMP’s in plain sight is an instruction that is familiar to us by now(i.e the instruction to fetch the address of PEB (Process Environment Block)).

Figure 2: Fetch address of PEB

At this point we can only speculate on why the malware needs the PEB address. Moving further in the code, we encounter another decryption point that is exactly same as the first one, which decrypts more code. Now the control is transferred to the newly decrypted code.

Figure 3: NtGlobalFlag (anti-debug)

In the image above, we have an interesting bit of code. Recall that the malware already collected the address of PEB. At this point, using the instruction CMP DWORD PTR DS:[EDI+68], ECX (here EDI holds the address of PEB which is "0x7FFD4000" and ECX holds a constant 0x70 ) a comparison is performed, after which a JNZ instruction decides the fate of the control flow.

Here we get our first glimpse of the anti-debugging technique employed by this malware. The instruction CMP DWORD PTR DS:[EDI+68], ECX compares the value of the ECX register (i.e. 0x70) to the location in the PEB structure known as “NtGlobalFlag”. The field is set to a value of “0x70”, if the process is spawned under a debugger.

In our case, this is true since we are debugging the file. Finally, the JNZ instruction at "0x401511" is not taken, which lands us in an invalid region in memory, thus triggering the anti-debugging. Let’s jump here and continue with our analysis. We now have another layer of decryption, which reveals more code after which, as usual, control is transferred to this region.

We then reach another piece of code, which is revealed only if we keep up with the control flow.

Figure 4: File-path, name identification (anti-debug)

The above code uses “strstr” to look for a string named “sample” anywhere in file path of our currently debugged file. If found, “strstr” returns a pointer to first occurrence of search string(i.e "sample") in file-path, or else it returns zero. The malware then checks the return value in EAX and takes a conditional jump in the form of JE instruction at "0x401135". If the jump is not taken, the code lands in “ExitProcess”, a call which terminates the process.

This is the second anti-debugging technique the malware employs, although not-an effective one in my opinion considering the odds of a file-path or malware name containing the name “sample”.

Figure 5: GetVolumeinformation, Volumeserial (anti-debug)

Again, here we have another anti-debugging technique where the malware retrieves the Volumeserial number using the API GetVolumeinformation and compares it with  “0CD1A40” and “70144646”. If either comparison matches, the code jumps to the ExitProcess call.

Another anti-debugging technique follows immediately thereafter in the form of “EnumSystemLocalesA”. The first argument that "EnumSystemLocalesA" accepts is a pointer to the callback function. Here the malware does a neat trick. If we look at the code below, at address “0x401179” a constant “0x2” is pushed onto the stack, which is followed immediately by a CALL. 

When this CALL is executed, it pushes the return address onto the top of the stack (which is "0x401180") and the EIP (Instruction pointer) now lands at the "EnumSystemLocalesA" call. Now if we observe the stack, the value on top of the stack is the return address, which naturally becomes the callback function address for "EnumSystemLocalesA" . When the "EnumSystemLocalesA" API is executed, control falls to the callback function, which continues the execution of the code. 

Figure 6: EnumSystemLocalesA (anti-debug)

Let's now continue our debugging from the address “0x401180”. Not far from here, yet another anti- debugging technique is uncovered. This time the malware retrieves the ‘Diskname’ from the registry. 

Figure 7: Diskname (anti-debug)

"RegOpenKeyExA" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\Enum)  and  "RegQueryValueExA" then uses “strstr” and searches for signs of a virtual environment such as “Xen”, “Vmware”, “Qemu” and also looks for string “virtual”.

Figure 8: Search vm strings(anti-debug)

Once the malware detects a virtual environment, it changes the control flow and land us in an invalid memory region. If we play along, we can observe something interesting here.

Figure 9: Adobe.exe crash

There we go. We can finally reproduce the crash that happened during the first stage of our analysis.
Ok, so a through binary analysis is often not so straight forward after all !!!

Figure 10: sandbox identification(anti-debug)

Let’s move on and see what surprises the malware has this time. Below, we can see anotherpiece of code that checks for a DLL name called “sbiedll” . Here, the malware checks whether it is run in a popular sandbox called “sandboxie”. If found, as usual, the malware bails out.


Immediately afterward, the malware performs a decryption routine to reveal compressed data, which is again packed with aplib and below we can observe the aplib unpacking routine which decompresses the data to a PE file.

Figure 11: Aplib decompression routine

Soon after, control is passed to the newly decompressed file. Below, we can see the new file being executed.

Figure 12: New PE-file in memory

Debugging further, we can observe the malware revealing the final trick that it has up it’s sleeve ,which I will explain in the next post in this series.

The story of a Trojan Dropper I

Introduction:

Recently, Zscaler ThreatlabZ  received a suspicious file from one of our customers, which 

was named “OrderDetails.zip”. After extracting the executable file from the archive I have 
performed a virustotal scan  to get some information about the file. At that time, very 
few antivirus vendors had definitions in place, which flagged the file as malicious.

As such, I decided to take look at the file in greater detail. After completing the analysis,
I've  decided to blog about the threat. Given the amount of information derived during the analysis, I've decided to divide the blog into multiple parts.

Figure 1:  virus total results

Modern day malware generally implements some kind of packing or obfuscation on the binary, in order to evade antivirus detection. Hence, it’s a good idea to determine which packer may have been used while analyzing the file. In order to do this, I implemented a popular tool called PEiD to check for the existence of a known packer.

Figure 2:  PEiD results

As we can see above, PEiD was not able to pick up anything from this file, but that doesn't mean that the file is not packed. Let’s have a closer look at the file.

While going through the file sections, one of the sections (.data) contained an unusually large amount of data, which at first glance gave the impression that it is obfuscated. This is an important clue and something we have to keep in mind while debugging the file.

Figure 3:  obfuscated data

While looking at the resource section, we can see that the file icon resembles that of a PDF file, which adds to our suspicion. Also, the file is not digitally signed.

Figure 4: File icon at resource section

Lets go further and execute the file. When doing so, I was greeted with a crash report where Windows was telling me that “Adobe.exe” had crashed during execution.

Figure 5:  windows error report 

We knew from the beginning that this was not a proper PDF file and would not therefore work with Adobe Reader. Let’s now look to determine where Adobe.exe exists in the file system. A 
Windows file search reveals Adobe.exe inside the temp folder, which when executed, produces exactly the same result as was shown above 

Figure 6: dropped file named adobe.exe

At the same time, a Wireshark capture was not able to output anything that was of interest.At this point we have adequate evidence to proceed with additional debugging, which i will explain in detail in the 2nd part of this blog post. The story of a Trojan dropper II

Figure 7: wireshark packet capture

Fake AV vs. Zscaler

I've been monitoring Blackhat spam SEO for more than a year now. I frequently have to modify the scripts used to retrieve the fake AV pages in order to deal with obfuscation and other obstacles the perpetrators have put in place.

Fake AV pages are designed to keep security scanners and researchers away. One of the techniques used to weed out automated scanning tools from victims using real web browser is JavaScript redirection. I have seen more than ten different techniques to redirect users from the spam page to malware pages leveraging different types of JavaScript. Usually, they use two to four redirections, one after the other, each using different code.

JavaScript code of some of the redirections

Once again, by trying too hard to hide the malicious code, Fake AV pages are actually easier to detect by looking at the redirections rather the malicious code itself.

Strict HTTP Referer

In addition to making the JavaScript redirections difficult for security tools to follow, there are strict checks on the HTTP Referer header. For example, a real browser sends a Referer if the redirection is done through an HTTP Location header redirection, a meta redirection, etc., but no referer is sent through when using the JavaScript functions location.assign(new_value) or window.location=new_value. 

IP Blacklisting

It usually only requires a few minutes of work to bypass the "protections" put in place by Fake AV pages. The fake AV authors have no doubt realized that their modifications were not very effective, and that Zscaler and others are still finding their malicious content.

A few days after Mike found IP tables settings shared online to block major security vendors, our main IP address was blacklisted. I quickly changed to a different IP address in the same sub-net, but only 3 days later, our complete sub-net was blacklisted. I have recently switched to Tor to get random IP address. This has allowed me to keep tracking new Fake AV pages.

The cat and mouse game between Fake AV and the security researchers will probably keep going on for a long time. Since the attackers keep modifying their content, malicious HTML, JavaScript and executables, Zscaler has to keep monitoring the changes in order to protect their customers given this rapidly-evolving threat.

-- Julien

Which networks are more susceptible to Firesheep (aka session sniffing)?

Firesheep highlighted once more, the problem of session sniffing. Users on open wireless networks are especially at risk when they login to websites without SSL encryption. But not all wireless networks are the same when it comes to sniffing traffic...and wired LAN networks are not 100% safe either.

Firesheep found user sessions

Wireless networks

Firesheep was released to demonstrate the inherent weakness that session hijacking can present on wireless networks. They are several types of wireless networks, some are safe, but most are susceptible to session theft.

Open networks

Open wireless networks are becoming more and more popular. They can be found in public libraries, coffee shops, book stores, etc. Anybody can connect to these networks and no password is required. An attacker simply needs to be physically close enough to the wireless signal to steal unencrypted sessions.

WEP

WEP networks are protected by a password. These networks are often used in hotels to restrict Internet access to paying customers, but the password is the same for everybody. If the attacker knows the password, the network is as unsafe as an open wireless network.

It's generally very easy for an attacker to get the password without being a real customer (just ask another user for the password and you will likely get it). However, knowledge of the password is not necessarily required, as WEP encryption has been broken. There are tools freely available to crack the password.

WPA-PSK/WPA2-PSK

Unlike WEP, WPA negotiates a different key with each client to encrypt the traffic, but like WEP, WPA/WPA2 PreShared Key (PSK) encryption has been cracked as well. Somebody with enough security knowledge can determine the shared key, and sniff the HTTP sessions.

WPA-Enterprise/WPA2-Enterprise

These extensions built on the WPA/WPA2 protocols have not been cracked. Unfortunately, those are not often found or personal wireless equipments.

Wired networks

Wired networks are not necessarily safe. As with a wireless network, the type of technology used has an impact on the likelihood that traffic can be intercepted.

Hubs

If hubs rather than switch are used to connect computers, session sniffing is easy. Hubs send network traffic received on one interface to all other interfaces. This means that anybody connected to the same hub receives everyone else's traffic. Hubs are not used in many enterprises because of the security issues they represent, as well as their performance issues. However, they are cheaper that switches, and thus, can still be found in home or SMB networks.

Hub: traffic is replicated to all ports

Switch

Switches are more efficient than hubs: the network traffic is forwarded to one interface only. In theory, session sniffing is not possible on these devices. However, it is quite trivial flood a switch in order to make it behave like a hub. This flooding would probably be noticed in a company with a good IT department monitoring the internal network, but not necessarily in smaller companies.

Switch: traffic is forwarded to one interface

Monitor port

Most enterprise-grade network equipment (switches, routers, firewalls) has a monitor or mirror port: all traffic seen by the switch is mirrored to this interface. Anybody with physical access to this port can sniff traffic from the entire network. Unlike the case of flooding a switch to make it behave as a hub, this would not create any unusual network activity, and could not be detected.

Don't trust your network! Wired LANs are safer than wireless networks in general because they require physical access, but they are not 100% safe. To be sure that you're the only one accessing your accounts on the web, make sure you use SSL: use HTTPS only, or use an SSL VPN.

-- Julien

Spam SEO: Use of Java/Flash leads to more dangerous exploits

Most malicious sites behind spam Search Engine Optimization (SEO) poisoning attacks lead to fake antivirus pages. The malicious sites rely on social engineering, tricking users into thinking their computer is infected and require user interaction to execute and install the malicious file, which is disguised as an anti-virus program.

Well hidden exploits

Over the past 3 days, we've seen some even more dangerous websites using Java exploits and Flash vulnerabilities. These malicious pages do not require any user interaction to infect users. They are also very difficult to detect - the exploits are hidden behind several layers of Javascript redirects and use obfuscation. Also, the attackers allow each IP address to receive the malicious page one time only. After a user or a security tool accesses the malicious domain, any subsequent requests coming from the same IP address get redirected to different, harmless pages. This makes post-infection analysis, and the use of security tools almost useless. You have to make sure that you hit the right page, the right way (correct headers, referer header, form data, etc.) the first time or the exploit will not be revealed. Popular online security scanners like JSunpack or Wepawet cannot be used since all requests to the malicious sites are done from the same IP address.

Spam SEO Page leading to a Flash exploit

Java exploit

Mike reported a 300 percent increase of Java exploits last month. These new pages are very similar to what we saw before. A malicious JAR file is launched automatically through a Java ActiveX control vulnerability on Internet Explorer, or through the Java Quick Starter, which is installed silently on Firefox with a recent Java Plugin update. The malicious JAR files are not flagged by most antivirus vendors.

Like all spam SEO, the attack starts with legitimate sites being hacked. New pages are added to target popular search terms, in order to appear in the first few pages of a Google search. When a user clicks on spam SEO links, he actually gets redirected to a different URL such as hxxp://www.hutriken.com/nvu_y/hqpa_b_.php. This page checks to determine if the browser supports Java, and if so, sends the following form with automatically:

Detection of Java capabilities

The next page (the 4th HTTP request) contains both inline obfuscated Javascript, and an external script (obfuscated as well). Once deobfuscated, the exploit is very simple - it invokes the ActiveX control or the Java Quick Starter with the URL of the malicious JAR file.

Deobfuscated java exploit code

If the user, or the security tool, fails at any stage to have the appropriate prerequisites (lacking certain browser capabilities, multiple requests to same page, etc.), it gets redirected to http://google.com/.

Flash exploit

The flash exploit is not as well hidden as the Java exploit, and it is found on fewer links. It consists of a single page with obfuscated Javascript.

Obfuscated Flash exploit

The exploit uses a heap spray technique via ActionScript. We've posted an extended analysis of this type of exploit back in December. Like the Java exploit, no user interaction is needed for the exploit to run.

Deobfuscated exploit

-- Julien