Bypassing Antivirus with Ten Lines of Code
attactics.org
attactics.org
At VirusTotal we are tired of repeating that the service was not designed as a tool to perform antivirus comparative analyses, but as a tool that checks suspicious samples with several antivirus solutions and helps antivirus labs by forwarding them the malware they fail to detect. Those who use VirusTotal to perform antivirus comparative analyses should know that they are making many implicit errors in their methodology, the most obvious being:
-VirusTotal's antivirus engines are commandline versions, so depending on the product, they will not behave exactly the same as the desktop versions: for instance, desktop solutions may use techniques based on behavioural analysis and count with personal firewalls that may decrease entry points and mitigate propagation, etc.
-In VirusTotal desktop-oriented solutions coexist with perimeter-oriented solutions; heuristics in this latter group may be more aggressive and paranoid, since the impact of false positives is less visible in the perimeter. It is simply not fair to compare both groups.
-Some of the solutions included in VirusTotal are parametrized (in coherence with the developer company's desire) with a different heuristic/agressiveness level than the official end-user default configuration.
thanks,
> perform antivirus comparative analyses
is not what is happening here.
-VirusTotal's antivirus engines are commandline versions, so depending on the product, they will not behave exactly the same as the desktop versions: for instance, desktop solutions may use techniques based on behavioural analysis and count with personal firewalls that may decrease entry points and mitigate propagation, etc.
-In VirusTotal desktop-oriented solutions coexist with perimeter-oriented solutions; heuristics in this latter group may be more aggressive and paranoid, since the impact of false positives is less visible in the perimeter. It is simply not fair to compare both groups.
-Some of the solutions included in VirusTotal are parametrized (in coherence with the developer company's desire) with a different heuristic/agressiveness level than the official end-user default configuration.
It says right in the parent comment that the VT results may not actually reflect how the product performs in the real world.
It was basically a firewall on the kernel level.
It worked splendidly, however, I was never able to gain any traction in marketing it. That was back at around OS X 10.4 now. I've been waiting for another company to come along with something similar - since it really does seem a comprehensive way of blocking viruses (albeit more suited to more advance uses). I'm still waiting for something like that.
See Windows Vista.
OSX has discretionary access control, which can be configured to be a full MAC[3].
Starting in OS X v10.5, the kernel includes an implementation of the TrustedBSD Mandatory Access Control (MAC) framework. A formal requirements language suitable for third-party developer use was added in OS X v10.7. Mandatory access control, also known as sandboxing, is discussed in Sandboxing and the Mandatory Access Control Framework.[4]
[1] https://en.wikipedia.org/wiki/Mandatory_access_control
[2] https://en.wikipedia.org/wiki/Security-Enhanced_Linuxhttps:/...
[3] http://sysdev.me/trusted-bsd-in-osx/
[4] https://developer.apple.com/library/mac/documentation/Securi...
Instead, Apple designed a KAUTH framework, which is way more limited than MAC, but can be used to implement some features that will be stable across kernels (it has ABI stability). There are already some AVs that are using KAUTH.
――――――
However, if a technical user is using the product, it makes security 100% solid. You can literally intentionally download and run any virus, with full confidence that you can easily stop it from doing anything you dont want it to. Since a dialog box is created before it can read or write to any file, there is literally nothing it can do without your permission.
It's also useful for monitoring what an installer or app is doing to your filesystem, exactly what files it is touching as it goes along, and also how to thoroughly uninstall it if you want to.
I have been meaning to make a cut down version just for the filesystem monitoring and as an uninstaller that works 100%. You can even make an uninstaller that not only uninstalls all files that were created alongside the file you choose, but also any files that were created by any of those files (by logging the paths of the open()'s with O_CREATE by any of those files)
What about a virus that reads your keystrokes or screenshots your screen and sends them to the Internet? Or a virus that spams or does DDOS attacks?
Same with the screenshots. You'd allow it to do whatever you feel like, but you might stop it when it tries to actually create the screenshot file, but allow it to do everything else in order to monitor its behavior. And since it's all in real time, with dialog boxes coming up for each of its actions, it makes it quite interesting to do so.
Out of curiosity, could you provide a link to the website advertising your kernel extension (if it still exists)? As an OS X user, I feel pretty bad that I wasn’t aware of its existence (I would’ve certainly recommended it to my friends).
――――――
¹ — http://www.oneperiodic.com/products/handsoff/tutorials/img/p...
It was based on a port of OpenBSD's PF firewall and let you set fine-grained permissions on file, network, and registry access. It's a painful training process for newly-installed software (lots and lots of prompts) but I haven't seen anything else come close to what it offered. I wonder if that pain is why they seem to have abandoned it; at some point the average user would end up just uninstalling it or clicking "Allow" for every prompt.
Once up and running, however, you could do some really cool things such as giving a process read-only access to its installed directory plus the ability to read/write to a specific folder you store that program's documents in. Attempts by the program to read outside those directories would be rejected, with mixed results (from gracefully handling it, to endless alert dialog looping, to crashing) depending on how well the software was written.
Once you've intercepted read() and write(), you control almost everything. One of the demos I did was injecting content into HTTP responses. Fun project, very glad I didn't ever share the code for it :)
Somewhat related: http://security.stackexchange.com/a/117312
- This wouldn't work for larger payloads. AVs flag binary looking data that is larger than a certain size and that is later processed or assigned to a variable.
- Their veil project has some problems. Py2EXE gets marked as malware by some AVs in many cases just because it is Py2EXE. Same thing with non-commonly used obfuscators. Basically, they just pick up on the fact that something is obfuscated. If that obfuscator is not commonly used in goodware programs, it is marked as malware. This is kind of a dumb strategy on the part of AV engines, but it works okay.
You're not going to catch new malware with static (or dynamic for that matter) analysis anyway. Thing is, the problem is ill-defined.
What is malware?
Is it a program that does something a user doesn't want? If users knew what regular programs do, they wouldn't be okay with most of it either.
Is it a program that does some obfuscating tricks and exploits undocumented functionality in the system? Plenty of legit programs including a lot of AV engines do that as well.
The only usable definition in my opinion is that it is a program that makes the user unhappy with no easily accessible way of removing it completely.
This is why the only solution seems to be to only allow installation from a trusted repository. I am still not sure why Windows/Apple OSX haven't adopted such a strategy (with a developer mode override option for some advanced users).
OS X Sandboxing seems to have the right idea: Instead of worrying about what the user doesn't want, do only what the user WANTS.
Basically, sandboxed apps don't have access to files and folders other than the ones that the user explicitly chooses in an Open/Save dialog. It's a surprisingly nag-free opt-in mechanism that "just works."
After that, automatic backups will let users revert any undesirable changes to their data, whether they were made by their own selves or by malware.
I think operating systems should just do a better job of making the user more aware of all recently-modified files, especially if a process has been modifying a large number of them in a short time (the recent ransomware comes to mind) or if a third-party background process has been generating an uncanny amount of network traffic.
Seeing something like "1,590 files modified" on log-on or in a notification, is way more alarming and would make users take immediate action, compared to all the usual OS or antivirus nags that we are all accustomed to subconsciously agreeing to.
https://blogs.msdn.microsoft.com/e7/2008/10/08/user-account-...
That being said, the "execute downloaded executable" protection only applies when the binaries are marked as being from the internet, which is easy to bypass. You just need to download the software in a way that the mark is not applied (e.g. not through a software mechanism designed to apply it). Furthermore, attacks need not rely on "execute downloaded executable". They just need to achieve code injection, which bypasses the need to run through the "execute downloaded executable" process. However, any injected code would be able to download and open without triggering UAC by not marking the file as having been downloaded from the internet. Such file marking is entirely voluntary and malicious code would likely never voluntarily do it.
Protection against inadvertent execution of software downloaded from the internet is the only function in UAC that is useful. The other functions are designed to operate on already executing software. Since already executing software can gain system privileges (above administrator privileges) via vulnerabilities the that Microsoft refused to fix, it can do basically anything it wants. UAC is fairly useless against it because anything it wants includes turning off UAC. I know enough about Windows security that I stopped using Windows years ago, so I do not know whether UAC would require malicious software that has gained system privileges to turn it off. If it does, it should be a simple matter. Anyway, the hot potato proof of concept code demonstrates gaining system privileges by exploiting such vulnerabilities:
http://foxglovesecurity.com/2016/01/16/hot-potato/ https://youtu.be/Nd6f5P3LSNM
The video of it running on Windows 7 uses the system privileges to give a regular user administrator privileges. There is a Windows firewall prompt that appears in the video, but it does not stop the exploit. The appearance of the prompt ought to be avoidable because whatever triggered the Windows firewall prompt was not necessary for the exploit and could be removed.
Isn't that what Gatekeeper (https://support.apple.com/en-us/HT202491) is supposed to be?
One weird thing w.r.t. Gatekeeper is that it seems to depend on everybody who downloads signed executables not via the App Store to blacklist them (by adding some extended attribute to the file)
I think a whitelist would be more reliable.
Should I be shocked? Shouldn't I be? I'm currently shocked but I don't know if it's justified, not an expert in the field.
It's impossible to determine whether software is malicious or not (Rice's theorem).
Antivirus software only reliably detects code that is identical to known malicious software.
Which is why proof-carrying code [https://en.wikipedia.org/wiki/Proof-carrying_code] is a good idea: the onus ought to be on the programmer to provide (machine-checkable) evidence that their program is safe to use, for whatever notion of “safe” might make sense in your system.
Better route was started in Burrough's where you pick a language good at correct programs and carefully design a safe machine around it. Same with System/38, SAFE (crash-safe.org) for functional, and Cambrige's CHERI for C language. The fundamentals work as advertised along with ability to enforce arbitrary security policies. Then design and security stuff are built on that. Only thing known to work consistently to any degree of success.
On COTS hardware, separation kernels and compiler transforms on legacy code are about best that we can do.
The only reliable things in security are the things that an attacker cannot bypass even when knowing that they in use (e.g. RSA). The premise of the article being discussed is that heuristics are trivial to bypass.
It looks like "halting problem being unsolvable" -> "rice's theorem" by a subset relationship. Consequently, if rice's theorem were false, you could solve the halting problem by modus tollens.
That being said, I had using the halting problem as my way of saying that identification of malicious software is impossible because infinite loops can be malicious and I had been unaware of rice's theorem. I will use that in my explanations in the future.
No, this is a principle limitation of any AV software that is based on blacklisting.
> Did no one come up with this before?
Of course other people came up with similar ideas before.
> Should I be shocked?
If and only if you had trust in your AV software before.
The main thing is to make sure you trust the things you're clicking on.
If you have to visit websites or try programs you don't trust, some people have virtual machines specifically for those situations. They'll visit the site/open the program inside the VM, and if something sketchy does happen, it'll be contained within the VM and not infect the host OS (unless it's incredibly sophisticated malware that can break out of VMs--but very unlikely you'd be targeted by something like that).
If you're really paranoid, you can save the state of the virtual machine before use, and restore the prior state every time you use, it, preventing any changes to the VM. You would occasionally want to start it up, install all the recommended updates, and then save the state again though.
1. Antivirus software that gives a false sense of security being popular.
2. The vendor refusing to fix vulnerabilities that give attackers complete control because of backward compatibility concerns:
http://foxglovesecurity.com/2016/01/16/hot-potato/
3. UAC prompts that annoy users to the point where the user either turns them off or automatically clicks yes. This is in part because of the even weirder situation of legitimate software often being written to touch things that it has no business touching.
4. End users trained to execute software obtained from random internet sites.
5. File names used to identify files as executable.
There are probably other backward things with regard to security too, although I cannot think of them offhand.
Your best choices would be installing a Linux distribution or buying an Apple machine running Mac OS X. If you must use some sort of Windows, check out ReactOS:
That likely does something by virtue of not having same bugs and not having yet implemented the legacy things that exploits often target. It is not as good for security as Linux or Mac OS X though.
The only thing that antivirus software does semi-decently is identify known software binaries. Antivirus software cannot reliably identify unknown binaries through heuristics because writing software to understand unknown software binaries is impossible in general. There are potentially an infinite number of ways of proving that, but the easiest way that occurs to me is that one of the many things necessary for understanding unknown software in general is solving the halting problem, which was proven to be impossible in general by Alan Turing.
Furthermore, the utility for a database of known malicious binaries is practically non-existent. Malicious software is always designed to exploit some vulnerability and once the vulnerability is fixed by the vendor, there is nothing for the antivirus software to do. If you could apply the definition update that the antivirus software needed to catch malicious software, you could have applied the vendor patch that fixed the vulnerability the malicious software used in the first place. That not only makes the definition update unnecessary, but handles the unknown things that the definition update would never have caught.
In the cases of a vendor being slow to patch, refusing to patch (e.g. the exploits used by the hot potato proof of concept code for all current Windows versions) or the user not applying the patch in time (e.g. lack of scheduled downtime), the inability of antivirus software to catch unknown software using those vulnerabilities provides a false sense of security. If a system is specifically targeted by a malicious hacker, the hacker would use something that antivirus software would not catch, such as a script kiddie tool against which there are no known definitions or custom code. Being unfortunate enough to be attacked by a virus, trojan, etcetera before they get definitions also means there is no protection.
Real security requires doing things like minimizing attack area and configuring things competently (e.g. not using your username as your password). That is something that you cannot get from an antivirus vendor.
No, a whitelist isn't good enough. You can't anticipate an exhaustive list of the programs the user will want to run.
What you can do, however, is enforce a policy by which programs are required to provide machine-checkable evidence, also known as proof-carrying code [https://en.wikipedia.org/wiki/Proof-carrying_code], that they respect the system's safety policy.
> it's a necessary but sufficient condition
Perhaps you mean “not sufficient”?
Whitelisting seems to be working out well for Apple. It's a big part of why they're the most secure smartphone platform.
When you don't root your android or iPhone they handle it a lot better than desktop operating systems.
I wouldn't be surprised if this was a common practice; we considered our product's detection capabilities to be proprietary.
void *exec = VirtualAlloc(0, sizeof c, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
Would be a red flag. I don't know how many programs use that on the Windows side of things but I have almost never seen programs call this function that weren't "crypters."
I am honestly impressed how simple this program is (it's the most elegant crypter I've probably ever seen) but I am still wondering whether heuristics could be made to detect this (without also falsely detecting thousands of other programs?) What do you think OP? Not really my field but curious all the same.
What's more, every program that uses Boost on Windows calls VirtualAlloc, in several places.
How? That's the principle that everyone's missing! Sure, you can change the code a bit, but the millions of copies of your worm out there already can't magically change themselves after AV vendors update their blacklist. Sure, you can make a polymorphic worm, but even after mutation, your worm still probably has common patterns that blacklist makers can catch.
I'm a fan of proactive, not reactive security --- but let's not pretend that what AV vendors are doing is completely bogus.
You also have to keep in mind that blacklists are behavior heuristics are more suited to a bygone age --- one of low-bandwidth, sporadic connections and floppy disks that could be infected with trojans. Nowadays, we're more worried about drive-by 0day flash exploits from ad networks than about infected, self-propagating executables.
I've always found it fascinating that the human immune system has both proactive and reactive security, just like our computers should. The innate immune system [1] is analogous to mandatory access control, OS file permissions, buffer hardening, and other non-specific security mechanisms. The adaptive immune system, on the other hand, works like a blacklist updated throughout your life (and propagated from mother to child!).
Both systems catch threats the other does not. There's still a lot to learn from biology.
[1] https://en.wikipedia.org/wiki/Innate_immune_system [2] https://en.wikipedia.org/wiki/Adaptive_immune_system
((void(*)())exec)();
Type cast a void pointer to a void pointer, execute the result, then execute the result of that? Or ... Can anyone explain what's going on here?
Exec (before the cast) points to memory containing the shellcode data.
To actually start executing the shellcode, you just need to somehow cause the program counter to point to the address of the shellcode.
An easy way to change the program counter is by calling a function ... which is what this line does.
Read this as "cast exec to a pointer to a function that takes zero arguments and returns void and call the function with no arguments."
This is the same as:
typedef void (*some_func)();
some_func func = (some_func)exec;
func();
It's not executing any old binary: the 'shellcode' has to be position-independent and can't rely on any normal PE features; it has to do all it's library loading on it's own etc.
yes, very possible to create. but if your malware/tool you want to run is large, it will take a fair amount of time to convert.
Anti-virus bypasses and even exploits are extremely common. My current line of thinking is that the best way to take control of your computer is to use virtualization to run many separate OS images for different sets of uses.
This reminds me of Nintendo's approach to emulation for their Virtual Console, actually. Rather than having a standalone emulator that you download images for, they package the emulator with the game. This way they never have to worry about inadvertantly breaking anything with a future release, but on the other hand any subsequent emulator improvements do not retroactively apply.
> Are reposts ok?
> If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
> Please don't delete and repost the same story, though. Accounts that do that eventually lose submission privileges.
Looking at the public available data of the 3 submitters, they look like real independent user (not sockpuppets or something).
* applying security updates
* enforcing least privilege
* reducing attack surface (e.g. Does your desktop really need open ports?)
* using decent passwords and two factor authentication when possible
* not reusing passwords in case a place where you used a password is compromised
* not executing code from untrusted sources
* checking whether code from a trusted source is vulnerable to a MITM attack before executing it
* saying no to prompts for elevated privileges unless you can prove to yourself that there is a good reason for them and finding out what caused a prompt for elevated privileges when you see no legitimate reason for it
* wiping a system should you think it might have been compromised and maybe also discarding the hardware just in case firmware was altered, which is what the US government tells US CEOs to do with things that they bring to China
* not providing confidential information (e.g. your password) just because someone claiming to be a trusted party such as IT called asking for it
That last one is how the NSA red team hacked the Pentagon's Joint Staff intelligence directorate when doing penetration testing as part of a "war game" in 1997:
http://www.slate.com/articles/technology/future_tense/2016/0...
That said, there are likely more when thinking about confidentiality (the other half of security), but these are the ones that occur to me when I think about ensuring system integrity.
Anyway, antivirus does not save you if you fail to do any of those things. Anything that could get by all of that would be a zero-day attack where antivirus software is likely to be similarly useless. Not all zero-day attacks can get past all of that (minimal attack surface is awesome). If you are the principle target (like the Pentagon was for the NSA red team), antivirus software has no chance of saving you against a zero-day attack.