Chrome Playing Hard to Get with Blackhole Exploit Kit

Chrome Playing Hard to Get with Blackhole Exploit Kit:

http://threatpost.com/en_us/blogs/chrome-playing-hard-get-blackhole-exploit-kit-120612

 

Is anyone surprised? Chrome probably still is the hardest browser to exploit after all.

 

Firefox with the NoScript plugin will stop this cold.

 

How exactly do these exploit infections work? Is it basically:

1. Bad guy buys exploit kit.
2. Bad guy uses SQL injection to load malicious exploit and URL into a legit site.
3. User with out-of-date Java, Flash, whatever goes to site. Exploit loads malware onto their computer.
4. Malware installs, delivers fake AV or ransomeware.
5. Duped users pay money, bad guy makes money.

 

Brandonn2010, That seems to be the way it works, as I've understood the analyses.

In many years of trying, I've never found a site with an actual redirect, so I've been limited to seeing how the Blackhole Kit works on the malicious page itself.

I've noticed that a plugin exploit has to pass through three layers of user configurations to work.

1) Javascript and plugins must be enabled. If not, the user sees a screen that does nothing, such as:



Also, some browsers have an "on demand" configuration for plugins. Opera here:



2) The firewall must permit the Java application to connect out:



3) There must be nothing in place to prevent the trojan from automatically downloading/installing:





----
rich

 

Even with all the evidence you've produced in this forum over the years, it astonishes me there are still so many who think outbound firewall control is useless

 

How would the average person know if Java is supposed to connect to the Internet though? Even if they had an outbound FW, they would probably just allow all.


Also, how is it so easy for websites to be hit with an SQL injection?

 

Security is a big problem for the "average" users. That's probably why so many security articles recommend that users just remove Java.

My understanding is that it is very easy, since there are automated programs that probe sites looking for lax user input validation points that let the hacker inject code via one of these points. One such tool brags,

See also:

SQL Injection
http://hakipedia.com/index.php/SQL_Injection

So, it's a web administrator problem, in many cases.

See:

SQL Injection Attacks by Example
http://www.unixwiz.net/techtips/sql-injection.html

----
rich

 

Well, in this case one without per-application rules (like iptables!) would be useless, because the Java applet just uses port 80 outbound - which you need if you want to surf the web.

In fact I kind of wonder how far a Linux version of this could get, if Linux users were a larger percentage of the market. Most distros come with:
- Javascript and plugins fully enabled in the browser
- No outbound firewall, or per application rules
- No serious MAC system
- User-writeable areas mounted with exec permissions

IOW no better than your typical Windows install, give or take a better update system and no AV. Rooting the system is probably harder, but malware does not need root access.

 

Agreed, iptables and any firewall that can only restrict ports, protocol, ip address, direction but not specific applications will not provide the same security benefits as those that can restrict applications. However, there are cases where malware utilizes the less conventional ports like 82, 8080, for example, and this is where restricting outbound TCP ports will help to at least to some degree mitigate threats.

Maybe, maybe not. At least the average person has the opportunity to deny the attempt, which they might do so if the attempt is unexpected and they endeavor to allow it only to sites they know and can trust. 3rd party firewalls do a lot to help the user in the decision making process by providing informative alerts when something does attempt to connect out for the first time. Besides, there is more to that example from Rmus than just stopping Java; you can see the final step where the exploit attempts to download then install the malicious .exe payload, which his anti-executable application stops in its tracks. The firewall is but one layer in the overall security model.

 

Even per application Firewalls are useless without HIPS. That's why so many Firewalls come with a HIPS component to restrict applications from each other - because almost all applications run as a single user and therefor can interact significantly with one another.

A default Ubuntu install is no more secure than a default Windows install. With Windows 8 it's arguably less secure, but there are so many variables it's not really possible to say.

 

I have outbound Java connection allowed by my firewall. I need this for a legitimate software.

 

Just found this a few minutes ago:

