Pages

Monday, December 30, 2013

Effective blocking of Java exploits in enterprise environments

Preface

"Java every day" was a joke about Java vulnerabilities, where almost every day, a new Java zero-day was seen. Recently, the "Java 0-day spotted in the wild" is no longer in the headlines every week (see http://java-0day.com), but Java exploits are still the most significant concern regarding exploit kits and drive-by-download malware. In a recent Kaspersky report, they found that about 90% of the exploit kits were trying to infect the victim machine via Java.

The "typical useless" recommendations

Okay, so we have a problem called Java in the browser, let's look for a solution!

The two most straightforward "solutions" of all are:
  1. Update your Java.
  2. Remove Java from your browser.

Both solutions are non-solutions for enterprises. Still, a hell a lot of in-house-built applications need old Java - e.g., 1.6.x, which is end-of-life since February 2013.

The next recommended "solution" is: "Create separate browsers for Internet and intranet usage. The intranet facing browser supports Java, the Internet-facing does not."
Although this sounds pretty effective, there are still a lot of problems with this approach. Now IT has to update two browsers instead of one. Users have to be trained, and in a web-security gateway (web proxy), one has to configure that this browser can go there, but the other can't, etc. And still, there might be Java applet based applications outside of the organization which has to be used by a bunch of people.

Next solution: "Use NoScript".
LOL. Teach NoScript to 50000 users, and see how they will learn the "Allow all this page" first, and "Allow scripts globally" the next time.

Next solution: "Click-to-play"
I think this is a good countermeasure, but from now on, the exploit maker either need an exploit to bypass the click-to-play, or to socially engineer the user to click, so this is not a bulletproof solution either.

The solution

Okay, so far, we have five totally useless recommendations. The next one seems pretty good at first sight: "White-list websites which need Java, and only allow Java to these sites."
Let's dig deeper. How can we "white-list" sites? This is not supported by Java out-of-the-box. In a decent web-security gateway, one can create white-lists, but we have to define a condition for Java traffic. A common misconception is to say: let's identify Java traffic for .class, .jar, and .jnlp file extensions, and only allow Java for white-listed websites. Although this will block some exploits, but not all.

Here is a screenshot from the trendy Neutrino exploit kit:


This is the .jar exploit. As you can see, there is no extension at all in the HTTP request (e.g., .jar). But what about the Mime-type in the response? It is video/QuickTime… But it is the jar exploit, with detection of 2/49 on Virustotal. And, yes, I'm aware of the fact that Virustotal statistics are useless, and AV has other possibilities in the exploit chain to block the malware being dropped. Or not :)

Two things can be flagged here as Java: the User-agent and the Mime-type in the request. I recommend checking for both. The User-agent can be reviewed via regular expressions, and if one matches, flag it as Java request.

Payload delivery

Although not closely related to the exploit, but the malware payload delivery is exciting as well. After successful exploitation, the exploit payload downloads the malware from the same site. In a standard web-security gateway, executables can be flagged and blocked for average users. Now look at the Neutrino exploit kit:


No executable extension (e.g., .exe, .dll), the response Mime-type is faked to audio/MPEG, and even the malware is XOR encrypted with a 4 character key (I let the exercise to the reader to guess the XOR key). Also if the web-security gateway looks for file headers to identify executables, it won't find it. The malware is decrypted only on the victim, where the AV might or might not find it. Although the User-agent here is Java again, be aware of the fact that at this stage, the User-agent can be faked by the exploit.

Update 2013.01.02: I forgot to mention the case of SSL interception. Although in an enterprise environment, it is a good idea to intercept SSL traffic (except on finance, webmail, healthcare, etc. sites) to hunt for malware (and block Java), if you don't do this, it is not a problem. There is again a misconception that the User-agent of the client browser is not visible in an SSL connection on the proxy (web security gateway). Below is a screenshot to disprove this statement. In case of a transparent proxy, yes, there might be no user-agent.


Mobile devices

If we white-list sites on the web-security gateway and block any other traffic when we see Java-based User-agent or content-type, we are right. Well, almost. As long as the client is in the enterprise… What you can do here is to enforce the mobile devices the use of VPN every time it is outside of the corporate network, and only connect it to the Internet through the corporate web-security gateway. I know this is still not a solution, but I can't think anything better at the moment. Leave a comment if you have a solution for this.

Now the only Java threat is that someone hacks one of the white-listed websites in a watering hole attack, and serves the java exploit from the same page. Not a likely attack, but possible for a real advanced threat.

Conclusion

If you are a CISO (or has the same position), you should proactively block Java exploits. White-listing websites which require Java is not impossible. Not a lot of sites use Java applets nowadays anyways. I would say average users see Java applets more in an exploit than in a legit site...

You can flag Java traffic via User-agent regular expression, or content-type (in the request), or both. Special care needs to be taken on mobile devices, which leave the enterprise on a regular basis. Of course, you will need other protections too, because this is not a 100% solution.

And if you are a plain home user, you can safely delete Java from your browser, or use a decent Internet Security Suite which can effectively block Java exploits.

Tuesday, December 10, 2013

DNSSEC, from an end-user perspective, part 1

We all know since at least 1990 that the DNS protocol is insecure. Yet DNS is still the basis of almost all Internet communication. The biggest problem with DNS is that a malicious attacker can redirect victims, where victims try to connect to, e.g. safesite.com, but instead of this, they relate to the attacker's website. There are a lot of different ways to achieve this attack.

DNS cache poisoning the DNS server, "Da Old way."

The attacker forces the victim's DNS server to resolve a domain where the attacker is the authoritative name server, and the attacker sends additional information to the DNS server that he is also the authoritative name server for safesite.com. This information is cached and used later when the victim resolves safesite.com.

It is easy to protect against this attack, any decent DNS server should be able to protect against this attack by dropping this additional information from DNS responses.

DNS cache poisoning, "Da Kaminsky way"

An attacker can initiate queries to the victim's DNS server, and in the meantime, "flood" the DNS server with fake responses. The server will accept the fake response if the following conditions are right: 
  • the DNS server receives the answers on the same IP as it expects (this is not an attack limitation), 
  • the DNS server receives the answer to his question (again not a limitation, an attacker knows what he wants to attack),
  • the random(?) port used to send the query matches the answer, 
  • the random(?) 16-bit(!) unique transaction number in the answer matches with the query.
If the last two are not random, an attacker can easily poison the server in a matter of seconds. Or if your DNS server is behind NAT, the NAT can remove the randomness :-O
To protect yourself against this, you should randomize the source port and unique identifier better, and disable your DNS server as being an open recursive resolver.

Rogue DNS server via malware

This is pretty common in both banking trojans, adware, etc. The malware reconfigures the users configured DNS server to use a malicious one, either in the local OS settings or in the home router.

To protect against this: don't let malware in your environment ;)

ISP hijack, for advertisement or spying purposes

This is the worst of all. ISP's hijack non-existing domains, and display advertisements. And because they broke the RFC, it will break a lot of your applications. I bet ISPs still think about this as a good idea :(

Sometimes the ISP hijacks your connection because the government wants to spy on your communication or divert it. Use TOR wisely if you don't want to be a victim.

Captive portals

Sometimes captive portals use DNS hijacking to redirect the users to the default login page. Although it breaks things, it is still better than the ISP solution, because it is only a problem at the beginning of the connection, and not permanently.

Pentester hijacks DNS to test application via active man-in-the-middle

Although this is not malicious at all (developers might think otherwise), but a lot of application security tests (thick clients, mobile applications) can only be carried out via DNS spoofing. Application security testers can easily make this attack because they can place the host machine in a network segment where they can make an active man-in-the-middle attack and respond to DNS queries sooner as the official DNS server. Or simply set the DNS server to their own DNS server.

Malicious attacker hijacks DNS via active MITM

This is similar to the previous one, but the goal is different. Although an attacker with active man-in-the-middle position can attack the victim in 1000 different ways (like SMB relaying, capturing LM/NTLM network hashes, modifying clear-text traffics, etc...), DNS spoofing is one of them.

Having access to the DNS admin panel and rewriting the IP

I believe this is going to be a new trend. This attack is the most effective one, and the hardest to prevent. Usually, it is not the admin panel that is being hacked, instead an admin's password gets stolen, or the password reset is hacked.

You, as a client, can do three things to protect against this attack:
  1. Choose a decent provider and prey :)
  2. Put a registry lock on your DNS settings (serverDeleteProhibited, serverTransferProhibited, and serverUpdateProhibited). Although this additional layer is good enough today, I bet some motivated attackers will be able to successfully attack this. The attacker only has to:
    • know the phone number of the client, which will be called by the registrar
    • hijack the call (social engineering the phone company)
    • provide an individual security phrase (social engineering the client)
  3. Or run your own DNS server (this is not a solution for everybody)

