E
D
C
B
A
9
8
7
6
5
4
3
2
1
0
Agenda
Motivations
E
D Types of Attacks
C
B
A IOS architecture
9
8 Detection of Attacks
7
6
5
Challenges with IOS
4
3 Methods of overcoming some issues
2
1
0
IOS shellcode
Introducing the Black-Hat-O-Meter
Why Cisco?
This talk is Cisco centric
E 92% market share* for routers above $1,500
D
C 71% market share* enterprise switch market
B
A This talk is access layer equipment centric
9
8 Small boxes, PowerPC based
7
6 What about Juniper?
5
4 From both attacker and forensics point of view, Juniper routers
3 are just FreeBSD
2
1 What about
0
From both attacker and forensics point of view, they are just
embedded Linux systems
*Source: stolen randomly
Who would hack routers?
E
D
C
B ARP games
A blocked by
9 the switch.
8
7
6
BBI
5 (The Big Bad Internet)
Switch
4 „Behind“ the
3 separates
Firewall
2 Hosts
1
0
Neighbor
systems have
local firewalls.
Who would hack routers?
E
D
C
B
A
9
8
7
6
BBI
5 (The Big Bad Internet)
4
3
2
1 Separation broken (ARP tricks are transparent now)
0
Modification of any traffic
Hard to recognize from the host
There just is no Reverse-NAC.
Who would hack routers?
E
D
C
B
A
9
8
7
6
BBI
5 (The Big Bad Internet)
4
3
2
1
Control over the entire network
0
Impersonation of the network against
the Internet
And on a larger scale...
E
D
C
B
The Internet
A
9
8
7
6
5
(OK, maybe this is too large)
4
3
2
1
0
Inter-Network Security
Network Firewall,
E IDS, IPS
D
C EIGRP 3
EIGRP 2
B
A Ingress & Egress
9 Filtering,
8 anti-spoofing,
7 route redistribution OSPF
6
5
4
3
2 Full Trust
1 EIGRP 1
within the EIGRP 4
0
autonomous
system
Network Security
Network security is hierarchical
E
D Defending against your downstream is common
C
B Defending against your upstream is rather hard
A
9 Defending against your peers is rare
8
7
6
Control anything in the hierarchy and you control
5
4
everything below
3
2
1
0
Hierarchical Compromises
(_x_)
E
D Local network
C EIGRP 3 compromise
EIGRP 2
B
A
9
8
7 OSPF
6
5
4
3
2
1 EIGRP 1
0 EIGRP 4
Hierarchical Compromises
(_x_)
E
D Just another
C EIGRP 3
B EIGRP 2 router
A
9
8
7 OSPF
6
5
4
3
2
1 EIGRP 1
0 EIGRP 4
But we got
Secure protocols can guarantee that nobody
E
D …modified the protocol messages
C
B …spoofed the communication peer
A
9 …replayed the protocol messages
8
7
6
But if someone did exactly that, they cannot do
5
4
anything about it.
3 The choice is: Availability or Security
2
1
0
What would your boss / mom do?
But we got
E (_x_)
D
C EIGRP 3
If the user could
EIGRP 2
B control the path his
A communication is
9
8 using, it would be
7 OSPF called „source routing“
6 and there is a reason
5
this is no longer in use
4
3 anywhere in the
2 Internet: The user
1 EIGRP 1 would have power over
0 EIGRP 4
the network.
All this is by design
E
D
C
In IP networks
B
A
The network node makes the forwarding decisions
9
8
The leaf node cannot control the traffic flow
7
6
5
4
3
2
1
0
Attacker Motivation
Windows and UNIX become harder targets
E
D IOS boxes are going to be around for some time
C
B We don’t see a new IOS for all the metal out there
A
9
8 IOS attack surface increases constantly
7
6 12.4 enterprise default feature set runs out of the box
5
4
a full Voice-XML IVM
3 New protocols constantly “invented”
2
1
0 Backdoored IOS images become popular
We need ways to detect and handle intrusions
What Type of Attacker?
Infrastructure is not attacked for a quick hack
E Development of reliable IOS exploits costs too much for quick
D hacks
C The chance of wasting a 0day exploit is too high
B
A What an infrastructure attacker wants is a solid foothold
9 Gain access to the infrastructure any time in the future
8
7 Be able to shut down the network at any given time
6 Stay undetected
5
4 According to estimates by F-Secure, modern Rootkits for
3 Windows cost about 40.000 € in development
2
1 IOS exploit development begins to make commercial sense for
0 an organization with offensive capabilities (three letters of your
favorite UNICODE page)
Types of Attacks
E
Protocol based attacks
D
C Functionality attacks
B
A
9
Binary exploitation
8
7
6
5
4
3
2
1
0
Protocol attacks
Injection of control protocol messages into the
E
D
network (routing protocol attacks)
C Attacker becomes part of the network’s internal
B
A communication
9
8 Attacker influences how messages are forwarded
7
6 Typical examples include:
5
4 ARP poisoning
3
2 DNS poisoning
1
0 Interior routing protocol injections (OSPF, EIGRP)
Exterior routing subnet hijacking (BGP)
Functionality attacks
Configuration problems
E
D Weak passwords (yes, they are still big)
C Weak SNMP communities
B
A Posting your configuration on Internet forums
9
8 Access check vulnerabilities
7
6
5
Cisco’s HTTP level 16++ vulnerability
4 SNMPv3 HMAC verification vulnerability (2008!)
3
2 memcmp( MyHMAC, PackHMAC, PackHMAC_len );
1
0 Debianized SSH keys
Queuing bugs (Denial of Service)
Binary exploitation
E
Router service vulnerabilities:
D Phenoelit’s TFTP exploit
C
B
A Phenoelit’s HTTP exploit
9
8
7
Andy Davis’ FTP exploit
6
5 Router protocol vulnerabilities:
4
3
2
Phenoelit’s OSPF exploit
1
0 Michael Lynn’s IPv6 exploit
Detection and Monitoring
SNMP
E Polling mechanisms, rarely push messages (traps)
D
C Syslog
B Free-form push messages
A
9 Configuration polling
8
7 Polling and correlation
6
5 Route monitoring and looking glasses
4 Real-time monitoring of route path changes
3
2 Traffic accounting
1
0 Not designed for security monitoring, but can yield
valuable information on who does what
Who detects what?
SNMP Syslog Config Route Traffic
polling monitoring accounting
E
D Poisioning Yes Yes - Yes Yes
C attacks
B
A Interrior routing Yes Yes (rare) - Yes Yes
9 attacks
8 Exterrior routing Yes Yes - Yes Yes
7 attacks
6
5 Illegal access Yes Yes Maybe - -
4 due to config
3 issues
2
1 Access check - Yes Maybe - -
0 vulns
Binary exploits - - Maybe - -
(if stupid)
The Common Solution
Centrally log everything
E
D The interesting information is in the debug messages.
C Too many, too slow
B
A Who wades through the logs?
9
8 Messages keep changing over IOS releases
7
6 SNMP
5
4 Doesn’t contain the information you need to decide if
3 you are looking at a regular crash or an attack
2
1
0 Attempting to detect the exploitation while it
happens has proven to suck badly
But there is Crashinfo
If the exploit failed, you might get a crashinfo file
E
D Not all IOS releases write crash-info files
C
B
A
Is there enough space on the flash: device?
9
8 Crash-info is for Cisco IOS coders, not for
7
6 forensics
5
4 Stack trace is misleading at best in more than 80% of
3 all crash cases (software forced reload)
2
1
0
After exploitation of heap overflows, the wrong heap
sections are shown
It’s just not enough info for forensics
What do binary exploits do?
Binary modification of the runtime image
E
D Patch user access credential checking (backdoor)
C
B Patch logging mechanisms
A
9 Patch firewall functionality
8
7
6
Data structure patching
5
4
Change access levels of VTYs (shells)
3 Bind additional VTYs (Michael Lynn’s attack)
2
1
0
Terminate processes
It actually depends … we will come back to it
Forensics for Binary Exploits
E
What we need:
D
C Evidence acquisition
B
A
9
Recovering of information from raw data
8
7
6
Analysis of information
5
4 Plus:
3
2
1 Good understanding of Cisco IOS
0
internals
Inside Cisco IOS
One large ELF binary
E Essentially a large, statically linked UNIX program, loaded by ROMMON
D Runs directly on the router’s main CPU
C
B If the CPU provides privilege separation, it will not be used
A e.g. privilege levels on PPC
9 Virtual Memory Mapping will be used, minimally
8
7 Processes are rather like threads
6 No virtual memory mapping per process
5
4 Run-to-completion, cooperative multitasking
3 Interrupt driven handling of critical events
2
1 System-wide global data structures
0
Common heap
Very little abstraction around the data structures, no way to force
Cisco IOS Device Memory
IOS devices start from the ROMMON
E Loading an IOS image from Flash or network into RAM
D
C The image may be self-decompressing
B
A The image may contain firmware for additional hardware
9
8 Configuration is loaded as ASCII text from NVRAM or
7 network
6
5 Parsed on load
4
3 Mixed with image version dependent defaults of configuration
2 settings
1
0 Everything is kept in RAM
Configuration changes have immediate effect
Configuration is written back into NVRAM by command
Evidence Acquisition
Common operating system:
E
D Most evidence is non-volatile
C
B Imaging the hard-drive is the acquisition method
A
9 Capturing volatile data is optional
8
7
6
Cisco IOS:
5
4
Almost all evidence is volatile
3 What we need is memory imaging
2
1
0
On-demand or when the device restarts
Restarting is the default behavior on errors!
Non-volatile Cisco Evidence
E
Flash file system
D If the attacker modified the IOS image
C
B statically
A
9
8
7
NVRAM
6
5 If the attacker modified the configuration and
4
3 wrote it back into NVRAM
2
1
0
Both cases are rare for binary exploits
Evidence Acquisition: Cores
Using debugging features for evidence
E
D acquisition:
C
B IOS can write complete core dump files
A
9 Dump targets: TFTP (broken), FTP, RCP, Flash
8
7 Complete dump
6
5 Includes Main Memory
4 Includes IO Memory
3
2 Includes PCI Memory
1
0 Raw dump, perfect evidence
Evidence must be configured
Core dumps are enabled by configuration
E Configuration change has no effect on the
D router’s operation or performance
C
B
A
Configure all IOS devices to dump core onto one or
9 more centrally located FTP servers
8
7 Minimizes required monitoring of devices
6 Preserves evidence
5
4 Allows crash correlation between different routers
3
2 Why wasn’t it used before?
1
0 Core dumps were useless, except for Cisco developers
and exploit writers
CIR – Cisco Incident Response
E
Publicly available core dump analyzer:
D
C
http://cir.recurity-labs.com
B
A Currently supports 1700 and 2600 series
9
8 Server side processing of core dumps
7
6
5 Entirely written in .NET
4
3 We don’t want to get owned by malicious core
2 dumps
1
0
Rootkit Detection Arms Race
E
D
C Next Attack Detection
B
A Rootkit code patching core dump GDB debug protocol memory
9 writing acquisition
8
7 GDB debugger stub patching ROMMON privilege mode memory
6
acquisition
5
4
3
2
1
0
The Image Blueprint
The IOS image (ELF file) contains all required
E
D
information about the memory mapping on the router
C The image serves as the memory layout blueprint, to be applied
B
A to the core files
9 We wish it were as easy as it sounds
8
7 Using a known-to-be-good image also allows verification
6
5 of the code and read-only data segments
4
3 Now we can easily and reliably detect runtime patched images
2
1
0
Image vs. Core
IO Memory
E ELF Header
D Code Segment Code Segment
C
B
A
9
8 Read-Only Data Read-Only Data
7
6
5
4 Data Data
3
2
1
0
BSS data
Simple Detections Work Best
E Recurity Labs CIR vs. Topo‘s DIK
D
C (at PH-Neutral 0x7d8)
B
A
9
8
7
6
5
4
3
2
1
0
CIR Online case: 120EF269A5BC2320730E60289A4B84D9047CECEE
Heap Reconstruction
IOS uses one large heap
E
D The IOS heap contains plenty of meta-data for
C
B debugging purposes
A
9 40 bytes overhead per heap block in IOS up to 12.3
8 48 bytes overhead per heap block in IOS 12.4
7
6
5 Reconstructing the entire heap allows extensive
4 integrity and validity checks
3
2 Exceeding by far the on-board checks IOS performs
1
0 during runtime
Showing a number of things that would have liked to
stay hidden in the shadows
Heap Verification
Full functionality of “CheckHeaps”
E Verify the integrity of the allocated and free heap block doubly
D linked lists
C
B Find holes in addressable heap
A
9 Invisible to CheckHeaps
8
7 Identify heap overflow footprints
6 Values not verified by CheckHeaps
5
4 Heuristics on rarely used fields
3
2 Map heap blocks to referencing processes
1
0 Identify formerly allocated heap blocks
Catches memory usage peaks from the recent past
Process List
Extraction of the IOS Process List
E
D Identify the processes’ stack block
C Create individual, per process back-traces
B
A Identify return address overwrites
9
8 Obtain the processes’ scheduling state
7
6 Obtain the processes’ CPU usage history
5
4
Obtain the processes’ CPU context
3
2 Almost any post mortem analysis method known
1
0
can be applied, given the two reconstructed data
structures.
TCL Backdoor Detection
E
We can extract any TCL script “chunk”
D
C
from the memory dump
B
A Currently only rare chunks
9
8 There is still some reversing to do
7
6
5 Potentially, a TCL decompiler will be required
4
3
2
1
0
IOS Packet Forwarding Memory
IOS performs routing either as:
E Process switching
D Fast switching
C
B Particle systems
A Hardware accelerated switching
9
8 Entirely incomprehensible voodoo
7
6
At least access layer router all use IO memory
5 IO memory is written as separate code dump
4 By default, about 6% of the router’s memory is dedicated as IO
3 memory
2
1 Hardware switched packets use PCI memory
0
PCI memory is written as separate core dump
Bigger iron?
Should provide a respective core file as well
IO Memory Buffers
Routing (switching) ring buffers are grouped by packet
E size
D
C Small
B Medium
A
9 Big
8 Huge
7
6 Interfaces have their own buffers for locally handled
5
4 traffic
3
2 IOS tries really hard to not copy packets around in
1 memory
0
New traffic does not automatically erase older traffic in a
linear way
Traffic Extraction
CIR dumps packets that were process switched
E
D by the router from IO memory into a PCAP file
C
B Traffic addressed to and from the router itself
A
9 Traffic that was process switching inspected
8
7 Access List matching
6
5 QoS routed traffic
4
3 CIR could dump packets that were forwarded
2
1 through the router too
0
Reconstruction of packet fragments possible
Currently not in focus, but can be done
Challenges with IOS
The challenge with IOS is the combinatory explosion
E of platform, IOS version, Feature Set and additional
D
C hardware
B
A Every IOS image is compiled individually
9
8 Over 100.000 IOS images currently used in the wild
7
6 (production networks)
5
4
Around 15.000 officially supported by Cisco
3 Cisco IOS is rarely updated and cannot be patched
2
1 This is a great headache for IOS forensics, but also
0
for IOS exploit writers
Reality Check IOS Exploits
The entire code is in the image
E
D Remotely, you have a 1-in-100.000 chance to
C
B guess the IOS image (conservative estimate)
A
9 Any exception causes the router to restart
8
7 This is inherent to a monolithic firmware design, as it
6
5
looses integrity entirely with a single error
4
3
Stacks are heap blocks
2 Always at different memory addresses
1
0 Addresses vary even within the same image
Reality Check IOS Exploits
So far, all IOS exploits published use fixed
E
D addresses that depend on the exact IOS image
C
B being known before the attack
A
9 IOS’s address diversity is a similar “protection” as the
8
7 Source Port Randomization patch you applied to your
6
5
DNS servers in summer 2008
4
3 Performing your own research in this area is vital
2
1 to understand weaponized exploits
0
It is always hard to detect something you could not
get to work yourself
Where to (re)turn to?
E
The complete address layout changes with
D
C
every image
B
A IO memory even changes based on
9
8 configuration and is not executable
7
6
5 Start End Size(b) Class Media Name
4 0x03C00000 0x03FFFFFF 4194304 Iomem R/W iomem
3 0x60000000 0x60FFFFFF 16777216 Flash R/O flash
2 0x80000000 0x83BFFFFF 62914560 Local R/W main
1
0 0x8000808C 0x8095B087 9777148 IText R/O main:text
0x8095B088 0x80CDBFCB 3673924 IData R/W main:data
0x80CDBFCC 0x80DECEE7 1117980 IBss R/W main:bss
0x80DECEE8 0x83BFFFFF 48312600 Local R/W main:heap
The ROMMON code
ROMMON code (System Version 11.3(2)XA4
E Bootstrap) is mapped in Version 12.1(3r)T1
D
C memory and stays there Version 12.1(3r)T2
B Version 12.2(10r)1
A 0xFFF00000 is the Version 12.2(6r)
9 exception vector base upon Version 12.2(7r) [cmong 7r]
8
7 startup, followed by Version 12.2(7r)XM1
6 ROMMON code Version 12.2(8r) [cmong 8r]
5
4
3 Version distribution is much smaller
2
1 The figure shows System Bootstrap versions for the 2600
0 platform, based on Internet posted boot screen captures
ROMMON is almost never updated (and often cannot)
Versions depend on shipping data (bulk sales rocks!)
Return Oriented Programming*
E
Chaining together function epilogs before
D
C
return to gain arbitrary functionality
B
A One of these hacking techniques that every
9
8 sufficiently talented hacker with a need came
7
6 up with independently
5
4
3
Has been shown to work nicely on IA-32
2
1 and SPARC code using an entire glibc
0
We have 146556 bytes (36639 instructions)
and a PowerPC CPU that returns via LR
* „Return-oriented Programming: Exploitation without Code Injection“
Erik Buchanan, Ryan Roemer, Stefan Savage, Hovav Shacham - University of California, San Diego
http://www.blackhat.com/presentations/bh-usa-08/Shacham/BH_US_08_Shacham_Return_Oriented_Programming.pdf
Return Oriented on PowerPC Stack
Code 41414141 Buffer
[here be buffer overflow] 41414141 Buffer
lwz %r0, 0x20+arg_4(%sp) 41414141 Buffer
E
D mtlr %r0
lwz %r30, 0x20+var_8(%sp) 41414141 Buffer
C
B lwz %r31, 0x20+var_4(%sp) VALUE saved R30
A
addi %sp, %sp, 0x20 saved R31
DEST.PTR
9
8 blr
41414141 saved SP
7
6 FUNC_02 saved LR
5 FUNC_02: Memory write!
4 stw %r30, 0xAB(%r31) 42424242saved R28
3 lwz %r0, 0x18+arg_4(%sp) 42424242saved R29
2
1 mtlr %r0 VALUE2 saved R30
0 lwz %r28, 0x18+var_10(%sp)
lwz %r29, 0x18+var_C(%sp) saved R31
DEST.PTR2
lwz %r30, 0x18+var_8(%sp) 42424242 saved SP
lwz %r31, 0x18+var_4(%sp) FUNC_02 saved LR
addi %sp, %sp, 0x18
blr stuff
Too Much Cache
PowerPC has separate
E
D instruction and data caches
C
B
A
Executing data you just wrote
9
8
doesn’t work AAAA…AAAAA
7
6
5
4 memcpy() D-Cache
3 return Memory
2
1 CPU
0 AAAA…AAAAA
I-Cache
More Code Reuse
stwu %sp, -0x10(%sp)
E
The Bootstrap code mflr
stw
%r0
%r31, 0x10+var_4(%sp)
stw %r0, 0x10+arg_4(%sp)
D
C
already brings bl
mr
Disable_Interrupts
%r31, %r3
mfspr %r0, dc_cst
B
A functionality that we cmpwi
bge
cr1, %r0, 0
cr1, NoDataCache
9
8 need: bl
bl
Flush_Data_Cache
Unlock_Data_Cache
7 bl Disable_Data_Cache
6
5
Disable all caches! NoDataCache:
bl Invalidate_Instruction_Cache
bl Unlock_Instruction_Cache
4 bl Disable_Instruction_Cache
3 mfmsr %r0
2 rlwinm %r0, %r0, 0,28,25
1
0 IOS doesn’t care mtmsr
cmpwi
%r0
cr1, %r31, 0
beq cr1, InterruptsAreOff
But we do! bl EnableInterrupts
InterruptsAreOff:
lwz %r0, 0x10+arg_4(%sp)
mtlr %r0
lwz %r31, 0x10+var_4(%sp)
addi %sp, %sp, 0x10
blr
Reliable Code Execution
AAAAAAAAAAAA IO Memory
AAAAAAAAA…
mtctr SP
Globals
Return oriented P bctr
mtctr S
E
D Cache Disable
6 Code Segment
C Return oriented bctr B10
B memory write
EFE
A Return oriented
0xF
9 memory write
h Read-Only Data
c
8 Execute written ar
7 data (code) se copy
6
Second Stage
5 Code: Data
4
3 Search for full
2 packet in
1 IO Memory
0
Run third stage
code
STACK
Heap
ROMMON
Reliability Notes
The return oriented ROMMON method is reliable
E
D for a known System Bootstrap version
C
B Successfully implemented an exploit for the IP
A
9 options vulnerability*
8
7 Successfully ported Andy Davis’ FTP server** exploit
6
5
to the method
4
3 The second stage code is actually less reliable:
2
1 Devices using the same ROMMON code may
0
place their IO Memory at different base
addresses (e.g. 2611 vs. 2621)
* cisco-sa-20070124-crafted-ip-option
** cisco-sa-20070509-iosftp
Getting away with it
E
Reliable code execution is nice, but an
D
C
attacker needs the device to stay running
B
A Andy Davis et al have called the
9
8
7
TerminateProcess function of IOS
6
5 Needs the address of this function, which is
4
3 again image dependent
2
1 Exactly what is not wanted!
0
Crucial processes should not be terminated
IP Options vulnerability exploits “IP Input”
Getting away with it
Buffer
41414141
Buffer
41414141
Remember the stack layout?
E Buffer
41414141
D We search the stack for a stack frame Buffer
41414141
C
B
A
sequence of SP&LR upwards saved
VALUE R30
9 saved R31
DEST.PTR
Once found, we restore the stack pointer
8 saved
41414141 SP
7 and return to the caller
6 saved
FUNC_02 LR
5
4
This is reliable across images, as the saved R28
3
2
call stack layout does not change saved R29
1
0
dramatically over releases saved R30
saved R31
This has been shown to be mostly true
saved SP
on other well exploited platforms
saved LR
stuff
Demo
E
D
C
B
A
9
8
7
6
Remote Message Display for IOS ☺
5
4
3
2
1
0
On IOS Shellcode
E
Image independent exploits require image
D
C
independent shellcode
B
A Earlier, image dependent exploits use fixed
9
8 addresses for function calls and data
7
6 structures
5
4 Signature based shellcode by Andy Davis
3
2
1
searches code but still uses fixed data
0 structure offsets, which are not stable
Disassembling Shellcode
E
When searching for code manually, one
D
C
often follows string references
B
A
9
8
7
6
5
4
3
2
1
0
Disassembling Shellcode
E
Shellcode can do the same:
D 1. Find a unique string to determine its address
C
B
A 2. Find a code sequence of LIS / ADDI loading
9
8 the address of this string
7
6
5
3. Go backwards until you find the STWU %SP
4
3
instruction, marking the beginning of the
2
1
function
0
4. Patch the function to always return TRUE
Disassembling Shellcode
bl .code .findlis:
.string „Unique String to look for" lwz %r4, 0x0(%r5)
.byte 0x00 rlwinm %r4, %r4, 0, 0xF81FFFFF
.byte 0x00 cmpw %cr1, %r4, %r7
.code: bne %cr1, .findlisnext
E mflr %r3 lwz %r4, 0x4(%r5)
D lmw %r29,0x0(%r3) rlwinm %r4, %r4, 0, 0xF800FFFF
C lis %r3,0x8000 cmpw %cr1, %r4, %r8
B ori %r3,%r3,0x8000 beq %cr1, .loadfound
A mr %r5,%r3 .findlisnext:
.find_r29: addi %r5, %r5, 4
9 lwz %r4,0x0(%r3) b .findlis
8 cmpw %cr1, %r4, %r29
7 bne %cr1, .findnext .loadfound:
6 lwz %r4,0x4(%r3) xor %r6, %r6, %r6
5 cmpw %cr1, %r4, %r30 ori %r6, %r6, 0x9421
bne %cr1, .findnext lhz %r4, 0x0(%r5)
4 lwz %r4,0x8(%r3) cmpw %cr1, %r4, %r6
3 cmpw %cr1, %r4, %r31 beq %cr1, .functionFound
2 beq %cr1, .stringfound addi %r5, %r5, -4
1 .findnext: b .loadfound
0 addi %r3,%r3,4
b .find_r29 .functionFound:
# string address is now in R3 lis %r4, 0x3860
.stringfound: ori %r4, %r4, 0x0001
lis %r7, 0x3800 stw %r4, 0x0(%r5)
rlwinm %r6, %r3, 16, 16, 31 addi %r5,%r5,4
andi. %r8, %r3, 0xFFFF lis %r4, 0x4e80
or %r8, %r8, %r7 ori %r4, %r4, 0x0020
or %r7, %r7, %r6 stw %r4, 0x0(%r5)
IOS Shellcode Options
Port bind shell (VTY)
Full interaction + logging
E Requires port 22 or 23 open and reachable
D Doesn’t work for AAA configurations
C
B Connect-back VTY shellcode
A Full interaction + logging
9 Requires outgoing connections to the connect-back target
8 Doesn’t work for AAA configurations
7 Single command execution shellcode
6
5 One packet – one command
4 Requires no back-channel
3 Works with AAA configurations
2 Cannot change the configuration easily
1 Image patching shellcode
0
The most powerful and flexible method, but can get really big
Further work is required in this area, so we know what to
look for in forensics
Summary
The best defense is still to block traffic
E
D
terminating at the router’s interface
C
B IOS forensic tools (e.g. CIR) are capable of
A
9
detecting current rootkits and shellcodes in
8
7
action, if they persist
6 Non-persistent exploits are really hard to detect
5
4
3
Reliable code execution is possible
2 At least on the PowerPC based platforms
1
0 It is highly likely that the $badguys have
significant better exploits at their disposal
Thanks
Nicolas Fischbach for pointing out Bootloader
E
D
and ROMMON code
C
B
Mac + souls for Cisco equipment
A
9 Cloudsky for the initial question on stack
8
7
overflow exploitation
6
5
Zynamics for BinDiff and BinNavi
4
3
nowin for finding and defending research time
2
1 Mumpi for awesomeness
0
Ilker from Cisco PSIRT for a presentation on
IOS attacks without the word “Phenoelit” in it