Category Archives: netsec

ProTip: Useful things from @SwiftOnSecurity

Some useful reference things; mostly from @SwiftOnSecurity
(i’l be updating this with more things)

odd scapy issue (with work around!)

with scapy i was trying to do a traceroute:

traceroute(["www.example.com","pronto185.com"],maxttl=20)

and was getting this annoying error (…not sure why)

Traceback (most recent call last):
  File "", line 1, in 
  File "scapy/layers/inet.py", line 1294, in traceroute
    timeout=timeout, filter=filter, verbose=verbose, **kargs)
  File "scapy/sendrecv.py", line 309, in sr
    s = conf.L3socket(filter=filter, iface=iface, nofilter=nofilter)
  File "scapy/arch/linux.py", line 316, in __init__
    attach_filter(self.ins, filter)
  File "scapy/arch/linux.py", line 132, in attach_filter
    s.setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, bpfh)
  File "", line 1, in setsockopt
socket.error: [Errno 22] Invalid argument

so i ran same thing with ipython (gives better error output)
and it showed this

/usr/lib/python2.7/socket.pyc in meth(name, self, *args)
    222 
    223 def meth(name,self,*args):
--> 224     return getattr(self._sock,name)(*args)
    225 
    226 for _m in _socketmethods:

so on line 223 for def meth(), i edited it: /usr/lib/python2.7/socket.py

def meth(name,self,*args):                                                     
    try:
        return getattr(self._sock,name)(*args)
    except:
        return 'wat'

and this seems to of fixed it! :D

>>> traceroute(["www.example.com","pronto185.com"],maxttl=20)
Begin emission:
.........*....*......*...*...*.....*......*.............*........*.......*....*......*.....*............**...........*...*........*.............**...........*.*............**................**............*.*...........*..*...........*..*.........*..*..........*.*....Finished to send 40 packets.
........*............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Received 928 packets, got 37 answers, remaining 3 packets
   208.100.54.15:tcp80 93.184.216.119:tcp80 
1  207.99.1.13     11  207.99.1.13     11   
2  207.99.53.41    11  207.99.53.41    11   
3  209.123.10.117  11  209.123.10.26   11   
4  -                   107.6.71.209    11   
5  -                   107.6.84.209    11   
6  154.54.6.226    11  208.122.44.201  11   
7  154.54.43.101   11  93.184.216.119  SA   
8  154.54.6.190    11  93.184.216.119  SA   
9  154.54.41.202   11  93.184.216.119  SA   
10 -                   93.184.216.119  SA   
11 154.54.1.210    11  93.184.216.119  SA   
12 38.104.103.238  11  93.184.216.119  SA   
13 208.100.32.78   11  93.184.216.119  SA   
14 208.100.54.15   SA  93.184.216.119  SA   
15 208.100.54.15   SA  93.184.216.119  SA   
16 208.100.54.15   SA  93.184.216.119  SA   
17 208.100.54.15   SA  93.184.216.119  SA   
18 208.100.54.15   SA  93.184.216.119  SA   
19 208.100.54.15   SA  93.184.216.119  SA   

Slightly interesting find from sshranking

Found something somewhat interesting via my ssh-ranking project
for the IP 218.28.116.247   (info page | mirror )
So when I notice the attacker has some http server going, I like to take a screenshot of said server.
this IP got:
218.28.116.247--1394113763So I downloaded those files, and ran file on them:

1:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
2:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
3:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
4:      C source, ASCII text, with CRLF line terminators
5.out:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x5e73ee3d92c18d1fb20e666626500eb580f0be39, not stripped
DDos:   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x3e423c19e481cf3b53b66fa8fd9857338565206a, stripped
DDos64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x2a987952391f567270d8c656b68613f38b00cc5c, not stripped

So yay, looks like I found some server that’s set up to host stuff for botnets:
Lets start with that C source code: (view it here)

 The comment on the c code is: /*
* jessica_biel_naked_in_my_bed.c
*
* Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura.
* Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca.
* Stejnak je to stare jak cyp a aj jakesyk rozbite.
*
* Linux vmsplice Local Root Exploit
* By qaaz
*
* Linux 2.6.17 - 2.6.24.1
*
* This is quite old code and I had to rewrite it to even compile.
* It should work well, but I don't remeber original intent of all
* the code, so I'm not 100% sure about it. You've been warned ;)
* 
* -static -Wno-format  
*/

