Dark Web Hosting Site Suffers Cyberattack, 7,600 Sites Down (zdnet.com) 48
It's the largest free web hosting provider for dark web services. But remember back in 2018 when its 6,500 sites all went down after attackers accessed its database and deleted all its accounts?
It happened again -- for the second time in 16 months. And this time, ZDNet reports, Daniel's Host won't be coming back online for several months: Almost 7,600 dark web portals have been taken offline following the hack, during which an attacker deleted the web hosting portal's entire database. This happened earlier this month, on March 10, at around 03:30 am UTC, according to a message posted on DH's now-defunct portal by Daniel Winzen, the German software developer behind the service.
Winzen said that an attacker accessed the DH backend and deleted all hosting-related databases. The attacker then deleted Winzen's database account and created a new one to use for future operations. Winzen discovered the hack the next morning, at which time most of the data was already lost.
The service doesn't keep backups by design.
In an email to ZDNet today, Winzen said he has yet to find out how the hacker breached the DH backend. However, since the dark web hosting service was more of a hobby, Winzen didn't look too much into it. "I am currently very busy with my day-to-day life and other projects, I decided to not spend too much time investigating," he told ZDNet...
Winzen said that users should consider the passwords for their DH accounts as "leaked" and change them if they used the same password for other accounts.
Winzen told ZDNet he still hopes to relaunch the service "at a later time" with "new features and improvements."
"Not having to administrate the services all the time will hopefully give me more time for actual development."
It happened again -- for the second time in 16 months. And this time, ZDNet reports, Daniel's Host won't be coming back online for several months: Almost 7,600 dark web portals have been taken offline following the hack, during which an attacker deleted the web hosting portal's entire database. This happened earlier this month, on March 10, at around 03:30 am UTC, according to a message posted on DH's now-defunct portal by Daniel Winzen, the German software developer behind the service.
Winzen said that an attacker accessed the DH backend and deleted all hosting-related databases. The attacker then deleted Winzen's database account and created a new one to use for future operations. Winzen discovered the hack the next morning, at which time most of the data was already lost.
The service doesn't keep backups by design.
In an email to ZDNet today, Winzen said he has yet to find out how the hacker breached the DH backend. However, since the dark web hosting service was more of a hobby, Winzen didn't look too much into it. "I am currently very busy with my day-to-day life and other projects, I decided to not spend too much time investigating," he told ZDNet...
Winzen said that users should consider the passwords for their DH accounts as "leaked" and change them if they used the same password for other accounts.
Winzen told ZDNet he still hopes to relaunch the service "at a later time" with "new features and improvements."
"Not having to administrate the services all the time will hopefully give me more time for actual development."
Dark web hosting (Score:2)
On the other hand, developers at a lot of companies make really bad decisions, so I shouldn't be surprised.
Re: Dark web hosting (Score:2)
Talks about really bad decisions...
Suggests AWS.
Why not host at the NSA right away??
Re: (Score:2)
Re: (Score:3)
All you need to host on AWS is a pre-paid credit card.
Yes, so? All public clouds get regularly scanned by the government and most certainly not only for actually illegal things. Finding who owns some host in a cloud is usually not that hard. Of course, they do not to want to admit that. But there are quite a few cases now, were incriminating data was found "by accident" and there were even cases were the accusations got dropped when the defense demanded to know the details how exactly it had been obtained. The picture is pretty clear.
Re: (Score:2)
Re: (Score:2)
Aehm, and how do you deliver that then? This is web-hosting, not storage, remember?
Re: (Score:2)
Re: (Score:2)
On any other web-hosting you do either not use encrypted storage or it gets decrypted transparently. In both cases, the hosting operator can see everything.
Re: (Score:2)
Re: (Score:2)
And that helps how?
Re: (Score:2)
Finally (Score:2)
Something good came out of hacking.
Does this fall under, "Hack the Gibson!"?
Re: Finally (Score:2)
You're falsely suggesting all "dark web" sites are harmful.
That's the kind of yes man attitude that breeds totalitarian terror states.
How about those that exist to protect *from* harm?
Like for Chinese who disagree with their government? Or Americans that suggest social behavior? Or organized rape victims afraid of their rapists that sit in powerful places? Or merely Wikileaks' TOR site?
All "dark web" sites that I have seen.
Re: (Score:2)
"Organized rape victims afraid of their rapists that sit in powerful places?" You're suggesting that these folks would use the dark web? What would they use it *for*? It's not much good for organizing a protest.
Now, "Chinese people who disagree with their government..." That I could see as being a legitimate use for the dark web, and I wonder if it is actually sometimes used for that.
Re: (Score:3)
So, you have a survey of what was actually hosted there? Or are you just full of it and think everything anonymous must inherently be bad? That would be pretty ignorant of actual reality.
Re: (Score:2)
“It’s the wild colour scheme that freaks me,” said Zaphod whose love affair with this ship had lasted almost three minutes into the flight, “Every time you try to operate on of these weird black controls that are labelled in black on a black background, a little black light lights up black to let you know you’ve done it. What is this? Some kind of galactic hyperhearse?”
Dark Web you say? (Score:2)
Whoops (Score:3)
"The service doesn't keep backups by design."
Well there's yer problem....
Re: (Score:3)
Yeah, that does seem a trifle sophomoric. He was already storing the information in a database, so why exactly is that all right while a backup Copy of that same database is verboten?
Re:Whoops (Score:4, Interesting)
I don't know what Winzen unspoken design parameters may have been.
But if I were responsible for hosting sites that required constant monitoring to prevent child porn, drug sales, bomb materials, or things like that, I would want to be able to instantly erase it all and say "whoops, hackers".
I suspect the possibility of some personal safety considerations.
Re: (Score:2)
This is of course correct. Also, his clients should also be able to hopefully (YMMV) wipe their own data with worrying about if he has it backed up offline on tape somewhere. If you want to back up your data - YOU do it. The operator in this case should absolutely not care, and I doubt he advertises backups as a feature.
Re: (Score:2)
Yeah, that does seem a trifle sophomoric. He was already storing the information in a database, so why exactly is that all right while a backup Copy of that same database is verboten?
My guess would be that any user can erase their data at any time and that takes effect immediately. The same effect can be achieved with a backup and public-key encryption though.
By design (Score:3)
>"The service doesn't keep backups by design."
Strange design. For their case, I can understand not wanting remote backups, time spans, or multiple backups. But an on-site, normally unmounted, single-snapshot, occasionally rsynced backup seems appropriate. I can't imagine ZERO protection from "rm -rf /" on any machine worth having.
Re: (Score:2)
It's up to the clients to keep backups. If he doesn't keep backups then he never has to respond to a subpoena request for same.
Re: (Score:3)
If the backups are encrypted so only the users can decrypt them, the situation is the same. And he still has to answer a subpoena for the life sites, so the difference to a short-term backup (say, 3 days or so) is pretty negligible.
Re: (Score:2)
>"The service doesn't keep backups by design."
Strange design. For their case, I can understand not wanting remote backups, time spans, or multiple backups. But an on-site, normally unmounted, single-snapshot, occasionally rsynced backup seems appropriate. I can't imagine ZERO protection from "rm -rf /" on any machine worth having.
That is what your shell configuration is for.
Re: (Score:2)
What you don't have, you can't produce in response to a subpoena.
Re: (Score:2)
Indeed. And, if paranoid, get every user a public/private key, encrypt the backup with the public key and have the private key in the care of the user only. That is not any less secure than not keeping backups, but a lot more reliable, since any user can still nuke their private key and effectively erase their part of the backup.
anbuew lepou papuadn (Score:1)
b.g (before god) (1985)
For the love of light, god beget sight
abracadabra
.bracadabra
. racadabra
.
.
. . adabra
. .
. . . abra
. . .
. . . . ra
. . . . a
He must have gotten bored (Score:1)
Re: He must have gotten bored (Score:1)
And human rights sites.
Disgustig! Unamerican! Unchinese! Unrussian! Unnorthkorean!
Re:He must have gotten bored (Score:5, Informative)
No backups = no service (Score:2)
"The service doesn't keep backups by design."
Others have commented on how easy it is to do backups. I'll leave that to them.
My thought:
If you don't have backups you're not providing a service. You're providing a hobby platform.
Service have backups, backup plans, redundancy, duplication, disaster recovery plans, and abilities to execute.
Obviously they thought it "better" not to have backups. Perhaps they couldn't afford it. Perhaps they didn't know how to encrypt backups so they're just as or even more s
Re: (Score:2)
Re: (Score:2)
P.S. Also while I'm mentioning it, if you don't do backups, DO BACKUPS, and if you do backups, RESTORE those backups elsewhere and test them. Any backup you haven't tested is just raw sewage bits.
I think a real file-level compare is usually enough (I have found several weak memory bits with that and one failing SATA controller), but overall, I fully agree.
The service didn't keep backups, but... (Score:2)
Let's hope the hacker made one before deleting the database. Once it gets posted on Wikileaks, a lot of ransomware kingpins and child porn traders are going to get nailed. And if he sells all the Bitcoin at once, that will solve another annoyance.
Sounds incompetent to me (Score:2)
Sure, not keeping long-term backups comes with the territory, but a daily short-term backup, kept, say, for 3 days or so would not have compromised security or privacy significantly, and would have saved the whole thing. It could even be done in such a way that each users has a private encryption key for their own backup and restoration is only possible with that. Then each user could still destroy their own backup at any time, but disaster recovery becomes feasible. Putting all your eggs in one basket is t
I think the basic question is (Score:2)
which government caused this to happen?
Passwords are leaked? What? (Score:2)
Winzen said that users should consider the passwords for their DH accounts as "leaked" and change them if they used the same password for other accounts.
That's now how you store passwords. Proper password storage means it's just about impossible to retrieve them.
Just ask LastPass.
Re: (Score:2)
That's *not how you store passwords. They're hashed or they're used to encrypt a known string on the server.