Conclusion 

Although almost all attacks can be mitigated one way or another, there was a desperate need to solve this DNS spoofing issue once and for all. And so it begins, DNSSEC has been developed.

In part 2, we are going to investigate DNSSEC, what you can expect from it, and what you can't.

Friday, November 29, 2013

Secure IPv6 deployment checklist: think twice, deploy once

Before deep-diving into IPv6, I'm going to summarize my views on IPv6:
  1. Start now(!) to plan your IPv6 deployment - in case you have not done so.
  2. IPv6 is the future! There is no other choice.
  3. NAT is the root of all evil.
IPv6 is coming. We've heard this 10 years ago as well, but it is really coming now. If you live in Asia, you can see this in real life. If you live in Europe or the USA, you can feel the pain of triple NATed devices.

Deploying IPv6 is not a binary task, you can do it in small steps. Get a public IPv6 address space, assign IPv6 addresses to your servers (e-mail, web, DNS).

Great, you are now ahead of the world!

Now, what about clients who want to access IPv6 web or email? You are lucky if you use an IPv6 compatible web/email proxy because the clients can still stay on IPv4.

Now, what about your clients/servers accessing IPv6 services on the Internet directly (without a proxy)?
  • If your network supports IPv6, your clients can directly access IPv6 services. 
  • If your network does not support IPv6, clients can still use tunneling protocols, e.g. ISATAP for Windows clients.
