[tor-relays] Handling abuse - like to get your help please

[Michael Armbruster]

On 2016-06-17 at 22:12, pa011 wrote:
> Thank you Michael, solving that obviously easy question :-)
> 
> So what was this "attac" then about, on which way, how can I see that ?
> 
> Nice weekend to all
> 
> Paul
> 
> 
> Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
>> On 2016-06-17 at 21:51, pa011 wrote:
>>> Thank you both !
>>>
>>> @ Michael: that’s exactly what I did so far and in the past
>>> @ Moritz:  I will try my best - yes it was an automated response with
>>> just an name in Germany and no IP given, that I could possibly block
>>>
>>> "HTTP/1.1 404 293..."  are these the ports the traffic went trough ?
>>>
>>
>> Hi,
>>
>> Glad to hear other people already helped you out with your first question :)
>>
>> To answer this one: No, this is just the HTTP version (so protocol and
>> version), the HTTP status code (404 for "Not Found"; file was not found
>> on the server) and the size of the message that was transmitted to the
>> client, 293 bytes in this case.
>>
>> Best Regards,
>> Michael Armbruster

Hi Paul,

assuming the default HTTP port, it was an attack to the port 80.
Furthermore, the cryptic looking signs (%XX, whereas X is 0-9 or A-F),
are url escaped characters. Unescaping them leads to something like this:

> /cgi-bin/php-cgi?-d+allow_url_include=on+-d+safe_mode=off+-
> d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-
> d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+-
> d+cgi.redirect_status_env=0+-n

(I only inserted line breaks, so it does look nicer. The url itself has
NO line breaks).

So the attacker accessed /cgi-bin/php-cgi on the webserver with some
arguments. Looking at those, we can see "allow_url_include=on" and
"safe_mode=off" etc.
So the attacker tried to modify the CGI servlet (the executable he tried
to access) via some url manipulation to deactivate various security
features.

Now to the other things per log entry.

At the beginning of each log entry, we have the IP address of the
"attacker" (your node in this case, you replaced it with x characters
for anonymity, that's good for this mailing list).

Secondly, we see the time when the access took place.

Then, we see the method of the request, in this case, its a POST. POST
means that we send additional data with our request to the server, while
GET does not do that (GET can only send data like the url manipulation
does, via the url, though of course, usually you submit important data
like the ID of an article you try to read on a news site).

Putting all those bits together, we can conclude that an attacker tried
to access the PHP executable on the CGI path on a webserver and
disabling various security features. The malicious code or data he tried
to send to the server was sent via POST data. Though we cannot see the
post data, so we can only speculate what the attacker tried to do. A
good bet would be to upload a shell to the webserver to gain further
access on the server, but that's only speculation.

I hope I could answer your question well enough :)

Best Regards,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160617/2863e039/attachment.sig>