Transport layer protocols for stealth and evil

Ever tested some of the more exotic transport protocols?

SCTP is interesting ... multihoming means you can have several ips involved on each side of a connection (association in sctp speak) ... so when you move from wired to wireless your ssh session still is fine. If you find a proper SCTP ssh, of course.

Testing it on Ubuntu LTS, though, using socat for glue... a listening SCTP socket is invisible in netstat -ln. Fun. tcp, udp, raw sockets are visible ... but sctp isn't.

socat SCTP-LISTEN:8080,fork TCP-CONNECT:localhost:22

Nice, stealthy backdoor. Does not show in netstat(8) or ss(8). Combine with socat TCP-LISTEN:2223 SCTP-CONNECT:localhost:8080 on a remote host and we have a completely stealthy tunnel, if the firewall is mildly clue-challenged.

knan@ip:~$ netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp        0      0 0.0.0.0:36558           0.0.0.0:*                          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp        0      0 0.0.0.0:631             0.0.0.0:*                          
udp        0      0 0.0.0.0:45561           0.0.0.0:*                          
knan@ip:~$ 

lsof reports a mysterious socket. But it also does that for udev and update-manager, so that's hardly conclusive.

knan@ip:~$ lsof | grep socat | grep sock
socat 24969 knan 3u sock 0,6 0t0 645716 can't identify protocol

The only place I've dug out useful info so far is from procfs.

knan@ip:~$ cat /proc/net/sctp/eps 
 ENDPT     SOCK   STY SST HBKT LPORT   UID INODE LADDRS
ffff8800722cb800 ffff8800342c8480 2   10  16   8080   1001 645716 0.0.0.0 

Hardly easy to read. But it says LADDRS 0.0.0.0, LPORT 8080. Ok.

(BTW: SCTP not being in netstat is a Debian/Ubuntu-specific bug, SuSE/Red Hat have applied patches.)

sctp_darn(1) can do more fun sctp-specific stuff, like setting up multiple local and remote addresses for the association.

Cool enough. But there are other fun transport protocols we can try.

How about DCCP? It's connection-oriented and has congestion control but otherwise is UDP-like.

netsend dccp receive

knan@ip:~$ netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 ::1:631                 :::*                    LISTEN     
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp        0      0 0.0.0.0:36558           0.0.0.0:*                          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp        0      0 0.0.0.0:631             0.0.0.0:*                          
udp        0      0 0.0.0.0:45561           0.0.0.0:*

Netstat still says nothing.

The only place in /proc/net you find DCCP mentioned is in /proc/net/protocols. Which says nothing about ongoing connections or listening sockets.

knan@ip:~$ grep -ir DCCP /proc/net/
/proc/net/protocols:DCCP 1400 1 -1 NI 1196 yes dccp_ipv4 y y y y y y y y y y y y n n y y y y n


lsof still says little.
knan@ip:~$ lsof | grep netsend | grep sock
netsend 25376 knan 3u sock 0,6 0t0 658124 can't identify protocol

ss(8) to the rescue! But only when you specifically ask it about DCCP sockets with -d.

knan@ip:~$ ss -ldn
Recv-Q Send-Q                              Local Address:Port                                Peer Address:Port 
0      0                                               *:6666                                           *:*     

The final protocol I want to propose today is UDP-Lite. This is basically a UDP variant with partial checksums, for the case when garbled data is better than no data.

$ netsend udplite receive

As usual, netstat tells us nothing of this uncommon activity.

knan@ip:~$ netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 ::1:631                 :::*                    LISTEN     
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp        0      0 0.0.0.0:36558           0.0.0.0:*                          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp        0      0 0.0.0.0:631             0.0.0.0:*                          
udp        0      0 0.0.0.0:45561           0.0.0.0:*                          

This time, though, lsof identifies it!

knan@ip:~$ lsof | grep netsend
netsend 25461 knan 3u IPv4 661633 0t0 UDPLITE *:6666

Which is good, since ss doesn't.

To summarize (for Ubuntu 10.04 LTS):

