Qfyilyi

I'm working on a thesis about the 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 of 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 since 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 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 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 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.

• Sometimes you can disable some feature or change some setting in the software which causes the exploit to not work anymore. For example, infection with the Morris Worm from 1988 could be prevented by creating a directory /usr/tmp/sh. This confused the worm and prevented it from working.


• Sometimes the exploit requires some kind of user interaction. In that case you can warn the users to not do that. ("Do not open emails with the subject line ILOVEYOU")


• Sometimes the attack is easy to identify on the network, so you can block it with some more or less complicated firewall rule. The Conficker virus, for example, was targeting a vulnerability in the Windows Remote Procedure Call service. There was usually no reason for this feature to be accessible from outside the local network at all, so it was possible to protect a whole network by simply blocking outside requests to port 445 TCP.

But that's not always the case.

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.