
Exploiting MySQL arbitrary file read: a honeypot that kicks - marbu
http://www.abclinuxu.cz/blog/jenda/2019/2/exploiting-mysql-arbitrary-file-read-a-honeypot-that-kicks
======
d33
> 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

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

~~~
larkeith
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).

~~~
tyingq
No actual MySQL server is involved in this...

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

------
roywiggins
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?

~~~
kevin_thibedeau
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.

~~~
roywiggins
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...](https://www.washingtonpost.com/news/the-
switch/wp/2014/04/11/hackertroll-weev-will-walk-free-but-the-court-didnt-rule-
on-the-main-issue/)

~~~
bigiain
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...

