I'm working on a thesis about the security hacker community.
When a 0day is published, how can an administrator secure his application/website between the time the 0day is published and the patch is developed ?
Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats ?
The person who discovers a security issue often reports it to the software vendor or developer first. This gives the software vendor time to fix the issue before publication. Then, after it is fixed, the bug is publicly disclosed. This process is called responsible disclosure.
Sometimes, someone doesn't disclose the zero-day to the software vendor but uses it to hack other systems. Doing this can tip off security companies and disclose the bug, burning the zero-day.
I don't think your statement "most of the time, this same 0day is used for months by black hats" is true. This is true for some security issues, but a lot of zero-day bugs are found for the first time by white-hat hackers. I wouldn't say black hat hackers are ahead of white hat hackers. They both find security issues and some of these overlap. However, the offense has it easier than the defense in that the offense only needs to find one bug, and the defense needs to fix all the bugs.
When a 0day is published, how can an administrator secure his application/website between the time the 0day is published and the patch is developed ?
They use temporary workarounds until a patch rolls out.
When news of a 0day comes out, there are often various workarounds that are published which break the exploit by eliminating some prerequisite for abusing the vulnerability. There are many possibilities:
Changing a configuration setting can disable vulnerable functionality.
Turning off vulnerable services, when practical, can prevent exploitation.
Enabling non-default security measures may break the exploit.
Every bug is different, and every mitigation is different. An administrator with a good understanding of security can figure out workarounds on their own if sufficient details about the vulnerability are released. Most administrators, however, will look to security advisories published by the software vendor.
Sometimes, an administrator doesn't have to do anything. This can be the case if the vulnerability only affects a non-default configuration, or a configuration which is not set on their systems. For example, a vulnerability in the DRM video subsystem for Linux need not worry a sysadmin with a LAMP stack, since their servers will not be using DRM anyway. A vulnerability in Apache, on the other hand, might be something they should worry about. A good sysadmin knows what is and isn't a risk factor.
Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats ?
Whitehats are more sophisticated, but blackhats are more efficient.
Whether or not blackhats are ahead of whitehats is a very subjective question. Blackhats will use whatever works. This means their exploits are effective, but dirty and, at times, unsophisticated. For example, while it is possible to discover the ASLR layout of a browser via side-channel attacks, this isn't really used in the wild since ubiquitous unsophisticated ASLR bypasses already exist. Whitehats on the other hand need to think up fixes and actually get the software vendor to take the report seriously. This does not impact blackhats to nearly the same extent, as they can often start benefiting from their discovery the moment they make it. They don't need to wait for a third party.
From my own experience, blackhats often have a significant edge. This is primarily because the current culture among whitehats is to hunt and squash individual bugs. Less emphasis is put on squashing entire classes of bugs and when it is, sub-par and over-hyped mitigations are what are created (like KASLR). This means blackhats can pump out 0days faster than they can be patched, since so little attention is given to the attack surface area and exploitation vectors that keep being used and re-used.
When a zero-day is released or published, it comes with more than just a fancy name and icon. There are details about how the zero-day is used to exploit the system. Those details form the basis of the defender's response, including how the patch needs to be designed.
For example, with WannaCry/EternalBlue, the vulnerability was found by the NSA and they kept the knowledge to themselves (the same happens in the criminal community where vulnerabilities can be traded on the black market). The details were leaked, which informed Microsoft how to create the patch and it also informed administrators how to defend against it: disable SMBv1 or at least block the SMB port from the Internet.
That's how admins protect themselves. Patching is only one part of "vulnerability management". There are many things that an admin can do to manage vulnerabilities even if they cannot or do not want to patch.
In the WannaCry case, the NHS did not patch, but they also did not employ the other defenses that would have protected themselves.
One large part of my job is designing vulnerability mitigations for systems that cannot be patched for various business reasons. Patching is the better solution, in general, but sometimes it just isn't possible at the time of patching.
... are the blackhats ahead of whitehats?
That poses an interesting problem. If a blackhat finds a problem and only shares it with other blackhats (or other members of the intelligence community), does that mean that blackhats, in aggregate, are ahead of whitehats? Yes. Once a zero-day is exposed, it loses its power (that's the whole point of disclosing it). So to keep it secret, gives it power.
Are blackhats better skilled or use better techniques than whitehats? No. But the shared secrets gives blackhats more power, in aggregate.
When a 0day is published, how can a whitehat secure his application/website between the time the 0day is published and the patch is developed?
Sometimes there are workarounds which fix or mitigate the problem.
/usr/tmp/sh. This confused the worm and prevented it from working.But sometimes none of these is a viable option. In that case you can only hope that there will be a patch soon.
Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats?
It happens quite frequently that developers / whitehats discover a possible security vulnerability in their software and patch it before it gets exploited. The first step of responsible disclosure is to inform the developers so they can fix the vulnerability before you publish it.
But you usually don't hear about that in the media. When point 59 of the patch notes for SomeTool 1.3.9.53 reads "fixed possible buffer overflow when processing malformed foobar files" that's usually not particularly newsworthy.
Another key defense is monitoring, and knowing your system.
Where are your valuable secrets, and who has access to them.
If someone tries to connect to your mail server on port 80, red flag.
Why is the mail server, all of a sudden, sending traffic to an unusual IP.
The mail server now has 10x the traffic why?
Monitor people connecting to your external IP's addresses. Drop and/or block all external ports and protocols that are not in use.
No legitimate user is going to connect to your web server on anything but 80 or 443. Unless you have added additional services. You might consider blocking those IP for some time. Sometimes, IP are part of dynamic pools, and you can't always solve a problem with a blacklist, then you just drop the packets.
If your business only does business in 1 country, maybe you should just block all other countries.
You can use whois to find the global owner of the IP address range, and if present use the administrator contact information to notify the owner. They can track it down on their end. (Its worth a try)
You should get notified when any system gets contacted by another system in any unexpected way. After first you may have a ton of notification, but if the computer(s) is on your network then you can investigate both sides. Then either eliminate it or white list it as expected traffic.
These monitor tools will also notify you about port scans, unless you have an authorized security team no one else should be port scanning.
Watch for regular events, and if they stop mysteriously why?
Check the machine for infections. If services are disabled you should be notified in advance so the changes will be expected and not mysterious.
Block as much as possible and monitor the rest.
Now once you have an attack you need to do something about it.
Sometimes turning the system off temporarily is the only option. Maybe you need to block their IP address for awhile.
You still have to protect and monitor all your legitimate services.
In addition to monitoring the community for vulnerability announcements. You should have penetration testers to find the bugs in advance before the hackers. Then you have a chance to mitigate the attack on your terms. Notifying the maintainer of the effect system so they can patch it. If its open source, you can have someone patch it for you.
Intrusion detection systems, and snort can also examine and potentially block incoming hacks by detecting suspicious patterns.
You may have to find an alternate product to replace the vulnerable one depending on the severity of the problem.
As always keeping your software up to date helps to protect you.
This way you can block suspicious activity, until you determine its legit.
Most potential exploits require a chain of vulnerabilities in order to be executed. By reading the as-yet unpatched zero-day, you can still identify other vulnerabilities or pre-conditions that the zero-day would require.
To defend against threat of (say) an RDP attack from outside the network (zero-day RDP authentication failure published), do not allow RDP from off-site. If you don't really need RDP from outside, then this is a chance to correct an oversight. Or, if you must have RDP from off-site, perhaps you can identify a whitelist of IPs from which to allow these connections, and narrow the aperture in the firewall.
Likewise, to defend against an inside (and to some extent outside) RDP threat, limit the ability of A) users to execute RDP, B) machines to execute RDP, C) the network to pass RDP, D) machines to accept RDP, E) users to allow RDP. Which VLANs should have the ability to generate outbound RDP? Which machines should be able to do this? And so forth.
Every one of these steps, in both the outsider and insider scenarios, works to harden your network against an RDP authentication exploit even without a patch.
A defense-in-depth mentality allows you to break the chain of vulnerabilities / conditions required for even an un-patched zero-day to be countered. Sometimes.
I have intentionally chosen a fairly easy problem here just to illustrate the point.
Source -- I have done this before.
Relatively few hacks allow the attacker to break into a system. Most are "privilege escalation" bugs that allow an attacker to have greater control over the system after they have access to it. There are so many ways to achieve administrative control of a machine once a hacker has access to it, that it is more or less a waste of time to try to secure a machine against privilege escalation. Your best policy is to focus on preventing hackers from getting inside in the first place and monitoring your network for intrusion.
Nearly all intrusions come from just three methods. You want to spend all your available cyber defense resources defending against these. They are:
(1) Phishing emails containing poisoned PDFs or PPTs. There are tons of zero days targeting PDFs and PPTs, and the nature of both these application formats is such that there is more or less no way to secure yourself against a contemporary trojan in either one. Therefore, you basically have two options: require all PDF/PPT attachments to go through a vetting process, which is not practical for most organizations, or to train your employees to vet emails themselves which is the best option in most cases. A third option is to test all PDFs and PPTs sent to the organization in a sandboxed environment after the fact, but this is only possible for advanced organizations, like the military, not the average company. Option 3 of course does not prevent the intrusion, it just warns you immediately if one occurs.
(2) Browser vulnerabilities. The vast majority of browser-based exploits target Internet Explorer, so you can defend probably 95% of these just by preventing users from using IE and requiring them to use Chrome or Firefox. You can prevent 99% of browser based exploits by requiring users to use NoScript and training them in its use, which unfortunately is not practical for most organizations.
(3) Server vulnerabilities. An example would be the NTP bug from a few years back. You can largely defend against these by making sure that all company servers are running on isolated networks (a "demilitarized zone") and that those servers are tight and not running unnecessary services. You especially want to make sure that any company web servers are running by themselves in isolated environments and that nothing can get into or out of those environments without a human explicitly doing the copy in a controlled way.
Of course there are lots of exploits that fall outside these categories, but your time is best spent addressing the three classes of vulnerabilities listed above.
Well, its ok to have 0 days from an attacker, the problem is how many zero days they have and how much does it costs for them to burn all the 0 days in your network.
If you don't have patches up to date, it lowers the cost for an attacker to develop a kill chain.
When you think about it, how would you send start attacking a network? Let say you start with a phishing attack / waterhole attack.
If it is a waterhole attack, you might need to find a 0 day in flash which allows you to execute code in the browser, and then you might need to break out of the browser sandbox first, which requires another 0day. And next you might face appcontainer, which requires another exploit to reach OS level privilege. And there are protection mechanism such as SIP in macOS, it means even if you have root access, you cant access important memory. That means you need another 0day kernel exploit. If it is running windows 10 with cred guard and you are targeting Lsass.exe, then you might need another 0day to attack the hypervisor.
So it turns out the attack is very expensive and requires a lot of research effort, and in the meantime while you exploiting them, you might trigger security alert.
So as a defender, make sure you know your network well, have defence controls in every single layer and you should be able to defend against 0 day attack.
The problem is not only with zero-days. There are plenty of companies which still drag on 200-days patches for a multitude of reasons (some good, some bad).
You have a large list of solutions, another one is to use virtual patching. It usually creates a mitigation for the issue before it hits the service (I learned about it years ago though a Trend Micro product - no links with them but I tested it and it mostly worked).
