I do not know whether the Wilders forum policy allows me to post links to free online exploit development courses... But in general you want to learn more about ROP and read quite a number of papers discussing previous EMET bypasses.
I still haven't bothered with any anti-exploit stuff... can't place enough trust in the companies listed in the initial post. I doubt I will install them either. There are worse things out there than browser exploits. Gotta' love how these companies just pump out apps that "do this" or "do that"... the supply seems to be outweighing the demand... and then they say "oh, ours is different because it does it this way"... *gives himself a backhander* sucked in much...
Just to name a few... 1) USB stick sharing conducted between people lacking security knowledge 2) Windows users who believe Windows Defender and Windows Security Essentials is enough 3) Java 4) Using the Internet without a VPN because *cough* I have nothing of interest, so who cares who is watching *cough* 5) The New Wave of Modern CDNs - MS Azure, Amazon Web Services, and the Google one 6) .... ...and then the browser is loaded...
1. autorun has been disabled for many years now 2. That is the case with every AV suite 3. The last vulnerabilities in the java plugin that has been actively exploited in the wild dates back 2 years. 4. Isn't that big of an issue unless you use an open wifi spot. 5. Please explain that one...
1 - Not it hasn't. It is a KB patch pushed out via Windows Update. Those who wish to control their AutoRun settings can do so by not applying the patch. Some prefer to handle things on their own, rather than having terms and conditions dictated to them. 2 - I doubt they "believe" it's the best. If they did, they would be fanboys/girls, sticking flyers under windscreen wipers during weekend sports games. It's more of a "what works for my setup" situation. Some/most of the time, users push themselves into a corner because they want layers and compatibility/communication between all tiers. The criteria list increases to the point where their setup is the only setup for them. 3 - I take it you believe everything you read... what's next? JRE's are safe as well? Rebuilding ColdFusion software packages on a Java foundation was a great idea too, huh... 4 - It's still an issue. 5 - Not yet, still gathering info...
I'm acquainted with how exploits work. I would no more run Anti-exploit software than I would build an anti-meteorite bunker "for protection" [against the highly, highly, highly unlikely]. I am also acquainted with how marketing works. First, "vulnerability" does not equate to "exploit" or "attack". The front door to my house is vulnerable to getting busted down but that doesn't mean thieves are breaking in. Next, "proven vulnerability" does not equate to "proven protection"; the only proven protection is an update to the software that specifically eliminates that vulnerability. Finally, I have a proper security configuration (to include an OS newer than 14 years old, for which these AE kits are primarily for) and am a reasonable, prudent, and generally astute person. If the software updates fail, the web filters fail and the security software fails to detect malicious logic that got on a legitimate site (I don't traverse the Information Bridge Under The Superhighway), then, by all means, the intruders earned their prize. (It was probably due for a reformat/reinstall anyway.) I tested MBAE and here was my result: It prevented my AV/HIPS/BB/MBAM from real-time scanning anything--it created vulnerabilities It saw Foxit Reader as an attack and protected Foxit Reader from itself. How many false positives per actual exploit do you think I would have? I cannot answer since I cannot divide by zero I would argue that anti-this and anti-that has reached critical mass; the more moving parts, the more that can go awry.
What does this list has to do with you not using anti-exploit software? The first three simply aren't even a possible mechanism of infection or issue for me - are they for you? Maybe we're on different pages here The main security risk of Java has traditionally been through exploitation, primarily through the browser plugin - and Java isn't being targeted like it used to be anyway. The top five as I see them, and realistically what I believe have been the most effective defences: 1/ Internet/network (worms) - firewall more than patching; 2/ Browser (exploits) - attack surface reduction (patch, whitelist only for plugins, adblock, etc); 3/ Email (trojans & exploits) - knowledge, using special email address for finances, third party script blocking; 4/ USB (worms/trojans) - autorun off; 5/ Browser (user downloaded trojans) - knowledge/judgement, testing. Anti-exploit adds an extra layer to this (reducing risk from worms, emailed trojans, and exploits), as does default-deny e.g. via software restriction policies (reducing risk from exploits to drop and run trojans). Software policies can also be used to deny execution of filenames like *.mp3.exe, and I know CryptoPrevent utilises this by default. I whitelist browser script sites using NoScript, but there's some obvious holes in this that you've identified, e.g. CDNs can be abused. I also agree that information security is a major problem.
Yes, this is the biggest problem with anti-exploit tools, they sometimes can cause unexpected problems. But I haven't got any problems with MBAE at the moment, it seems like quite a mature product, and developers are quick to solve any problems.
I believe in exploit mitigation techniques being built into the OS and apps itself as much as possible. Failing that, something like EMET might prove itself useful for legacy apps and apps that download/render content.
It's funny how people can have the same beliefs, yet be lead in the opposite directions Where you use AV, HIPS, BB, & AM - I don't need any of those. Appreciate you letting them know about your compatibility issues with MBAE though.
My AV has HIPS and BB (most do nowadays); I only have it (Qihoo 360) and GlassWire (HIDS and network eye-candy) free running. I don't run MBAM real-time on my production machines, only during some testing.
