Category Archives: linux

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

How I use autossh

autossh is nice little program that will auto restart ssh connections when they drop
This is extremely useful if you use ssh-tunnels a lot.

  • autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea is from rstunnel (Reliable SSH Tunnel), but implemented in C.
  • Connection monitoring using a loop of port forwardings or a remote echo service.
  • Backs off on rate of connection attempts when experiencing rapid failures such as connection refused.

I have my raspberrypi at home using autossh to do a remote port foward of ssh to my server.

 

To set this up I created an account on my server I just for tunneling.
User called tunnel with the shell set to /bin/false
On the rpi I generated ssh-keys (with no password)

Toss the public key into the tunnel account of the remote servers  ~/.ssh/authorized_keys

now test it with out auto ssh:

root@rpi:~# ssh -N -R 3333:localhost:22 tunnel@server
the -N is for no shell; the -R is forwarding the rpi’s ssh’d to your remote server on port 3333
now from the server you can do  ssh user@localhost -p 3333   and login :D

 

Now for autossh!
i use autossh in cron; not _sure_ if that’s how its meant to be used… but it works very nicely
as roots , crontab -e
*/1 * * * * autossh -M 20001 -R 3333:localhost:22 -N tunnel@server
this will check the tunnel every minute, and if its not up it will bring it up

 

 

Its like a lazy mans vpn! :D

SSH ranking update!

Firstly, links!:

http://vps2.pronto185.com/ssh_rank/lists/all
https://github.com/pronto/SSH-Ranking
also: follow me: https://github.com/pronto/ https://twitter.com/moo_pronto

Now for “wtf is all this?!”

Intro bit:
On linux boxes theres a file called /var/log/auth.log where all login attempts to the system are logged, and other things.
If you’ve ever run a linux box on the web with port 22 open you’ll know that it gets hit, and hit hard (especially so if your IP is in a well known ‘server range’ eg:linode.com)
Now most sane people will either just use fail2ban(or something similar) or change the ssh port.
But craycray people like myself like it when auth.log* gets filled up with these attempts for a fun dataset!
About the project:
This project mainly started as something to do using python, sql-alchemy, flask/jinja2 and other things.
What it does is parse though auth.log getting very failed login attempt and tosses it into a database.
then the web-part will query the DB and display interesting things, e.g: http://vps2.pronto185.com/ssh_rank/user/r00t  which IP’s have tried the user name ‘r00t’
Remember this project is still in the early phases, and could be unstable. I wouldn’t run this on production boxes. If you want to see data from production boxes, I recommend moving the auth.logs off to some test-server and telling the sshrank.py to parse those
Whats next?:
Going to start doing more digging into the top offenders. Doing port scans, keeping an rdns history for changes, grab the whois data to compare with other offenders.
Also thinking about logging the passwords for failed attempts, Eric Gragsone had an interesting idea on how to do that with pam

‘This is neat, i want this’ and ‘how can i help?’

Get it running?

The readme on github should help you get started. note: it was tested on debain7.2 so if you use something else, you might have to do things different
i have gotten it working on python 2.7 and 2.6.6

How I help?

All the code is on github, feel free to fork/etc… and if I like your changes, I’ll merge it into the main one.
If you don’t know how to use github, I high recommend learning how to use it you can find a lot of links here to figure it out :)

Talk to ….me?!

Best way is via: irc(pronto on: efnet,freenode,snoonet,and other nets…) email: pronto185@gmail.com, or google chat/hangouts

Python function to update a var in a list of tuple

As part of my new ssh-fail script, now written in python I found myself needing to update a var in a list of a list, but you can’t just do list_a[3][3]= ‘new thing’ :(

so i wrote this function:

def tuple_update(touple, varloc, newval):
    temp = []
    for a in range(len(tuple)):
        if varloc != a:
            temp.append(tuple[a])
        else:
            temp.append(newval)
    return temp

and you can use it like this:

>>>ip_test=[('8.8.8.8', 423, None, 0), ('4.2.2.2', 64, None, 3), ('42.42.42.42', 23, None, 10)]
 
>>> ip_test[1]
('4.2.2.2', 64, None, 3)
>>> ip_test[1]=tuple_update(ip_test[1],1,38)
>>> ip_test[1]
['4.2.2.2', 38, None, 3]
>>> ip_test[2]=tuple_update(ip_test[2],0,'100.100.2.3')
>>> ip_test[2]
['100.100.2.3', 23, None, 10]
>>> ip_test
[['9.9.9.9', 423, None, 0], ['4.2.2.2', 38, None, 3], ['100.100.2.3', 23, None, 10]]

that’s: tuple_update(list,location,newval)