Hacker News Reader

Comment by lilboiluvr69 | Hacker News Reader

Interesting article, but I don't see why it's titled '0-day' when he references a research paper from 2012.

"Although these are old, they are classified as zero-day attacks because there is no solution."

They are?

This is the same person who had a blog post on the front page ~2 months back, rambling about a JavaScript scroll bar issue, the fact that an ISP could block entry node traffic, and a few other things along those lines ("omg, 0 day!"):

https://news.ycombinator.com/item?id=23929312

Both blog posts probably ended up on the front page and got quite a bit of attention because the words "0 day" and "tor" were used in close proximity, something the author is apparently very fond of doing (the posts are part of a series titled "Tor 0day").

This guy is a bit crazy https://news.ycombinator.com/item?id=18523549

I even remember you wrote that. I come here too often.

Here is a technique that is used to uncover hidden services:

1. purchase VPS products at a bunch of providers who accept bitcoin / crypto

2. ddos your target

3. see if you notice any of your hosted boxes go down

4. once you know the provider pop them (they're usually running some shitty WHMCS or similar homebrew solution, old Cpanel, etc. etc. and they're almost always resellers and amateurs) and move laterally to your target

When the feds do it against online drug markets (and they have been for years) they have the bonus of having decent network insight / view by working with backbone providers

There is just no way to hide multi-Gb of traffic

That's why you split your drug empire into a server for images and static stuff, and another server to run the rest. The server for the rest can be proxied through the image server, and through another tor connection. That way the feds only find your image server...

And perhaps throw some needles of steganography into the haystack.

Most of them do that now - the better markets have gateways that are CAPTCHA'd and spread out over other providers that then proxy to the real hidden service (you can do this with a second step over Tor again)

Checkout this project which is now being more widely deployed to prevent a lot of these attacks:

https://github.com/onionltd/EndGame

Pretty cool, but you'd think they would just have a Dockerimage ready to be deployed and a network driver or something similar for these types of challenges.

Hope this password advice isn't taken seriously

> TORAUTHPASSWORD - Password which is used for your Tor Control Port Authentication with NGINX. Alphanumeric without spaces (example: passwordIcanremembertyping)

> KEY - Alphanumeric Key for the shared front session key. Random between 64-128 would do fine. (example: isthis64charactorsalreadyicantbelieveitwowsocoolwaitnotyetohdarn)

Very cool. I clicked a bunch of links from there and got to here: https://github.com/mikeperry-tor/vanguards/blob/master/READM...

Good overview of threats.

Are you really saying that feds DDoS hosting providers and actively hack control panels for lateral access? More than once? Have you got any documented cases of this happening? Because it really sounds... Unlikely.

Hitting a hosting provider (indirectly) with a ddos for a few minutes doesn't sound that difficult to do, and could easily pass as a routing glitch or something like that. If it's the only way to track down the server it seems reasonable that it would get a rubber stamp approval. After all, who's going to be able to prove the feds did it?

You too have the capability to do it - should we some it's you? I din't disagree it's viable. Just that the parent said "when feds do it", that's a big leap from "it's possible". How do you know feds do it?

> and actively hack control panels for lateral access

I would definitely see this under the umbrella of various secret agencies, especially those with an "offensive" position in cyber-warfare.