This might sound easier than it is. But do you have the budget/people/management support to do this?

Anyways, before you deploy IPv6 in your corporate environment, you have to think about the security issues. The next list is far from comprehensive or complete. Beware, here be dragons!

It is a myth that IPv6 is more secure than IPv4. The only practical security addition in IPv6 is called IPSEC, and has been backported to IPv4 many years ago.

Most networking people are not familiar with the new terms, best practices introduced with IPv6. It is important to educate the networking and security personnel about IPv6, and let them play with the technology.
IPv6 can reintroduce basically all security vulnerabilities which has been mitigated in IPv4:
  • If the vulnerability is not in the IP layer, the vulnerability will stay there. Although it sounds obvious, most people tend to forget this. Your MS08-067 vulnerability won't magically disappear if you use IPv6. OK, but you closed port 445 on the firewall. Oh crap, it is open on IPv6...
  • Man-in-the-middle attacks: Organizations have already guarded themselves against ARP spoofing and DHCP server spoofing with mitigation techniques like DAI (Dynamic ARP Inspection) and DHCP snooping in the world of IPv4. The only thing which has been changed is the name of the attacks and defenses. Search for ICMPv6 attacks, and Neighbour Discovery attacks.
  • Source routing: Source routed IPv4 packets have not been seen for a while bypassing firewalls, but "luckily" the IPv6 standard reintroduced source routing in IPv6, in the name of Type 0 Router Headers. You should check whether your OS/network equipment support Type 0 Router Headers. If you have time, play with Scapy to test it.
  • Blocking ICMP: Let's face the truth: In order to effectively use IPv6, some ICMPv6 messages has to traverse through firewalls. Like it or not, you can't hide your clients anymore.
  • Router advertisement: Let's play a game. Go into any network, and start broadcasting IPv6 router advertisement packets in the network. Guess what, the clients are going to connect to you, and you will be the default IPv6 gateway for the clients. If there is no web proxy configured on the client, this means all Google, Youtube and Facebook traffic will be routed through your box, because IPv6 is preferred over IPv4. This can be the next generation WPAD attack :) If you don't want to be vulnerable, better search for RAGuard or similar solutions.
  • Translation/tunneling: If all your network equipment support IPv6 and configured to use it, you are lucky, because your clients can use native IPv6. Otherwise, your clients have to use 6to4/ISATAP/Teredo/NAT64 or whatever IPv6 translation/tunneling. Do you know these protocols? Do your security products know these protocols?
  • Dual stack: Your clients have to use both IPv4 and IPv6 together for a while. Be aware of the additional operating costs of maintaining 2 network protocol parallel.
  • Fragmentation: In the first era of IDS/IPS devices, one of the main bypassing technique was IPv4 fragmentation. Have you checked whether your current solutions (IPS/IDS) parse fragmented packets the same way as your protected assets?
  • The IPv4 implementations have been tested thoroughly, and not much implementation bug is left there. But IPv6 implementation bugs, there will be a lot from them. Most of the programmers still don't know the basics of secure coding practices.
  • IPv6 evercookie: Now that your clients don't have the same NAT IP, they static IP can be used to track them online. Luckily Microsoft solved the issue with IPv6 privacy extension, so clients will use temporarily IPv6 addresses to communicate with the Internet. Great, now how do you know in your security logs, which IPv6 address is which client???
