Navigation

• Main Page

• Random Page
• Create a new Page
• All Pages
• Categories

• Administration
• File Management

• Login/Logout
• Language Selection
• Your Profile
• Create Account

Quick Search

Advanced Search »

Table of Contents [Hide/Show] Introduction to CIR Reports Signatures    ELF Signature    Core Signature    Apples and Pears    Report Signature Text Segment Compare Read-Only Data Segment Compare    Note: IOS Design Failure Heap Tests    Heap Parser    Heap Parser IO    Check Heap Use    Check Heaps Processes    Process Lister Packet Memory    Packet Headers    Packet Header 2 PCAP

Edit

Introduction to CIR Reports

CIR outputs its dynamic knowledge base into reports. The main report file is report.xml and contains all information that CIR recovered from the core dump data. This file is therefore the primary and only information source for the resulting HTML files generated by the report transformation engine.

The following discusses typical CIR report outputs and how to interpret them to detect attacks and modifications for site's

Edit

Signatures

IOS images and the resulting core files contain signatures that tell CIR which version, feature-set and platform this image belongs to. CIR performs three checks on the signatures, as detailed below.

Edit

ELF Signature

CIR extracts the signature from the IOS image ELF file and shows it as result in the ELF IOS Signature field.

Edit

Core Signature

CIR extracts the signature from the IOS core file and shows it as result in the Core IOS Signature field.

Edit

Apples and Pears

CIR performs a comparison between the IOS image and the core file signature to ensure that the comparison between the image and the core is valid. Several tests in CIR depend on the image being an untempered-with IOS image that corresponds exactly to the platform, version and feature-set of the image that wrote the core file. If the test AppleAndPears fails, the entire CIR report is invalid!

Edit

Report Signature

This module is responsible for reporting the identified signatures in IOS ELF image and core file in a form understandable by regular Cisco engineers.

Edit

Text Segment Compare

Differences in the Text Segment Comparison are almost always corruptions. As the text segment is read-only on almost all router platforms, the modification is in almost all cases intentional and the result of an attack. As an example, see:

The example shows Topo's DIK rootkit patching three locations in the text segment of the IOS image at the entry of functions. In a forensics case, the investigator needs to load the core dump into a disassembler, such as IDA. The CIR report tells the investigator exactly at which addresses the code modification was performed, without the need to disassemble the entire core file and compare it manually to the image disassembly. Simply going to the virtual addresses shown in the report and disassembling from there is sufficient to recover the entire rootkit in this case.

Edit

Read-Only Data Segment Compare

Read-only data segments should never differ between an IOS image and the resulting core file. Any modification identified may indicate an intentional modification caused by an attack or backdoor.

Edit

Note: IOS Design Failure

There are IOS images that will exhibit a very large number of changes in successive read-only data segment addresses. The forensics investigator must inspect the IOS image (uncompressed) and the core file at the addresses shown in the CIR report. If the uncompressed IOS image shows the byte signature PK\03\04 in the beginning of the section in question, the difference may not be caused by an attacker but by poor software design: Apparently, some IOS images bring the firmware for line cards, such as Modem cards (e.g. WIC-1AM) as ZIP compressed binary blob in their read-only data section. Unfortunately, some image versions decompress this payload in-place, meaning that the decompressed data is written to the same memory address. This has several consequences:

1. The read-only data section is obviously no longer memory mapped as read-only, otherwise the write operation of the decompression would fail.
2. The compressed firmware for the line card may easily contain malicious code or header information, causing IOS to overwrite other parts of memory it did not intent to overwrite, exploiting itself. This is fairly hard to detect.
3. An attacker can modify the IOS read-only data segment and hope to stay undetected due to the large number of modifications.

The forensics investigator should in this case trace all modifications by comparing the hex dump of the uncompressed image and the core file to the point where an apparent decompression would end. If a significant gap between the decompressed data and another modification is observed, the later modification must be inspected more closely.


Edit

Heap Tests

This section covers the IOS heap based tests and modules in CIR. The IOS heap is the most intensively used data area of the entire runtime environment and therefore yields the most insight for the forensics investigator.

Edit

Heap Parser

The Heap Parser analyzes the IOS heap based on its internal structure. The analysis views the heap in the same way IOS views it, hereby presenting a view that is very similar to the output of IOS on-board commands, such as show process memory. The summary of the plugin's output shows the number of allocated and the number of free blocks.


Edit

Heap Parser IO

Edit

Check Heap Use

Edit

Check Heaps

Edit

Processes

Edit

Process Lister

Edit

Packet Memory

Edit

Packet Headers

Edit

Packet Header 2 PCAP

Web hosting