No Wireshark? No TCPDump? No Problem!
Have you ever been on a pentest, or troubleshooting a customer issue, and the "next step" was to capture packets on a Windows host? Then you find that installing winpcap or wireshark was simply out of scope or otherwise not allowed on that SQL, Exchange, Oracle or other host? It used to be that this is when we'd recommend installing Microsoft's Netmon packet capture utility, but even then lots of IT managers would hesitate about using the "install" word in association with a critical server. Well, as they say in networking (and security as well), there's always another way, and this is that way.
"netsh trace" is your friend. And yes, it does exactly what it sounds like it does.
Type "netsh trace help" on any Windows 7 Windows Server 2008 or newer box, and you'll see the following:
C:\>netsh trace help
The following commands are available:
Commands in this context:
? - Displays a list of commands.
convert - Converts a trace file to an HTML report.
correlate - Normalizes or filters a trace file to a new output file.
diagnose - Start a diagnose session.
dump - Displays a configuration script.
help - Displays a list of commands.
show - List interfaces, providers and tracing state.
start - Starts tracing.
stop - Stops tracing.
Of course, in most cases, tracing everything on any production box is not advisable - especially if it's your main Exchange, SQL or Oracle server. We'll need to filter the capture, usually to a specific host IP, protocol or similar. You can see more on this here:
netsh trace show capturefilterhelp
One of the examples in this output shows you how t o e.g. 'netsh trace start capture=yes Ethernet.Type=IPv4 IPv4.Address=157.59.136.1'
You could also add Protocol=TCP or UDP and so on..
Full syntax and notes for netsh trace can be found here: https://technet.microsoft.com/en-us/library/dd878517
For instance, the following session shows me capturing an issue with a firewall that I'm working on. Note that you need admin rights to run this, the same as any capture tool. In a pentest you would likely specify an output file that isn't in the users' directory.
C:\>netsh trace start capture=yes IPv4.Address=192.168.122.2
Trace configuration:
-------------------------------------------------------------------
Status: Running
Trace File: C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace
.etl
Append: Off
Circular: On
Max Size: 250 MB
Report: Off
When you are done capturing data, it's time to stop it:
C:\> netsh trace stop
Correlating traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as
"C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.cab".
File location = C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.etl
Tracing session was successfully stopped.
c:\
The cool thing about this is that it doesn't need a terminal session (with a GUI, cursor keys and so on). If all you have is a metasploit shell, netsh trace works great!
If this is a capture for standard sysadmin work, you can simply copy the capture over to your workstation and proceed on with analysis. If this is a pentest, a standard copy might still work (remember, we're on a Microsoft server), but if you need netcat type function to exfiltrate your capture, take a look at PowerCat (which is a netcat port in PowerShell).
Next, open the file (which is in Microsoft's ETL format) in Microsoft's Message Analyzer app - which you can install on your workstation rather than the server we ran the capture on ( http://www.microsoft.com/en-us/download/details.aspx?id=44226 ). Message Analyzer has a surprisingly nice interface and some decent packet parsing, you might be able to wrap up your analysis just in this tool (see below).
If you do need another packet analysis tool, it's easy to a File / Save As / Export, and save as a PCAP file that Wireshark, tcpdump, SNORT, ngrep, standard python or perl calls, or any other standard tool can read natively.
Or you can convert to PCAP using PowerShell (of course you can). A short, simple script to do this might look like:
$s = New-PefTraceSession -Path “C:\output\path\spec\OutFile.Cap” -SaveOnStop
$s | Add-PefMessageProvider -Provider “C:\input\path\spec\Input.etl”
$s | Start-PefTraceSession
This Powershell cmdlet is not available in Windows 7 - you'll need Windows 8, or Server 2008 or newer
(This script was found at http://blogs.technet.com/b/yongrhee/archive/2013/08/16/so-you-want-to-use-wireshark-to-read-the-netsh-trace-output-etl.aspx )
If 'netsh trace' has solved an interesting problem for you, or was the tool that got you some interesting data in a pentest, please, use our comment form to let us know how you used it (within your NDA of course!)
===============
Rob VandenBrink
Metafore
Freak Attack - Surprised? No. Worried? A little.
There has been some press surrounding the SSL issue published recently dubbed Freak. It was reported in the Washington post1 and other sites, but what does it really mean?
The issue relates to the use of Export Ciphers (the crypto equivalent of keeping the good biscuit yourself and giving the smaller broken one to your little brother or sister). The Export Ciphers were used as the "allowed" ciphers for non US use. The ciphers are part of OpenSSL and the researchers2 have identified a method of forcing the exchange between a client and server to use these weak ciphers, even if the cipher suite is not "officially" supported3.
On first reading, like many, I thought so what, especially since you have to do a man-in-the-middle (MITM) attack. When you do a MITM attack you have full control over the connection anyway, so why bother decrypting anything? However, if I'm reading and interpreting the examples correctly (kind of hoping I'm wrong), it looks like this particular attack solves one challenge that a MITM has. For HTTPS intercept you usually generate a new certificate with the information of the site and resign the certificate before presenting it to the client. Whenever you present this newly signed certificate the client receives an error message stating that the certificate does not match the expected certificate for the site. From the vids2 it looks like this attack could "fix" that particular problem. So now when you perform a MITM attack you retain the original certificate and the user is none the wiser. This could open up a whole new avenue of attacks against clients and potentially simplify something that was quite difficult to do.
What is the impact to organisations? Well it is quite possible that your sites will be impersonated and there won't be much that can be done about it and you may not even know that your customers are being attacked. To prevent your site from being used in this attack you'll need to patch openSLL4 (yes again). This issue will remain until systems have been patched and updated, not just servers, but also client software. Client software should be updated soon (hopefully), but there will no doubt be devices that will be vulnerable to this attack for years to come (looking at you Android).
Matthew Green in his blog3 describes the attack well and he raises a very valid point. Backdoors will always come back to bite.
The researchers have set up a site with more info5.
Cheers
Mark H - Shearwater
(Thanks Ugo for bringing it to our attention).
Links:
1 - http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-undermines-security-for-apple-and-google-users-researchers-discover/
2 - https://www.smacktls.com/#freak
3 - http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
4 - https://www.openssl.org/news/secadv_20150108.txt
5 - https://freakattack.com/
Comments