Do your current security devices fully support IPv6? Have you tested this?
  • Hardware Firewall (with all dual-stack/translation/tunneling nightmare)
    • Do you block all outgoing UDP from the clients, especially 3544?
    • Can you maintain rules for both IPv4 and IPv6?
    • If you remove an IPv4 rule, do you remove the same rule for IPv6?
  • Log collection, log analysis, correlation:
    • Do the logs contain IPv6 addresses? 
    • Is it parsed by the SIEM application? 
    • Do you know that the DHCP IPv4 address is the same asset (workstation) as the IPv6 address with a privacy extension? 
  • IPS, IDS:
    • Can these applications monitor/block all kinds of IPv6 translation/tunneling protocols?
  • WAF:
    • Is your WAF IPv6 ready/aware?
    • What about fragmentation?
  • VPN:
    • Can your clients connect to IPv6 services through VPN?
    • Is your IPv6 VPN firewall rule as restrictive as the IPv4 one?
    • If you remove a rule on IPv4, do you remove the same in IPv6?
  • Software firewall:
    • Is your software firewall IPv6 ready/aware? 
    • Does it understand all translation/tunneling protocols? 
    • Does it filter incoming traffic to the Teredo interface?
  • AV/endpoint protection:
    • Is your AV/endpoint protection IPv6 ready/aware?
    • What about files downloaded via IPv6, is it scanned the same way as IPv4?
  • DLP (if you are in the 1% who actually bought one and enrolled it in production):
    • Is your DLP IPv6 ready/aware? 
    • Can it monitor tunneled traffics?
And last but not least, the bad news: you are already using IPv6 if you have Windows7 notebooks leaving your company, not having access to the domain controller. Or have you checked your servers link-local IPv6 addresses recently? Do you have a Windows2008 cluster? It is using IPv6 already!

The good news? In the not so far future (I estimate 2050) you can turn off your last device with IPv4 address, and forget all the nightmare around NAT and dual-stack. Because remember: NAT is not a security feature. It never was.