I’m just now scratching the surface on 3.0 Def +. I would like to know how the experts treat their 'net browser in D+, especially with browser Add-ons/extensions (which may/or may not be secure) being popular. What type of application do you assign it, and what type of modifications to the application (if any) do you assign to it for both security as well as limited problems/hassles/PUs? I see that 3.0 has 5 different pre-assigned application settings in Def +, each with the listings of
Run- executable Ask/Block - 2) interprocess memory Accesses Ask/Allow/Block - 3) Windows/WinEvent Hooks Ask/Allow/Block - 4) Process Terminations Ask/allow/block - 5) Device Driver Installs Ask/Allow/Block - 6) Windows Messages Ask/Allow/Block - 7) Protected COM Interfaces Ask/Allow/Block - 8.) Protected Registry Keys Ask/Allow/Block - 9) Protected Files/Folders Ask/allow/Block - 10) Loopback Networking Ask/Allow/Block- 11) DNS Client Service Ask/Allow Block - 12) Physical Memory Ask/Allow/Block - 13) Computer Monitor Ask/Allow/Block- 14) Disk Ask/Allow/Block - 15) Keyboard Ask/Allow/Block
Also if this has been covered in a thead/or the 3.0 help section/link please…thx
I lock down on programs that could be exposed to malicious content. Such programs would include Internet-facing programs such as web browsers and email clients, and also programs that use data files from unknown sources. One reason for locking down on programs, such as media playing programs, that use data files from unknown sources is because of buffer overflow exploits. If you are victimized by a buffer overflow, Comodo Firewall will not detect it (as of the day I write this), and the buffer overflow code will be allowed to do whatever the process with the buffer overflow is allowed to do. Another reason to lock down on such programs is because of possibly malicious scripts or other programmatic capabilities present in web pages, .chm files, .pdf files, etc.
In more detail, here is how I lock down on programs that could be exposed to malicious content. This only applies if you’re using one of the Defense+ modes that allows training. So if you’re using Paranoid Mode, then none of this applies to you. First, run the given program awhile, exercising its functionality in order to let Defense+ train on what the program needs to do. Then, after some time has passed, set most Defense+ settings for the given program that are still set to Ask, to Block instead. Protected files/folders, however, I keep on Ask, because training doesn’t apply to protected files/folders, except during part of computer bootup. Also, sometimes I deny a given program rights to some things it requests, such as keyboard access, that may be abused by malicious code running inside the given program. If something doesn’t work right with the given program, look at the Defense+ logs to see if you need to allow something that was blocked. Failure to do this locking down of programs that could be exposed to malicious content, in conjunction with using modes that allow Defense+ to train, will cause Defense+ to train when malicious code is run within the given program!
There are some other things you can do outside of Comodo Firewall to increase security for programs that could be exposesd to malicious content. I recommend using Comodo Memory Firewall, a free separate product, to protect against (hopefully most) buffer overflows. Also, let your antivirus program’s resident scanner scan all files, not just executable files, because your antivirus program may detect tainted data files that cause buffer overflows. Last but not least, for every one of your programs that could be exposed to malicious content, make sure it runs with limited operating system privileges; see http://www.broadbandreports.com/forum/remark,14461638 for an example of how to do this in Windows XP with Internet Explorer.
Thx for the link, that was interesting. Just out of curiosity, what happens during a buffer-overflow attack? Does your browser and OS just lock-up? as I’ve had this happen several times, and I’ve immediately D/Ced from the 'net physically, and had to do a hard-shutdown and restart. Is the damage already done when you restart? Is an AV with HIPS, the regular CFW, and BoClean, not enough to stop this kind of malware attack? Also, is running a browser like FX or Opera in the Limited-user account enough for limited OS privileges? Windows is a h*!!uva an OS, when you have to run an AV/HIPS, SW-FW, HW-FW, real-time malware scanner (such as BoClean), and then have to run a Buffer-overflow FW on top of all that!—just to surf the internet, Why not run a sandbox, as well? no wonder you need at least a gig of ram anymore just to get on-line. This whole surfing/security thing is just completely out of control, imo, and I still don’t understand why anyone would want to load up their browser with a bunch of cute add-ons (security-holes), that aren’t specifically geared for increasing browser security.
Here is a part of the Wikipedia article on ‘buffer overflow’: “A buffer overflow is an anomalous condition where a process attempts to store data beyond the boundaries of a fixed-length buffer. The result is that the extra data overwrites adjacent memory locations. The overwritten data may include other buffers, variables and program flow data and may cause a process to crash or produce incorrect results. They can be triggered by inputs specifically designed to execute malicious code or to make the program operate in an unintended way. As such, buffer overflows cause many software vulnerabilities and form the basis of many exploits.” Full article is at Buffer overflow - Wikipedia.
A lockup in your browser does not necessarily indicate that you had a buffer overflow attack. If you are the victim of a buffer overflow attack, code from the attacker runs inside the process attacked. To be a victim of a buffer overflow attack, there has to be a vulnerability in a program, and an exploit has to be targeted for that program. So it’s a good idea to keep programs that could be exposed to malicious content up to date; use Microsoft Update and Secunia PSI to help keep your programs up to date. Defense+ will not warn you about buffer overflow. Antivirus may be able to warn you, if you allow it to scan all files, not just executable files. BOClean will not detect the buffer overflow code. However, since the amount of space available to run the buffer overflow code can be quite small, the buffer overflow code will often launch or use another process to do most of the dirty work; at this point BOClean may be able to detect the malicious code. Here is an article from the maker of BOClean about BOClean and a particular buffer overflow exploit: http://www.privsoft.com/archive/nws-wmf.html.
If you’re already running with a limited user account, then you’re already running your browser with limited operating system privileges. I was assuming in my previous post that the user is running as administrator, and wished to reduce privileges in some programs.
I’ve decided to not lock down on programs facing possibly malicious content any longer. Instead, I’ve set Defense+ to Paranoid Mode, and set most of the settings for these programs to Ask. The reason for this change is that I didn’t like going through the Defense+ log to find out what was causing a locked-down program feature to fail, and then having to make the necessary change in Computer Security Policy. In Paranoid Mode, no training will take place, so I don’t have to worry about a malicious script, buffer overflow exploit, network exploit, etc, doing anything that I didn’t previously allow in Computer Security Policy for the given program.
Programs prone to malicious activity really dont need to be locked down. Thats what antiviruses, and D+ in this case are for. Also updating your OS will eliminate many exploits, so a lockdown isnt nessesary. Unless your guarding a HUGE secret O.o
I’ll give a specific example to show why I lock down on programs that are exposed to possibly malicious content. Let’s suppose you’re running Defense+ in a mode that allows training, which is the default. You friend gives you an mp3 that he got from the Internet from a source that is not trustworthy, and he didn’t tell you where he got it from. You have an antivirus memory resident file scanner, which you have set to scan all files with executable content (.exe, .dll, etc). The media player that you use to play the mp3 is a popular program, and is on Comodo’s whitelist. Unfortunately, the current version of the media player is vulnerable to a buffer overflow exploit when playing poisoned mp3 files. Unfortunately also, the mp3 that you got from your friend is a poisoned mp3. Your antivirus scanner does not scan the mp3, because you have it set to scan executable files only. You play the poisoned mp3 file with your media player program. A buffer overflow occurs within the media player program. Comodo Firewall does not tell you that a buffer overflow occurred, because it is not designed to (yet). The shellcode from the poisoned mp3 is a simple keylogger program. Because Comodo Firewall is training on this media player program while the shellcode is running inside the media player process, Comodo Firewall automatically lets the program have low-level keyboard access. After a period of time, the shellcode starts Internet Explorer invisibly via COM interface, and sends your harvested keystrokes to a rogue website. Again, because Comodo Firewall is training on this media player program while the shellcode runs, Comodo Firewall automatically allows the protected COM interface for Internet Explorer to be used. So, now your keystrokes have been sent to a rogue website. Too bad that you were typing in confidential bank account login info while the keylogger was running…
If, instead, you had either locked down on the media player program, or were running in Paranoid mode, and if you hadn’t previously allowed the media player low-level keyboard access and not previously allowed the protected COM interface to Internet Explorer, this scenario would have been either blocked (if you had locked down on the program and are in a Defense+ training mode), or you would have been prompted for the keyboard low-level access and use of the protected COM interface to Internet Explorer (if Defense + was in Paranoid mode).
This example also shows why, IMHO, you should not run programs that might be exposed to malicious content as a Trusted Application in Defense+, as some others have advocated on the forums, even though the given program may be considered a safe program by Comodo. If you had run the given program as a Trusted Application, and also if you are not running the given program with limited operating system privileges, the shellcode could have created and loaded a driver, leading to you perhaps being infected with a rootkit.
This example can be generalized to any program that is exposed to possibly malicious content. Mitigating factors are that Defense+ does not train on running of executables, nor modification/creation/deletion of protected files. Also, another mitigating factor is that because of possibly limited space in the buffer, shellcode might instead merely instruct a web browser to download further code for the exploit, at which point Defense+ might alert, either at the point of the attempted execution of the web browser, or, failing that, at the execution of the exploit code that the web browser downloads. And if your Defense+ configuration allowed both to happen, your antivirus, etc, may have detected the malicious code downloaded.
Yes but first of my antivirus does scan all files. Second of all (in my case) I would get a warning from nemerous sources that not only there is a keylogger but that mp3 was spawning another process.
Other then that it is highly unlikely that an MP3 would contain that kind of attack, as mostly movies are infected.
With that aside, once they keylogger (in this case) loads into memory it will be detected or blocked by heuristics. Also a lockdown isnt nessesary because D+ would alert you to the spawning of the keylogger.
There needn’t be another process spawned when buffer overflow code is running inside of a program. As far as the operating system is concerned, it is, in my example, the media player that is running. The buffer overflow code could launch another process, and in real life I’m guessing it normally would, but it doesn’t have to. If you don’t believe me, please try the proof of concept in the following link, and verify that Comodo Firewall gives no alert when the buffer overflow happens (I’m not referring to the possible alert for the separate calculator process spawned): https://forums.comodo.com/feedbackcommentsannouncementsnews/result_of_real_world_exploit_test_comodo_memory_firewall_worked-t18683.0.html. In this proof of concept, the shellcode that is launched is merely the running of Windows calculator; this shellcode is not part of another process and thus your security tools probably won’t alert you, unless you are referring to the separate Comodo Memory Firewall or similar buffer overflow detection programs. In this case, the calculator will be a separate process, but the code that launched the calculator is not part of a separate process; instead of launching a calculator, it could just as easily have been keylogging code not launched in a new process, provided there is enough space available to fit the keylogging code.
You can substitute your favorite movie player and a poisoned movie media file in place of the mp3 player and poisoned mp3 in my example then, but the threat remains the same.
If the keylogger has been launched as a separate process, then yes, as I alluded to, it’s fair game for your security tools and Defense+ to stop. However, if the keylogger is within the buffer overflow code for the media player, then your other security tools will not know about it (except for maybe buffer overflow detection tools), because the exploit code for the keylogger in this case is part of the process for the media player. Do you know of a program, preferrably free, that regularly scans all processes for malware? BOClean scans just near the beginning of the spawning of a new process, but not thereafter, if I am not mistaken.
Good. Mine does also. But what about for other Comodo Firewall users who don’t know to do this? After all, some antivirus scanners do default to scan only executable files. And there is the possibility that your antivirus will not catch it anyway, even if you do have it set to scan all files, because all antivirus programs miss some malware samples.
You make good arguments. However as being on several hacker forums (and an aspiring white hat myself) most users have patched programs, which are set to ‘auto update’. However if a program update isnt used or the program is out of date, windows does have several built in security mechanisms (which are always updated concerning 90% of users) that will foil any part of the process thus ending the whole process.
Please refer here:
It is unlikely that a buffer overflow will be the prime attack of the hacker, because it is difficult to track such attacks (being the hacker) and it is very unlikely the attack can be used on a massive scale.
I see your point, and I acknowledge you are very knowledgeable, I am simply saying a buffer overflow is more of a rare encounter and should be considered in deploying protection, but it is a very rare attack.
Thank you also for your good points, Info-Sec. I assume you are referring to the Data Execution Protection feature of Windows XP SP2. However, I don’t believe Data Execution Protection protects against all buffer overflow scenarios. With Data Execution Protection turned on, try Comodo BO Tester. I believe some of the tests will fail. If Data Execution Protection worked in all scenarios, then I don’t believe Comodo would have developed Comodo Memory Firewall. Comodo claims that Comodo Memory Firewall will stop about 90% of buffer overflow attacks, which means of course that some buffer overflow attacks are still possible even with Data Execution Prevention and Comodo Memory Firewall being used. Please also note that the article you mentioned says that Data Execution Protection can be circumvented.
I am not a hacker so I will defer to others on the issue of rarity of buffer overflow attacks. However, I do recall buffer overflow exploits such as the .ANI exploit. According to http://securitywatch.eweek.com/exploits_and_attacks/ani_exploit_tied_to_hacked_super_bowl_site.html, the .ANI buffer overflow exploit, according to eEye, was ‘“one of the most potent zero-days recorded” by the security company’s Zero-Day Tracker.’ As of the time the story at http://www.networkworld.com/news/2007/041007-over-2000-sites-now-exploit.html was written, 2,000 websites had been rigged with this exploit. This exploit was discovered in the wild before any patch was issued. According to http://blogs.zdnet.com/security/?p=150, “[Users] who visit one of the thousands of pages will be infected with a generic password stealer that will run without any user-interaction. Assuming users connect to the sites they will be redirected to two unique locations which are hosting exploit code which in turn downloads and installs a file called “ad.exe”. The file includes a generic password stealer and is not detected well by most Antivirus companies.” In this case it appears that the buffer overflow code did cause a separate file to be downloaded and executed, so your security programs and Defense+ could indeed have protected you, although most of the antivirus programs at the time apparently were not good at detecting the malicious code.
What types of exploits, according to what you have read, Info-Sec, are the most common? And thank you again for your fine points and knowledge
In that article it does indeed tell how to circumvent DEP. But what better way to reinforce your argument by studying both sides?
I am aware of the .ANI and several others that were supposed to be ‘big hits.’ I can assure you they were all over the forums, tons of source code and PoC’s were released. I viewed several of them. The thing was, microsoft became aware of this, and was able to notify vendors, and .ANI became a thing of the past.
If I remember right .ANI was packaged in sound, and cursor programs (correct me if im wrong.)
Anyway, newer exploits are based inside websites, buffer overflows are what I like to call OS based exploits, now exploits are browser based exploits.
An excellent example is phishing, and our security hellhole called myspace.
Again valid points. For the sake of arguments (I like this intelligent talk) from what ive seen hackers arent really going for the buffer overflows. Shellcode is still alive and nuking people with A’s, but lets not forget the difficulty of automating these exploits. It is also quite difficult to get a buffer overflow to execute, with out errors. Also delivering the exploit takes time, and most of the time dosnt hit the target OS.
First off certain things need to be perfect, there has to be an environment in order for the exploit to succeed. Like there has to be this version of IE, and this setting cant be enabled.
Second of all the exploit has to be functional, most of the time to code conks out and just flat out dosnt work.
Then there is OS protection, if the new exploit matches or works in the same way another patched exploit works then the exploit will fail there.
Then again the exploit has to automate, and run silently.
We have been talking like placing the exploit is easy.
Interesting discussion but both sides are missing a few points.
Infosec is right that at the level (which is probably not at the top tiers, correct me if i’m wrong) he is talking about, “hackers” find it difficult to exploit Buffer-overflows. But at the professional levels there is indeed a great deal of interest and work done, particularly for targeted attacks (something most of us do not worry about granted).
He is also somewhat right is pointing out that buffer overflows are somewhat sensitive to system conditions, but this fails to take into account that for people who pay attacks to infect as many computers with their adware as possible, it doesn’t matter. So what if one or two computers don’t get infected, there are still millions of computers out there.
Well when you talk about enterprise level, then this convo is much different. From my understanding brian, and I were talking at the private, home user level. It is also possible to use malware to trigger these buffer overflows, as you have pointed out.
The problem with a separate peice of malware though, is it has to interact with the program at its core levels to trigger the buffer overflow, this can be seen by anything guarding at the kernal level, it can intercept hooks, calls, ect.
I would also like to point out that it has been a pleasure conversing with you brian, and I invite you to add something more to your argument, or hopefully start a thread in the near future, its been a pleasure talking to you.
I didn’t specifiy before, but I was targeting this conversation at anyone who might be reading this topic - that is, a Comodo Firewall user. Most of these I guess would be home users, and maybe some in business also.
Info-Sec and I both agree that web browsers are nowadays a common source of malware exposure. The makers of BOClean, who undoubtedly have seen a lot of malware, state that “the use of exploits has become the MAJOR means by which people and their machines get hijacked in the first place” (source: http://www.privsoft.com/archive/nws-wmf.html). I happen to believe that it’s not rare, for those browser exploits that do succeed, that a buffer overflow exploit was involved. There are a lot of buffer overflow vulnerabilities out there, and they also tend to be the “most severe” type in terms of possible damage done, according to Dark Reading | Security | Protect The Business. Also, common browser plugins such as Adobe Flash, RealPlayer, and QuickTime are not rarely found to have buffer overflow vulnerabilities.
For those who are not familiar, an example of a browser-based buffer overflow vulnerability can be found at Cybersecurity News, Awards, Webinars, eSummits, Research | SC Media. This particular vulnerability allows data stealing through certain versions of Opera and Firefox. An exploit based on this vulnerability is triggered by the user simply viewing a poisoned webpage. Other buffer overflow exploits can do such things as complete system takeover.
I do agree that a specific version of a specific program is required for a buffer overflow exploit to succeed. However, some programs such as Internet Explorer, Adobe Flash, etc, are very popular, and because of auto-update it is probably common that a specific version, namely the current version at the given time, is the version present.
I do agree that a person who writes a buffer overflow exploit needs technical knowledge to do so. However, once written, it can be included in exploit tools such as Metasploit, where people without much expertise can use it.
I do agree that Data Execution Prevention can stop some buffer overflow attacks. However, if a hacker’s potential exploit never works on his/her own machine due to Data Execution Prevention, do you think the hacker would bother to try this exploit on other machines, or instead try something else, such as try to modify the exploit to evade Data Execution Prevention?
I do agree that a given exploit may be unreliable against the particular version of the program it targets for various reasons. On the other hand, a malicious website can try a large number of exploits, some possibly buffer overflow exploits, until one perhaps succeeds. A hacker can purchase a toolkit that has the code already written to do this. If a hacker finds that a particular exploit works seldomly, the hacker can simply move on to exploits that maybe work better. If you have 100 exploits at your disposal, only 10 of which work reliably, which exploits would you perhaps use more often? Because of the commonality, severity, and ease of use of buffer overflow exploits, it would seem to me that buffer overflow exploits would be tried a lot in malicious websites.
From my understanding, this is not true. For example, if you are using a browser version vulnerable to the particular exploit mentioned above, and you view a poisoned image on a website, then that image data is put in a certain place in memory. Nothing happened here that would trigger an alert from Comodo Firewall. 0s and 1s moving into a buffer, and perhaps outside of the buffer due to the buffer overflow programming error, do not trigger an alert from Comodo Firewall. It’s just 1s and 0s being written in memory, which is common for code to do. Unfortunately, because of the buffer overflow exploit, those 0s and 1s happened to contain executable code and can possibly be executed, within the browser process itself! If the rogue code running inside the browser does things such as downloading files with further exploit code, or starts another process, then of course Comodo Firewall could alert you at that point, for the second stage of the attack. But the first stage rogue code triggers no alerts from Comodo Firewall. For example, if you had your browser set to be a Defense+ Trusted Application, and the first stage rogue code modified your hosts file, you would receive no alert from Comodo Firewall, because the first stage rogue code is part of the browser, and a Trusted Application can (try to) change any file without alerts. To summarize, first stage buffer overflow exploit code triggers no Comodo Firewall alerts; second stage code, if present, is fair game to trigger a Comodo Firewall alert. Please see http://www.privsoft.com/archive/nws-wmf.html for an explanation of this, from the people who make BOClean, for a particular buffer overflow exploit.
Why not, Luketan? It worked on the only example I tried - https://forums.comodo.com/feedbackcommentsannouncementsnews/result_of_real_world_exploit_test_comodo_memory_firewall_worked-t18683.0.html. Not a big sample size, I know. But if this had been a malicious attack instead of just a proof of concept, and my antivirus didn’t catch it first, would I have been better off with or without Comodo Memory Firewall? I haven’t seen any cons to using Comodo Memory Firewall on my machine yet, and I have see the pros. It costs nothing. It didn’t seem to slow my machine down. It admittedly does not catch 100% of buffer overflows (Comodo claims it works 90% of the time), but then again your antivirus also doesn’t catch 100% of its target malware either.
I’d also like to mention that buffer overflow exploits are not the only type of malicious content that a program can be exposed to. Any program that allows content to have programming capabilities, such as scripts, could possibly be exposed to malicious programming in the content. Even though the programming capabilities are designed in such a way as to allow no harm to your machine, there are sometimes flaws in the design or implementation of the programming capabilities that can lead to harm being done to your machine.
That was quite a long response, so forgive me if I miss a few points.
I see what your saying, and it is quite possible for the scenario (to which youve displayed) can happen. The glorty of hack tools (for security firms) is that once an exploit is released, weather source code, or an actual compiled, exploit, its detectable. Hack tools once released are detectable, it is very difficult to UD (undetect) a hack tool, because it will end up being detected.
If malware, was to infect, or an exploit was to launch inside of the browser, and run an attack aimed at the host file, any decent antispyware could block the attack, just for the fact that it isnt an authorized change (as defined by user) or an alert will be generated because of a host file change.
It is also very difficult to automate an exploit. It is designed to slip through the cracks if you will, and most exploits can be foiled by the stupidest things (remember proper environments.) Most of the time the environment throws everything off.
The biggest defense is auditing, and leakage. When an exploit is created, its source is posted as a complete exploit, a basis or a PoC. It is then leaked, and circulated. Then it is picked up by a security firm, and patched. When UD a compiled exploit, a lot of the time executable bytes are modified thus nulling the exploit.
To sum it up, malware is a more common attack, because its easier, exploits are becoming the thing of the past because of their complexity, and maintinence costs (time.) If these attacks were this easy then we would all be compromised right now.