https://www.wilderssecurity.com/showpost.php?p=1463939&postcount=1

It's a few years ago, but it's a great read, highly informative and relevant even with today's exploit landscape.

 

Exactly. That is a huge problem with Java and process specific rules in a firewall. If you have any application on your system that uses java and uses the internet, you tell your filewall to allow java. But then any other java code can use it too.

With every program written in java showing up as the process java.exe, it is very hard to use the process name to decide what an app should and shouldn't be allowed to do.

 

In my case I just limit the required Java processes to only the selected remote addresses and ports I require them to connect to:

Code:

<rule type="7" action="accept" name="Java processes allowed to selected ip address to ports 80 &amp; 443">
                <event value="0x2" />
                <application value="C:\Program Files (x86)\Java\jre7\bin\java.exe" />
                <application value="C:\Program Files\Java\jre7\bin\java.exe" />
                <application value="C:\Program Files (x86)\Java\jre7\bin\javaw.exe" />
                <protocol value="0x00000002" />
                <remote_addr value="65.181.175.181" />
                <remote_addr value="128.255.33.28" />
                <remote_addr value="192.168.1.68" />
                <remote_addr value="75.98.163.66" />
                <remote_addr value="137.254.16.66" />
                <remote_addr value="23.5.112.60" />
                <remote_addr value="137.254.16.78" />
                <remote_port value="80" />
                <remote_port value="443" />
            </rule>

 

Assuming the application connects to a specific site and doesn't need free access to the internet, wat0114's solution protects, since the firewall whitelists specific IP addresses you designate. The firewall will alert at any attempt to connect to an address not whitelisted:




----
rich

 

Oh, don't get me wrong, I totally agree that this approach works. However, it is a little on the advanced side.

Lets say I download a java application that I trust. I run it and my firewall pops up saying java wants internet access, allow or deny. Making that decision is straight forward and easy for most applications. But to use this approach I would almost have to reverse engineer the application. If you know all the IP addresses and ports the app uses then its easy. If not, it can take some trial and error to get the correct configuration.

But the problem with java apps, is if you do happen to have just one java application whose connections can not be predicted, you have to allow the whole java.exe app, so now any program written in java has full access through the firewall.

 

The problem with that type of solution is that you could never deploy it to regular users, they wouldn't put up with it.

 

I will defer to you on this because I've not used an application that requires Java.

Is such an application any different from any that asks for internet access? The IPs are coded into the application and are revealed by the firewall when a connection is attempted.

Here, one of my photo editing programs which wants connect out to the developer's site. When I first used the program, the firewall alerted:



It was just a matter of customizing a rule for that application and putting the IP address into the firewall Whitelist.


----
rich

 

I've got to agree. This and many of the solutions discussed at length here are just not going to be acceptable to the general public who far outnumber the types found here. If you leave a decision to a user, something is going to screw up. If you don't leave any decision to a user, inevitably they're going to raise holy hell. There's no easy answer to security in my own opinion. Move the needle too far to the right, bad things happen. Move it too far to the left, people get upset and can't do a lot of what they want to do. We sometimes shake our heads at stories or get a laugh, but quite frankly if we're not their authority figure or the purchaser of their systems, we have no right to tell them how to use their computers or where they can and can't go. I think it needs to be faced that the masses are simply content and feel more comfortable living their lives with AV software and other "useless" means of security. They don't necessarily care a huge amount, and we can't make them.

 

Discussion of solutions shouldn't have to depend on whom a solution is going to be acceptable to.

You can apply that reasoning to many situations in life!

In my area, "healthy foods" (fresh vegetables and fruits, etc.) is a big topic. Many dismiss such discussions as useless because "the masses are simply content" to partake in fast foods and frozen dinners.

So be it, and each to her/his own.


----
rich

 

I don't at all recall dismissing the discussions as useless or saying that discussions shouldn't happen unless it fits a certain criteria. All I recall saying is that solutions that are complicated, restrictive and annoying, are going to dismissed as unacceptable to the content masses.

 

