HIPS vs "Man-in-the-Middle" (MitM) malware?

Can y´all perhaps check if the HIPS that you´re using, for example on Win XP/7/8, is monitoring for this stuff?

http://blog.phishlabs.com/new-man-in-the-middle-attacks-leveraging-rogue-dns

More info: https://www.wilderssecurity.com/thre...cks-leveraging-rogue-dns.361932/#post-2361963

 

Come on guys, work with me please.

It isn´t that hard to test your HIPS. I would like to know if your HIPS alerts you when you change your system DNS settings with a tool like DNS Angel: http://www.snapfiles.com/get/dnsangel.html

Secondly, I would also like to know if anyone knows how to protect against tampering with root certificates. Is protecting the registry enough, and how to test it? Some more info: http://superuser.com/questions/411909/where-is-the-certificate-folder-in-windows-7

 

The cert protection can't be achieve with EMET
http://blogs.technet.com/b/srd/archive/2013/05/08/emet-4-0-s-certificate-trust-feature.aspx

 

DNS Angel wants to edit registry keys:
HKLM\SYSTEM\ControlSet001\services\Tcpip\Parameters\Interfaces\*interface IDs*\NameServer

Not sure about the second one, the keys are only for IE though:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates\

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\

Kaspersky, Bitdefender and ESET need to install a Root CA in order for the browser to accept their certificate for HTTPS/SSL scanning.
You could test it with a HIPS which is compatible with one of them(don't know which one, but ESET is the most compatible with other products afaik), or with a tool that logs all changes they make.

 

Thanks to both of you for the feedback.

But based on the lack of reactions, I think that most HIPS are not monitoring this stuff. So the developers must have missed this attack vector.

 

Forgive my ignorance on this subject. Are those certificates just for Internet Explorer and other Microsoft products? I thought Mozilla browsers used their own and those are stored as files.

 

Yes, from what I´ve understood, other browsers use their own certificates, I haven´t got a clue of how to protect them.

 

For registry stored certificates, a classic HIPS that allows you to add individual keys to those it protects would work. I don't see any realistic way classic HIPS can prevent a browser from modifying certificates that are stored as a database in the browsers own directories. IMO, both of these are outside the scope of what most HIPS were designed to protect. HIPS aren't the best tool for this task.

A couple thoughts come to mind. Seems to me that the most effective way to protect both registry and database stored certificates would be to change the registry key and file permissions respectively. Make the registry keys and the certificate database unwritable. When you need to update them change the write permissions, update it, then remove the write permission again. These should work if you use the NTFS file system. With a FAT32 file system, you could use an integrity checker and add the database to its list of monitored files. It wouldn't be real time protection but would be better than none at all.

 

That´s quite an interesting idea.

 

Jetico blocks it on two types of alerts:

1. Control system services
2. indirect access to network

Actually, HIPS wouldn't be required to block DNS Angel, since it needs elevated rights to run. UAC alerts on that already.

 

Very cool that Jetico can actually block this. But it seems to be a bit too advanced for me.

Btw, like I said before, with a registry monitor (like in SSM) you can also block this stuff. I did had to add a rule myself though.

 

A simple way to defeat the changing of DNS settings would be with an outbound firewall. Allow DNS traffic only to the specific IPs of the DNS service that you use. If something changes the settings, the firewall blocks the traffic. If your firewall can be configured to alert to specific blocked outbound attempts, even better.

 

Yeah, I've spent lots of time modifying the rules, in particular utilizing IP address and Application groups, to make the rules processing more streamlined.

 

As much as I like and rely on classic HIPS, this thread is an example of what I consider a flawed approach to securing a PC. The original question boils down to "can HIPS defend against this type of attack?" The question should be "What is the best way to defeat this type of attack?", then choose the application, system tool, or configuration that's most able to mitigate it. Choose the tool to enforce the policy instead of making the policy fit the tool. In the above examples, the tool that most directly addresses the issue of changing settings or rewriting certificates is the systems own ability to enforce file and registry permissions. HIPS can serve a secondary role by restricting the utilities and system components needed to alter these permissions.

 

HIPS is only a part of what I rely on to secure a pc. Outbound firewall control (also Jetico) and built-in O/S measures are used as well for the Windows 7 machine. A similar philosophy is used in the Linux setups, except MAC (Apparmor) is used on them rather than classic HIPS.

 

Same here. The first layer should always be the configuration of the OS itself and the apps running on it. It was the title of the thread itself that brought it to mind. The tool (HIPS) was already chosen before it was determined if it was within the tools ability to mitigate such an attack. For my own system, most of the problem is moot. I have no software that uses the registry stored certificates. It was never installed or was removed immediately afterwards (98Lite and XPLite). The registry key doesn't exist. If something changes or tries to use a different IP for DNS than those I've chosen, Kerio will block the traffic and warn me. If something manages to defeat SSM's registry key protection, they'll be restored when I reboot. The browsers that I do use never see any certificates save those of Proxomitron. It handles those duties. Unlike the browsers, Proxomitron can't modify its own certificate store. It can accept new certificates on a per-session basis only. Modifying the certificate store has to be done with OpenSSL.

I have no trust in the entire certificate system. IMO, it's broken by design and is only slightly better than nothing at all against any adversary beyond a script kiddie. I'll trust self signed certificates like those used here more than those using certificate authorities. IMO, the certificate authorities are little more than a deliberate flaw, easily bought or coerced.

 

Yes, I wouldn´t know much about that, but then again, I don´t have to use all the advanced settings. Perhaps I will give Jetico a try, I kinda like the clear GUI. I'm still looking for a replacement for ZoneAlarm (noob firewall ), they totally ruined the GUI. I didn´t like the firewall in SpyShelter.

 

If I recall, there's a couple of large thread for Jetico here that were very comprehensive. I've never tried it but I've heard it's good if a bit complicated. No idea what Zone Alarm is like now. It's been at least 10 years since I've looked at it.

 

Firefox certs are saved inside the profile folder, cert8.db
Changing file permissions sounds interesting, but wouldn't that block updating of blacklisted certs/CA's? If those blacklist updates are included in program updates, you can disable it before updating, but what if it's not?

 

I know what you mean, but I´m looking at it from a different point of view. I have always been fascinated by HIPS, and I always keep thinking about which areas they should be monitoring. IMO, it´s the job of the HIPS developer to monitor what kind of attack vectors are being used by malware, I just hate it when they miss things.

Check out this old thread:

https://www.wilderssecurity.com/threads/hips-and-behavior-monitoring.197356/

 

I have a Jetico "Application Group" tied into a rule that monitors several user-writable and executable directories for all the Process Attack parameters:

Code:

<group name="Directories requiring surveillance" comment="">
            <item value="C:\Users\*" />
            <item value="C:\NST" />
            <item value="C:\ProgramData\*" />
            <item value="C:\Windows\Tracing" />
            <item value="C:\Windows\debug\WIA\*" />
            <item value="C:\Windows\debug\WIA" />
            <item value="C:\Windows\Tracing\*" />
            <item value="C:\NST\*" />
            <item value="C:\Windows\Temp\*" />
            <item value="C:\Windows\Temp" />
            <item value="C:\Windows\Registration\CRMLog" />
            <item value="C:\Windows\Sys*\FxsTmp" />
            <item value="C:\Windows\Sys*\Tasks\Microsoft\Windows\SyncCenter" />
            <item value="C:\Windows\PCHEALTH\ERRORREP\*" />
            <item value="C:\Windows\Sys*\Tasks\Microsoft\Windows\PLA\System" />
        </group>

I believe these are at least some of the areas malware writers are commonly targeting.

 

It's not physically possible for any single security application to address every attack vector. What you're describing is a combined security suite. There's lots of these combined security suites available. IMO, combined suites that try to do everything seldom do anything very well. These do it all suites are heavy, demanding on the system, require constant updating, and are often quite invasive. Example, should a HIPS be capable of filtering malicious javascript? How about blocking/removing spam? Where do you draw the lines? HIPS were originally designed to stand on their own, to eliminate the reliance on the huge databases of blacklists (or whitelists), the constant need for updating which adds the vendors servers and the internet itself as additional attack surface. Making them into combined suites reintroduces the same problems they were intended to fix and introduces other potential problems. There's been several discussions here that weigh the pros and cons of combined suites vs separate, layered components. Which is better depends on the users needs, abilities, and how they evaluate the cost/benefits of each. Performance issues aside, I'll choose separate, free standing security apps. Separate, they're better able to protect each other. Combined, they can work together but can also share common vulnerabilities.

 

I think you misunderstood me, because I actually agree with you, I hate bloated all in one products. However, it´s the job of HIPS to monitor all (or the most dangerous) suspicious behavior that´s used by malware in real life.

But there must be a balance between security and usability. For example, if you look at Comodo, it´s a true all in one HIPS, and they tried to cover just about anything, but it´s way too agressive and not fine tuned. That´s why I don´t really like it, it´s a bit too annoying. On Win XP I´m still using SSM and Neoava Guard, the only problem is, they missed out on a couple of things.

http://www.matousec.com/info/articles/features-of-modern-security-suites-part-2.php

 

This is what I like to see in HIPS (part 1):

Anti Exe:

All apps not on the whitelist can´t run. Of course stuff like rundll32.exe (which could be used in attacks) can never run automaticly and all essential Windows processes should be whitelisted. To make things easy, all apps from C:\Program Files should be able to run.

Anti Exploit:

All apps vulnerable to zero day attacks should be protected against in-memory attacks (buffer overflow + Anti-ROP). This means that no malicious code will be ever executed, and apps under attack will be automaticly terminated.

Behavior Blocker:

Monitor all processes for suspicious behavior. To reduce alerts, you can auto allow signed apps (not recommended). You can also mark apps either "Trusted" or "Restricted". Restricted apps will in fact run in a policy based sandbox, with lower rights/priviliges.

Sandbox:

Restrict not fully trusted apps in a policy based sandbox with virtualization, so that you´re system won´t get messed up. File system + registry + inter process communications (IPC) will be virtualized. You will normally not get to see any alerts, unless you want to (Behavior Analyzer).

 

This is what I like to see in HIPS (part 2):

Data protection:

Protect certain folders, so that important files can´t be damaged or hijacked. Only certain apps are allowed to write, delete (and read) your files. This should be able to stop ransomware.

Firewall:

Protection against inbound and outbound traffic. Including protection against ways to evade the firewall, also known as anti-leak.

Anti Rootkit:

Protection against kernel-based rootkits, who try to hide from anti-malware tools, by modifying the OS kernel. True protection can only be achieved by making use of a hypervisor (with the help of Intel VT). The hypervisor will make HIPS run in a more priviliged mode than rootkits and other malware.