the first part is in Slovak: (google translate)
* Doval of Knajpa and stare from Wojtas again has nothing to do, kura.
* Gizdi, mate cosyk Here you will find the edge, while a Flow and blabbed.
* Anyway this is old as well as CYP jakesyk crack.

So it’s a rather old linux exploit.  So this is most likely post-exploitation stuff (eg attacker already has user-level shell on a out of date linux box and will use this to get root)

lets take a look at the executables. I’m going to use my awesome reverse engineering skills here (aka, lets run strings on it)

  1. Starting with the file named ‘1’ (view the strings output here)
    • This binary is one for trying to get root from user privs
  2. binary: 2 (strings output)
  3. binary: 3 (strings output)
    • Looks to be similar to binary 2 bet with some ‘l33tsp3ak’ added, and other things
    • “3v3ryth3ng f41l3d!!*@&^@&*^ () * try an0th3r 0d4y L0l”   –> “Everything failed ….. try another 0day lol”
  4. binary: 5.out (strings output)
    • from google’ing looks like yet another linux 0day
  5. binary: DDos·(strings output)
    • From the name, I’m going to assume this is for running DDos attacks once the attacker has root
    • Found domain in the strings though: jeck.f3322.org   (which goes to the same server)  I’ll talk more about this later.
  6. binary: DDos64
    • same thing as DDos; just compiled for 64bit

So lets take a look more at that domain name, and the IP

% nslookup jeck.f3322.org
Non-authoritative answer:
Name:   jeck.f3322.org
Address: 218.28.116.247

% nslookup 218.28.116.247
Non-authoritative answer:
247.116.28.218.in-addr.arpa     name = pc0.zz.ha.cn.

Authoritative answers can be found from:
28.218.in-addr.arpa     nameserver = ns.hazzptt.net.cn.
28.218.in-addr.arpa     nameserver = ns.halyptt.net.cn.

% nslookup pc0.zz.ha.cn
** server can't find pc0.zz.ha.cn: NXDOMAIN

so none of that matches up at all…  and by the time i got back to writing this things went down; anyways…

I also found another very similar Server: 122.226.102.99

info page | mirror

122.226.102.99--1394556350

1:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
3:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
4:     C source, ASCII text, with CRLF line terminators
5.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0x5e73ee3d92c18d1fb20e666626500eb580f0be39, not stripped
txma:  ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

So the files seem to be similar:

  1. File ‘1’: an md5sum shows its the same file from the first IP
     md5sum */1
    a3e718751e600c4e8503ac6836b84aba  122.226.102.99/1
    a3e718751e600c4e8503ac6836b84aba  218.28.116.247/1
  2. file ‘2’
        again, same file
    $ md5sum */2
    e62089b51f3b485b891359accdb11bdc  122.226.102.99/2
    e62089b51f3b485b891359accdb11bdc  218.28.116.247/2
  3. file ‘3’
        again, same file
    $ md5sum */3
    585be83c1ee0ad009379369717ba988c  122.226.102.99/3
    585be83c1ee0ad009379369717ba988c  218.28.116.247/3
  4. file ‘4’
        again, same file
    $  md5sum */4
    9a501b92f3cf548ba13478f1b5855c68  122.226.102.99/4
    9a501b92f3cf548ba13478f1b5855c68  218.28.116.247/4
  5. file ‘5.out’
        again, same file
    $ md5sum */5.out
    ff1e9d1fc459dd83333fd94dbe36229a  122.226.102.99/5.out
    ff1e9d1fc459dd83333fd94dbe36229a  218.28.116.247/5.out
  6. New File: ‘txma’ ‘txma: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped’
    • strings output
    • basically all gibberish because of This file is packed with the UPX executable packer
    • im sure someone could ‘unpack it’ chances are its similar to one of the other binaries

     

link to all the binary: (warning: its obv malware, don’t be running whats in this unless you know what you’re doing)

 

Soon to follow: another server with the same HttpFileServer, but way different files. Also another with files via anonymous ftp