You won't ever see any of this documented due to the "parallel construction" method. And for what it's worth, almost all of the Wikipedia content on that one (https://en.wikipedia.org/wiki/Parallel_construction) deals with DEA usage of this.

Besides, the general way of "hacking services to distribute malware" has already been done, most famously in 2013 when the feds burned a Firefox 0-day to unmask a child porn ring: https://krebsonsecurity.com/2013/08/firefox-zero-day-used-in...

Why not? They're not above sending literal malware to people's computers in order to compromise them:

https://en.wikipedia.org/wiki/Network_Investigative_Techniqu...

https://www.eff.org/pages/playpen-cases-frequently-asked-que...

A DoS attack is nothing to these people. The only difference between them and cybercriminals is the fact the law legitimizes their work.

That's not a documented case of DDoSing a company to get location.

They're examples of a US federal agency using malware to compromise the computer systems of suspects and collect evidence to use against them. If they're willing to exploit vulnerabilities in order to break into computers, surely they won't balk at denial of service attacks. They even let the suspect go free in order to avoid revealing the vulnerability they exploited.

They are not. Zero counts from the time the vulnerability is disclosed, not when it's fixed. This is not a "zero day" vulnerability.

So if 10 years passed and this can still be exploited using tactics discussed a decade ago, how to classify this?

You classify it as a threat that is outside the threat model that tor can defend against.

Tor is a tool like any other. It has certain strengths and certain weaknesses. When you're evaluating any security product you always have to determine if the security properties the tool provides match up with the security properties you need. Tor is no different.

it's a "known issue" maybe it should be mentioned in the documents with more clarity. it seems the author of this post stumbled over what is well known to many people and then went on a diatribe. looks like he hit a nerve so maybe it's really an issue with documentation. on the other hand people should learn about how to think via threat models. not sure if the tor project should be expected to cover every hypothetical scenario, and if they did would people study it?

A whole set of mitigations were published on Tor Project's blog in 2018.

https://blog.torproject.org/announcing-vanguards-add-onion-s...

As a PhD student my main topic was the period of time just after the disclosure of a vulnerability. This is the most threatening stage of its life cycle as mitigations are not disseminated in the community yet (a patch may be available but nobody installed it yet, etc.).

We struggled to find a commonly accepted term for vulnerabilities at this stage of their life cycle, but we finally settled on n-day vulnerability. This term have been relatively well accepted by the vulnerability research community.

The exact length of this period is completely dependent on the velocity of the community to adopt a mitigation such as a patch. Heartbleed and Shellshock had been massively mitigated in a matter of days or weeks, but EternalBlue based-attacks still caught a lot of production systems off-guard more than a year after its disclosure.

For what it's worth, until the widespread dissemination of auto-updaters, into the mid-late 2000's, you were describing most vulnerabilities. Most things stayed highly exploitable for a very long time. We didn't have a special name for them.

I see a consistent definition for the arguments of others: "You have zero days until this can and will be exploited. You have zero days until you need this patched."

A zero day starts with it's exploit or public disclosure and ends with a released patch. It's not a zero day for private disclosure.

Edited based on child comment about clarity

For clarity: "private disclosure", even to the vendor, doesn't mean anything. At the point a vulnerability is publicly disclosed, patch or no patch, users can mitigate it (if only by ceasing their use of the affected software). "Zero" refers to the interval elapsed since the public, meaningful, disclosure of the vulnerability.

If I find an RCE in Cisco IOS and report it Cisco, who sits on it for a few dozen months, and you later find the same RCE and circulate it amongst your friends, who exploit it, your friends are exploiting a zero-day vulnerability.

So back a long time ago, we counted days from the time an exploit was 'known'. Now people seem to use it for the time since a patch has been released? I don't know, but every time I ask I get downvoted.

A 0-day generally means either one person, a single organization, or a small group of people, know about the exploit in question. As soon as an exploit is widely known or published, it's not a 0-day since anyone can find it, even if the exploit is for abandoned software that'll never receive a security fix.

Yep, that's what I said I think (by 'known' I meant publicly). Once it's widely known, it's a 0 day for 24 hours, then it's not anymore. That's what we used to mean by 0-day anyway. Other people will tell you that it's a 0-day until there is a patch against it. I think different people use this this phrase so divergently that using it isn't a useful way to communicate anymore.

What is it called after there is a patch against it? Does it just stay at like a 27-day if it takes 27 days to patch?

I feel like in common parlance calling something a 0-day would imply that it is something the manufacturer didn't expect and has no solution for which is a big problem. I guess whatever communicates information best. I kind of feel like we just use 0-day to mean big problems, everything else is just a bug that has some age, and then fixed stuff doesn't get remembered. Right?

That seems fairly useful, at least in communicating to the general tech media.

If you know about the bug, but manufacturer does not provide any patches, you can still mitigate it, put in place detection measures or just stop using that software. You can't (necessarily) do those if you don't even know about the bug yet as it hasn't been published. That's why 0day is a useful term.

Not "known", but "disclosed" to the public, or at least those responsible for a patch.

Zero days are known, exploited and used all the time by all sorts of black hats, govt institutions etc.

At this point bloggers seem to mostly use 0-day to mean: i havez cool 1337 hackorz skillz, regardless of merit.

I've always understood it to mean : time/version since the software is vulnerable. 0 day ,from first release of the software, meaning all versions are vulnerable.

Which was/is more relevant when commercial software is updated at most once ever year or two

But it appears no one can agree anymore, making the term useless.

Hold the line! Let's make the term useful. An 0-day is an 0-day before public disclosure and for 24 hours after.

At one point in history a "0day" referred to a pirated release of software on/before it hit the shelves (and/or the crack that was released simultaneous to protected software aka "warez").

It was years later that a "0day" went from a copy protection removal/crack ("0day warez") to its more general modern usage in computer security.

See: https://www.google.com/books/edition/_/8ETRQhDytIsC?hl=en&gb...

Got us reading so that's good

It started out as a 0-day in 2012, and since it has remained unpatched, it continues to be called a 0-day. That is how it is commonly used.

No, that's not how the term is used.

Known vulnerabilities or weaknesses that don’t have patches are not 0-days. A 0-day is a vulnerability that you don’t know exists yet. That’s how the term is used in risk management and threat modelling. You don’t have 0-days that you’ve known about for 8 years. They’re just known risks.

Disagree. An 0-day is only a 0-day for 1 day after public disclosure. (and before)

It's a useful distinction. 0-days are special because your target has no idea such a vulnerability even exists. This makes them very different than known but still unpatched vulnerabilities.

How does that make them very different? The latest version of the software is still exploitable in either case. In my opinion, that is why it's useful to call them 0-days until they are patched.

One difference: With an 0-day you know your target can't have done anything to specifically mitigate that vulnerability. If a vulnerability is well known but still unpatched by the vendor, a potential target can take their own steps to protect themselves.

For example, if you're running some ancient mailing list software that you know has an unpatched XSS vulnerability, you can have your front end servers scan for attempts to exploit that and abort the requests. Or lock it down with a CSP policy. Or if you know your image manipulation library has tons of vulnerabilities, you could run it in a locked-down sandboxed environment where exploitation doesn't get the attacker much of anything.

This is simply absurd. Please stop things making up.

Reply on news.ycombinator.com