Exploiting MySQL arbitrary file read: a honeypot that kicks | Hacker News Reader

Exploiting MySQL arbitrary file read: a honeypot that kicks

abclinuxu.cz

67 pointsmarbu20 comments

> Okay, so what to do with this when I don't want to do any harm? I have contacted abuse@ for the given addresses, but unsurprisingly received no reply.

shutdown -h now

OK this is is fun but can anyone describe a scenario where this is actually dangerous...?

From the very entertaining article: Summary A mysql exploit created in two hours can generate ~4 rootshells per month.

This is dangerous for anyone who connects to random MySQL databases with the default settings of most clients as it allows arbitrary file reads?

The segment at risk is almost exclusively black-hat, although maybe you could MiTM a connection....

My immediate thought is if an attacker gains control of your MySQL server they could use this to help propagate across the network (and of course grab arbitrary data from everything that connects).

No actual MySQL server is involved in this...

It would be interesting to see if the client will upload a file from an SMB share using the credentials the client is running under.

But I think the main scenario is where the MySQL server is compromised and the attacker wants to pivot to the client machine.

Retrieving the keys and other interesting bits under ~/.ssh might have a higher success rate, and no hash cracking needed.

my first thought is, no surprise this is being described by someone with a visibly non-American domain, as this would be a fairly textbook breach of CFAA, right?

My understanding (disclaimer, not a lawyer) would be yes this would be a violation. However the group of people who connect to random MySQL servers is going to be almost exclusively black-hat.

This would be akin to "But officer he stole my drugs", sure they committed a crime but in reporting it you implicated yourself.

The connection is initiated by someone who isn't authorized for your server. Don't see anything fraudulent in requesting a file they are free to ignore.

Consider how happy the district attorney will be if the "someone" in your scenario is a federal agent.

I eagerly await your entrapment defense argument.

They were breaking the law by trying to hack my computer with malicious SQL.

The FBI has not been yet been significantly deterred by courts:

https://www.wired.com/2016/05/history-fbis-hacking/

If they have a search warrant for your server and you hack back, you're liable to have a bad time.

I guess there some interesting technicalities in the phrase "your server" there.

You might _think_ that ec2 instance is "your server", but the FBI are unlikely to serve you with that warrant. I'd guess it'll go to Amazon, who may or may not care about whether you even know of its existence. (Especially if the warrant is for someone else with a VPS on the same piece of hardware that "your server" is on...)

You can say someone stole your bike so you broke into their house to steal it back, but it doesn't negate that you also committed a crime. I think law enforcement would probably be pretty unlikely to bother charging someone popping a few cybercriminals who stumbled across their honeypot, but they could charge you if they want to.

I'd be _reasonably_ comfortable doing just that.

Cracking passwords in that file and using those credentials to log in to someone else's box is a _loooooong_ way over the line though...

Tell that to weev. His case was only overturned on a technicality. His conviction was for enumerating an unsecured API by sending requests that the server was free to ignore.

https://www.washingtonpost.com/news/the-switch/wp/2014/04/11...

There is a technical difference here though.

weev was actively initiating that connection to somebody else's server. In this case, the honeypot is sitting idly, and _responding_ to someone else's connection (in a manner that's clearly unauthorised), and it's responding with something valid but unexpected.

Not that I'd want my lawyer having to explain that difference to a jury...

That part is fine. Actually trying out the passwords found in received files may however not be OK.

Reply on news.ycombinator.com