Protocol	netstat(8)	ss(8)	lsof(8)	/proc/net/*
SCTP	No	No	No	/proc/net/sctp/eps /proc/net/sctp6/eps
DCCP	No	Yes (-d)	No	No
UDP-Lite	No	No	Yes	/proc/net/udplite /proc/net/udplite6

Hope this leaves you entertained by the possibilities. Black hats begone!

P.S.
launchpad:netstat+sctp
launchpad:lsof+sctp
launchpad:lsof+dccp

sed for dns hackers

(Requires gnu sed)

Moving to a new set of nameservers is a bit like moving house. Lots of stuff thrown away for reasons of unreasonable antiquity, lots of stuff could do with a refresh and cleanup.

sed -i.bak '/\(NS\|SOA\)/ s/\bdns1\.example\.org/innerdns1.example.org/g; /\(NS\|SOA\)/ s/\bdns2\.example\.org/innerdns2.example.org/g' master/*

This simple, pretty oneliner fixes NS and SOA records to point to new addresses, and leaves other records alone - unless you have really unfortunate and awkward capital-letter names in your zones. Add some more \b safeguards if so.

Japanese WHOIS fun

Recently, I wanted to look up info on a Japanese domain name. Being a command-line type of guy, I obviously did $ whois ac.jp and expected things to work out.

Well, things were a bit less helpful than I'd hoped.

$ whois ac.jp
Domain Information: [%I%a%$%s>pJs]
a. [%I%a%$%sL>]                 AC.JP
e. [$=$7$-$a$$]
f. [AH?%L>]                     3X=Q%I%a%$%s
g. [Organization]               Academic Domain
k. [AH?%<oJL]
l. [Organization Type]
m. [EPO?C4Ev<T]
n. [5;=QO"MmC4Ev<T]
p. [%M!<%`%5!<%P]               a.dns.jp
p. [%M!<%`%5!<%P]               b.dns.jp
p. [%M!<%`%5!<%P]               c.dns.jp
p. [%M!<%`%5!<%P]               d.dns.jp
p. [%M!<%`%5!<%P]               e.dns.jp
p. [%M!<%`%5!<%P]               f.dns.jp
p. [%M!<%`%5!<%P]               g.dns.jp
[>uBV]                          Reserved
[EPO?G/7nF|]
[@\B3G/7nF|]
[:G=*99?7]                      2005/03/30 17:37:52 (JST)

While I can figure out what I need here, why the garble? This is 2010 and I'm running in a UTF-8 locale with proper fonts; I should see hiragana/katakana/kanji just fine.

So I looked up the current WHOIS protocol. That's probably the shortest RFC I've ever seen.

The interesting bit: "The WHOIS protocol has no mechanism for indicating the character set in use." ... rrrright. Obviously not UTF-8 on this server.

Some trial and error, then.

$ whois ac.jp > gnark.txt
$ file gnark.txt
gnark.txt: ASCII English text, with escape sequences

Oh thank you. Very helpful. (irritated hacking ensues)

End product (bash function):

function jwhois { whois "$@" | iconv -f iso-2022-jp ; }

$ jwhois ac.jp
Domain Information: [ドメイン情報]
a. [ドメイン名]                 AC.JP
e. [そしきめい]
f. [組織名]                   学術ドメイン
g. [Organization]            Academic Domain
k. [組織種別]
l. [Organization Type]
m. [登録担当者]
n. [技術連絡担当者]
p. [ネームサーバ]              a.dns.jp
p. [ネームサーバ]              b.dns.jp
p. [ネームサーバ]              c.dns.jp
p. [ネームサーバ]              d.dns.jp
p. [ネームサーバ]              e.dns.jp
p. [ネームサーバ]              f.dns.jp
p. [ネームサーバ]              g.dns.jp
[状態]                        Reserved
[登録年月日]
[接続年月日]
[最終更新]                     2005/03/30 17:37:52 (JST)

Looks better, yes?

P.S. This was written using FreeBSD whois. Ubuntu whois acts completely differently - specifically asks for and shows English information in English locales, and breaks interestingly in the Japanese locales I've tested.

Wine on Windows...

The Wine project is preparing the long-awaited 1.2 release for the end of the month.

Stuff like this should help morale:

Gothic I & II not working on Windows 7

Working around a longstanding d3d driver bug by instead running via crosscompiled d3d8+wined3d on OpenGL on Windows. :)

Fun hardware - first results

Testing the Fusion-io ioXtreme 80GB (/dev/fioa) vs Intel X25-M gen 2 160G (/dev/sda). The non-directio dd went cpu-limited for some reason, needs looking into.

792 MB/s read speed at 12% cpu use in the directio case looks a bit promising :)

# dd if=/dev/fioa2 of=/dev/null bs=1M
26723+1 records in
26723+1 records out
28021615104 bytes (28 GB) copied, 201.797 s, 139 MB/s
# dd if=/dev/fioa2 of=/dev/null bs=1M iflag=direct
19792+0 records in
19791+0 records out
20752367616 bytes (21 GB) copied, 26.2142 s, 792 MB/s

# dd if=/dev/sda4 of=/dev/null bs=1M
5157+0 records in
5156+0 records out
5406457856 bytes (5.4 GB) copied, 25.136 s, 215 MB/s
# dd if=/dev/sda4 of=/dev/null bs=1M iflag=direct
6040+0 records in
6039+0 records out
6332350464 bytes (6.3 GB) copied, 26.1701 s, 242 MB/s

Stay tuned, more to come...

Fedora kernel on Ubuntu Lucid 10.04

I had need of a Fedora Core 12 kernel lately. Testing the fun hardware of the previous post.

Turns out that running that kernel with Ubuntu 10.04 userspace is pretty easy. Alien + some dkms invocations are enough.

fakeroot alien kernel-2.6.31.5-127.fc12.x86_64.rpm
fakeroot alien kernel-devel-2.6.31.5-127.fc12.x86_64.rpm

dpkg -i kernel_2.6.31.5-128_amd64.deb
dpkg -i kernel-devel_2.6.31.5-128_amd64.deb

update-initramfs -c -k 2.6.31.5-127.fc12.x86_64

dkms build -m nvidia-current -v 195.36.15 -k 2.6.31.5-127.fc12.x86_64
dkms install -m nvidia-current -v 195.36.15 -k 2.6.31.5-127.fc12.x86_64

update-initramfs -u -k 2.6.31.5-127.fc12.x86_64

update-grub

et voila:

knan@sarevok:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid
knan@sarevok:~$ uname -a
Linux sarevok 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 GNU/Linux

Tease

Now, if only I had the rest of the New! Shiny! computer handy, this would be a very fun weekend... as is, I'll just have to tease and promise benchmarks & impressions in a few weeks' time.

Buona sera!

htrosbif gets better

Alpha 4 is out now.

More signatures, more tests, and even bugs fixed. Imagine.

Git repo: git clone http://anduin.net/~knan/htrosbif.git/

Perl trick-of-the-day - $USER-local modules

Ever been frustrated by CPAN and scared to upgrade modules as root? Been burned by a perl rpm/deb upgrade overwriting your carefully upgraded modules?

Jon Allen brings us the light in a nice, short revelation. And a perl module. Of course.

Install/upgrade local perl modules in a user homedir, with basically no extra effort. Brilliant.