BTW: As I found out with my recent issue with the Blackhole Exploit kit, which was placed on a website which was formerly a safe to visit homepage of a small innovative robot company which was in the news (and the website got hacked).

You CAN'T trust the VirusTotal check of URLs.

Really the only tools that help to discover the Blackhole Exploit Kit are the following tools, which do a live scan of the requested URL:

• urlQuery - http://urlquery.net
• Zscaler Zulu URL Risk Analyzer - http://zulu.zscaler.com
• Sucuri SiteCheck - http://sitecheck.sucuri.net/scanner/
• SecureBrain, Check with Gred - http://check.gred.jp/
• Comodo Site Inspector - http://siteinspector.comodo.com
• Quttera Web Investigation System - http://quttera.com/
• Wepawet - http://wepawet.iseclab.org/
• Anubis - http://anubis.iseclab.org/
• Avira - https://analysis.avira.com/

All of the other URL scanner tools, like "NoVirusThanks URLvoid" found nothing. If you are interested in which tools found nothing, I can create a list, too.

As said, You CAN'T trust the VirusTotal check of URLs.

- The first time I tested the website 0 (yes, none) of the malware scanners of VirusTotal found anything
- Just only after I manually tested the website myself! with Comodo Site Inspector and Wepawet (which are part of the VirusTotal scanners), hours later they started to report sth. on VirusTotal
- But 3 days ago still only 1 of 32 scanners reported the site as malicious
- Today I had to tell VirusTotal to do a rescan, just now 2 of 32 scanners reported the site as malicious
- Even days after I manually tested the site with URLQuery and Sucuri SiteCheck, these test results don't show up / are not updated on VirusTotal (URLQuery is still shown as untested and Sucuri SiteCheck is still shown as safe, which is both not the case, both manually tested reported the site as malicious)

https://www.virustotal.com/url/224e...11e60be62ed98fe18b4fbe0f/analysis/1355830076/

To recap: First time I used VirusTotal, it found nothing. Second time I used VirusTotal, only one scanner had detected the Blackhole Exploit. Third time I used VirusTotal, only two scanners had detected the Blackhole Exploit, and to get that info I had to do a optional rescan.

And even the Google Safe Browsing tool did not help. Only AFTER I manually tested the website on 2012-12-15, it started to report this website as malicious. The first time I checked the website with the Google Safe Browsing tool it found nothing (aka it didn't live scan it for me).

http://www.google.com/safebrowsing/diagnostic?site=http://wall-ye.com/


P.S. Here are the malware results of this particular website which hosts the Blackhole Exploit Kit:

http://urlquery.net/report.php?id=411311
http://zulu.zscaler.com/submission/show/0a39cf9e8e76d49ee0c52b4a22c9a52a-1355526614
http://siteinspector.comodo.com/public/reports/show_log?id=7874972&type=malicious
http://anubis.iseclab.org/?action=result&task_id=1a89977b6cc1eb744f50c6d8e4d4a6e1c&format=html

 

OK - understood!


----
rich

 

Ok, so lets say I am a software vendor, and I write my programs in java. The binary that I distribute to a user of my program would be a *.jar file. For a user to actually run it, they use the java.exe virtual machine to load the jar file and execute it.

So Internet Explorer is not written in java, and is distributed as iexplore.exe. When a user starts it up, their firewall will say iexplore.exe wants to connect to some address. Adding firewall rules for each IP address in this case would not work because the IP addresses can not be predicted. So in this case, the only option is to say iexplore.exe can access any IP it wants.

But, if Internet Explorer was written in java, it would be distributed as iexplore.jar. When a user would start it up, the firewall would say java.exe wants to connect. IP addresses still can not be predicted, so you would have to say java.exe has full IP access. But, now any application written in java would have full access.

This is a contrived example, but it shows how firewall rules for all the java apps on your system keep adding on to each other.