tag:blogger.com,1999:blog-90890434016833643192024-02-20T02:09:39.512-08:00Heisenbugs and other unobservablesDaniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-9089043401683364319.post-3974104295054352572015-07-08T12:57:00.001-07:002015-07-08T13:00:06.759-07:00They see me scannin' (part 2)In the <a href="http://blog.bonsaiviking.com/2015/07/they-see-me-scannin-they-hatin.html">first post in this series</a>, we looked at 10 different ways that IDS and other security systems can identify an <a href="https://nmap.org/">Nmap</a> scan and ruin your day. Don't despair! With a little ingenuity and knowhow, we can eliminate most of these trouble spots.<br />
<br />
There are 3 cardinal rules when trying to avoid detection that apply no matter what tools you are using:<br />
<ol>
<li><b>Less is more. </b>The less traffic you generate, the less the IDS has to match its rules against. You can also avoid packet-counting thresholds this way.</li>
<li><b>Blend in. </b>If your traffic looks like legitimate traffic, it will be harder to catch without drowning in false-positives.</li>
<li><b>Do your research. </b>Reading this blog post is insufficient. You have to know what kind of setup your target is using and tune your approach to what works best.</li>
</ol>
Before we even get to the trouble spots from last time, we can apply these rules to our scan plan. You <i>do</i> have a plan of what you want to accomplish, right? With <i>Less is more</i> in mind, your first step should be to gather as much information as you can from non-attributable sources; only use Nmap for the things only Nmap can tell you. Some examples:<br />
<ul>
<li>Use <b>public DNS records</b> from sites like <a href="https://www.robtex.com/">Robtex</a> for host discovery.</li>
<li>Use <b>hosted scan data and scanners</b> like <a href="https://shodan.io/">Shodan</a>, <a href="https://scans.io/">scans.io</a>, and <a href="https://hackertarget.com/">HackerTarget.com</a>.</li>
<li>Use <b>search engines</b> and <a href="http://qr.ae/7qmlrC">Google dorking</a> to look for interesting stuff.</li>
<li>Use <a href="https://nmap.org/book/man-host-discovery.html#idm214690155792"><b>nmap -sL</b></a> to do reverse-DNS lookups on big subnets looking for interesting names. </li>
</ul>
Once you've done these things, you can try to <b>eliminate unnecessary <a href="https://nmap.org/book/nmap-phases.html">phases</a></b> from your Nmap scan. The simplest one is host discovery: using pre-assembled lists of addresses or hostnames via -iL, you can avoid sweeping large areas of network for active hosts. You probably should verify once that they are up, and afterwards you can use <b>-Pn</b> to skip the <a href="https://nmap.org/book/man-host-discovery.html">host discovery</a> phase. If you <b>save all your output with -oA</b> then you can split your scan into different runs of Nmap without duplicating effort between them. Then you can let some parts (like a broad host discovery scan) run <i>very</i> slowly while you move on with other phases and examining interesting results.<br />
<br />
The other important thing is to <i>do your research</i> regarding your targets and their defenses. By searching job postings, using passive detection, and mapping rules and thresholds, you should get a good idea of what kind of defense systems are being used, how they are configured, and what the typical response actions are. Without this information, you are working blind and just guessing what behaviors to change. Take full advantage of weaknesses: if their IDS is vulnerable to fragmentation bypass, use fragmentation and don't worry about most of these restrictions!<br />
<br />
Now let's examine the trouble spots we identified in Nmap's behavior.<br />
<br />
First, there's the general problem of Nmap's raw packets being unique and fingerprintable. A good way to avoid this for TCP scans is to <b>use the TCP Connect scan</b> (-sT) instead of the SYN scan (-sS). This uses your OS's native socket calls to make connections, which means that the packets will <i>blend in</i> with other connections from valid clients. There are downsides in performance and level of detail (TTL info that can be used to map firewall rules is not available, for instance) but these are usually minimal in an IDS-evasion scenario.<br />
<br />
"But wait," you say, "Isn't SYN scan the 'stealth' option?" Yes it is—<a href="http://phrack.org/issues/51/11.html#article">in 1997</a>. If your defense technology consists of watching daemon logs for aborted connection attempts, then TCP SYN scan is completely invisible. But as we discussed last time, SYN scan sticks out like a sore thumb to a stateful IDS. The combination of unique TCP options and unusual packet sequence make it a poor choice for IDS evasion.<br />
<br />
<i>Side note:</i> A patch to allow a user to override the TCP Window size in SYN scan was <a href="http://seclists.org/nmap-dev/2015/q3/52">just posted to the Nmap development list</a>. I haven't tested it at all, but it would help with one aspect of this detection. <br />
<br />
Next, there's the specific problem of Nmap's ICMP Echo Request host discovery option (-PE, used by default with root privilege) sending packets without a body. There are <a href="https://nmap.org/book/man-bypass-firewalls-ids.html#idm214689309776">a few different options</a> that can be used here: <b>--data-length</b> has been around since before Nmap 3.00 and appends a specified number of random bytes to the end of all raw packets. This avoids the signature directly, but still could look suspicious because most ping tools use a well-known static string. In the <a href="https://nmap.org/download">latest versions</a> (beginning with 6.49BETA1), you can also use <b>--data</b> or <b>--data-string</b> to specify particular payloads to use. You'll have to separate the ICMP host discovery Nmap commands from the other uses of Nmap, though, since the data gets appended to <i>every</i> packet, which is unexpected and weird.<br />
<br />
I'm mostly going to skip over <a href="http://nmap.org/book/osdetect.html">OS detection</a>, because there's no way to make it more stealthy. Because it depends on sending a bunch of strange-looking packets in a specific order, it will always be easy to detect. <b>Avoid -O and -A</b> if you are at all concerned with avoiding detection.<br />
<br />
The cautions regarding excessive fragmentation are best handled by <i>doing your research.</i> Not all IDS will complain about this, and many of them will actually be bypassed by it (which is why the -f option was created in the first place). If you <b>probe your target's defenses</b> before trying large-scale enumeration, you'll know whether or not -f will help or harm you. <br />
<br />
The performance impact of TCP Connect scan should not cause you problems because you will be artificially slowing down your progress to avoid timing thresholds. A good way to do this is to <b>start with the <a href="https://nmap.org/book/man-performance.html#idm214689427808">timing templates</a> (-T[0-5])</b> and then apply some <i>well-researched</i> tweaks. -T3 is the default, so you obviously want to go slower than that, but -T0 slows you down to 4 packets per <i>minute</i>, which is ridiculous. Here are some options that are helpful in combination with -T2 and lower:<br />
<ul>
<li><b>--max-retries</b> - At very reduced speeds, you can't often afford to spend extra packets confirming that a port is filtered. Set this to 1 or 2 and just accept that you might miss something due to a dropped packet here or there.</li>
<li><b>--max-rate</b> - The primary effect of -T[0-2] is to slow down the packet rate. If you don't remember or don't like the rate one of the templates uses, override it with this.</li>
</ul>
For UDP payloads that are getting you in trouble, the easiest way to avoid the pain is to not scan for UDP ports. That advice isn't very helpful, though, so let's look at your options for <i>blending in</i> and reducing the noise. The first and simplest option is to use <b>--data-length 0</b> to disable the payload feature. Actually, any of the --data* options will override the UDP payload feature, but --data-length 0 is a special case that has no other effect. As you might expect from a fast-simple option, this one loses you the most functionality; no payloads means slower UDP scans and more retries.<br />
<br />
Another, more difficult way to hide your UDP scans is to actually <b>edit the <a href="https://nmap.org/book/nmap-payloads.html">nmap-payloads file</a></b> to change what payloads are used. This can be beneficial in the long run, but requires that you <i>do your research.</i> Since these are actually sent to service daemons on your target, proceed with caution. You could end up <a href="https://docs.google.com/spreadsheet/ccc?key=0Agg23JycSkYddDZHRnltVlZUMkVKSnUtN2g0WDl5clE&usp=sharing">crashing something</a>.<br />
<br />
As always, the ultimate solution to IDS detection of <a href="https://nmap.org/book/vscan.html">-sV</a> is not to use the option. That said, there are other ways to reduce the noise a bit. Using the <b>--version-intensity</b> option, you can <i>reduce the number</i> of different probes that Nmap will try before giving up on a service. This means losing some version information, but you can usually get an idea of the type of service running on a port if it is a common port for that service. Setting this option to 0 will send only the Null probe (connect and wait for banner) and any probes that have been specifically listed as pertaining to the scanned port in <a href="https://nmap.org/book/vscan-fileformat.html">nmap-service-probes</a>. As always, <i>do your research</i> and understand what kinds of probes will be sent to what ports.<br />
<br />
In addition to the probes in the nmap-service-probes file, -sV implies "--script version" or "run all the <a href="https://nmap.org/nsedoc/categories/version.html">NSE scripts in the 'version' category</a>." In versions of Nmap prior to 6.49BETA1, you could only <b>prevent these scripts from running</b> by removing them from the script.db catalog or by building Nmap without NSE support (./configure --without-liblua). Now, however, the --version-intensity option passes through to the version scripts, which all check to be sure that it is not less than 7 before running.<br />
<br />
If you are wild enough to try NSE scripts against an IDS-protected target, you should know how to read <a href="http://www.lua.org/manual/5.2/manual.html">Lua</a>, since <b>the script sources</b> are the final authority on what data is sent. But if you're just looking to get a little better at <i>blending in</i>, these tips should help:<br />
<ul>
<li>Use <b>--script-args-file</b> to pass script arguments to Nmap from a file. This will keep your command line clean and make it harder to accidentally miss one of the options you choose</li>
<li>Obviously <b>avoid dos, intrusive, and exploit category</b> scripts.</li>
<li><b>Use scripts by name</b> instead of by category, so that you know exactly what will be run. </li>
<li>Thoroughly <a href="https://nmap.org/nsedoc/"><b>read the documentation</b></a> for each script you intend to use.</li>
<li>Set <a href="https://nmap.org/nsedoc/lib/http.html#script-args"><b>http.useragent</b></a> to something believable that blends in.</li>
</ul>
I hope this was interesting and useful. Stay safe and happy scanning! Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-41627855938467349252015-07-08T05:48:00.001-07:002020-02-17T07:58:44.231-08:00They see me scannin'; they hatin'<ol>
</ol>
(Part 1 of a 2-part series on IDS evasion with Nmap. <a href="http://blog.bonsaiviking.com/2015/07/they-see-me-scannin-part-2.html">Part 2 is here</a>.) <br />
<br />
One hour into your pentest and you're already getting calls from the Blue Team:<br />
<br />
"We see your Nmap scans. Do you want to just give up now, or..."<br />
<br />
<i>Impossible,</i> <i>I used "SYN Stealth scan" and scanned really slowly!</i><br />
<br />
It's not impossible: <a href="https://nmap.org/">Nmap</a> out-of-the-box is really not that hard to spot if you know what you are looking for. Here are the most-common ways that Nmap scans get detected by IDS.<i> </i><br />
<br />
<b>Quirks of Nmap's raw packets.</b> Nmap uses raw sockets (or raw Ethernet access on Windows) to craft and send customized packets for rapid scanning. Because these packets are unique, they can be detected easily. Some specific examples:
<br />
<ul>
<li><b><a href="https://nmap.org/book/man-host-discovery.html">ICMP Echo Request</a> with no payload.</b> Snort IDS recognizes this with <a href="https://www.snort.org/rule_docs/469">SID 469</a>.</li>
<li><b><a href="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1">TCP options</a> in port scan.</b> This is how <a href="http://lcamtuf.coredump.cx/p0f3/">p0f</a> recognizes Nmap's SYN scan: TCP window size a multiple of 1024, and only the MSS option supported with a value of 1460.</li>
<li><b>TCP options in <a href="https://nmap.org/book/osdetect.html">OS detection</a>.</b> These options were chosen specifically to test edge cases of target TCP/IP stacks, and must be consistent in order to produce consistent results. That means it's a stationary target for IDS signature writers. Snort and p0f both catch this easily.</li>
</ul>
<b>Invalid or unexpected TCP packet sequence.</b> Nmap's more <a href="https://nmap.org/book/man-port-scanning-techniques.html">unusual scan options</a> like the FIN, NULL, XMAS, Window, and Maimon scans send packets which are invalid, since they are not part of any existing TCP session. That means they can be detected immediately by an IDS. It's also very likely that the packets will simply be blocked by a <a href="https://en.wikipedia.org/wiki/Stateful_firewall">stateful firewall</a> rule.<br />
<br />
Even the standard SYN scan can readily be detected by this method as soon as it scans an open port, since the SYN, SYN/ACK, RST behavior is highly unusual.<br />
<br />
<b>Excessive fragmentation.</b> Some of the previous detection points can be avoided by fragmenting the scan packets into tiny bits that cannot be completely inspected. The <a href="https://nmap.org/book/man-bypass-firewalls-ids.html">-f and --mtu options</a> enable this behavior. But this can have unintended consequences: routers may just drop your traffic; IDS engines can trigger alerts based on the unusually small fragments; and IDS engines can use preprocessors like <a href="http://manual.snort.org/node60.html">Snort's frag3</a> to reassemble the fragments before applying rules.<br />
<br />
<b>Timing thresholds.</b> These generic rules will catch pretty much every port scanner ever, as long as they try to operate at any reasonable speed. The most valuable thresholds count the number of failed connections (TCP RST or ICMP error responses) in a time window and trigger when there are too many. <a href="http://manual.snort.org/node78.html">Snort's sfPortscan</a> preprocessor is a good study in this kind of heuristic detection.<br />
<br />
<b>UDP payloads. </b>UDP port scanning is tricky, since there's no guarantee that a listening service will respond to an empty packet; in fact, most will not. For this reason, Nmap sends <a href="https://nmap.org/book/nmap-payloads.html">special data payloads</a> to some well-known ports to try to get a real response. These payloads are static, and could be used to identify Nmap. Some, like the SNMP version 1 query with the "public" community string, trigger <a href="https://www.snort.org/rule-docs/1411">IDS alerts</a> that are intended to catch generic bad behavior, which have no idea they've caught Nmap.<br />
<br />
<b>Service probes.</b> Nmap's service probes are similar to the UDP payloads, but there are more of them and they get sent to more ports, both TCP and UDP. Some of them are highly Nmap-specific, including an SSL probe with a static (old!) date and a SIP probe that identifies itself as Nmap.<br />
<br />
<b>NSE behaviors. </b>Nmap Scripting Engine (NSE) scripts are great gatherers of information, but they don't do a great job of hiding what they are doing. The <a href="https://nmap.org/nsedoc/lib/http.html#script-args">HTTP scripts all use a User-Agent header</a> that identifies as "Nmap Scripting Engine." Not to mention that any of the brute-force or exploit scripts will naturally be detected as those specific attacks.<br />
<br />
<b><a href="http://blog.bonsaiviking.com/2015/07/they-see-me-scannin-part-2.html">Next</a></b>: some Nmap options to reduce the impact of these detection techniques.<br />
<ol>
</ol>
<ul>
</ul>
Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com2tag:blogger.com,1999:blog-9089043401683364319.post-67814774113481375792013-04-04T15:14:00.001-07:002013-04-04T15:14:24.802-07:00Kill geoclue, but keep your clockUbuntu 12.04 with Unity has only one clock, and that clock requires a GeoIP provider called geoclue:<br />
<br />
<pre>Package: indicator-datetime
New: yes
State: installed
Automatically installed: no
Version: 0.3.94-0ubuntu2
Priority: optional
Section: misc
Maintainer: Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com>
Architecture: i386
Uncompressed Size: 319 k
Depends: gconf-service, libc6 (>= 2.7), libcairo2 (>= 1.10), libdbusmenu-glib4
(>= 0.4.2), libdbusmenu-gtk3-4 (>= 0.4.2), libecal-1.2-10 (>= 3.2.3),
libedataserver-1.2-15 (>= 3.2.3), libedataserverui-3.0-1 (>= 3.2.3),
libgconf-2-4 (>= 2.31.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libgeoclue0
(>= 0.11.1+git20091217), libglib2.0-0 (>= 2.29.19),
libgnome-control-center1 (>= 1:2.91.2), libgtk-3-0 (>= 3.1.4), libical0
(>= 0.30), libido3-0.1-0 (>= 0.2.2), libindicator3-7, libpango1.0-0 (>=
1.18.0), libpolkit-gobject-1-0 (>= 0.99), libtimezonemap1,
dconf-gsettings-backend | gsettings-backend, gnome-control-center,
geoclue-ubuntu-geoip | geoclue-provider
Recommends: indicator-applet | indicator-renderer, evolution-data-server
Description: Simple clock
A simple clock appearing in the indicator bar
Homepage: https://launchpad.net/indicator-datetime</pre>
<br />
Geoclue calls home to geoip.ubuntu.com, as pointed out in this helpful <a href="http://ubuntuforums.org/showthread.php?t=2000108">Ubuntuforums thread</a>. Luckily, this is easy to neuter. The thread says you need to recompile indicator-datetime, but that's overkill. We just need a package that "provides" geoclue-provider.<br />
<br />
<a href="http://asic-linux.com.mx/~izto/checkinstall/">Checkinstall</a> is a great tool for building mostly-working packages from source trees. It can build RPM, Slackware, and Debian packages, and on Ubuntu, it's as easy as <code>aptitude install checkinstall</code>. Now we just need a source tree.<br />
<br />
<pre>mkdir /tmp/geoclue-provider-1
</pre>
<br />
That was easy. Now to "make" and install our package. Checkinstall defaults to running "make install," but you can specify any other command on the command line. You'll have to answer some prompts to be sure that your "package" will work like we want:<br />
<br />
<pre>miller@danbuntu:/tmp/geoclue-provider-1$ sudo checkinstall ls
checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
This software is released under the GNU GPL.
The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs? [y]: n
Please write a description for the package.
End your description with an empty line or EOF.
>> geoclue killer
>>
*****************************************
**** Debian package creation selected ***
*****************************************
This package will be built according to these values:
0 - Maintainer: [ root@danbuntu ]
1 - Summary: [ geoclue killer ]
2 - Name: [ geoclue-provider ]
3 - Version: [ 1 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ checkinstall ]
7 - Architecture: [ i386 ]
8 - Source location: [ geoclue-provider-1 ]
9 - Alternate source location: [ ]
10 - Requires: [ ]
11 - Provides: [ geoclue-provider ]
12 - Conflicts: [ ]
13 - Replaces: [ ]
Enter a number to change any of them or press ENTER to continue:
Installing with ls...
========================= Installation results ===========================
description-pak
======================== Installation successful ==========================
cp: cannot stat `//var/tmp/tmp.XZZzyKCsmE/newfiles.tmp': No such file or directory
Copying files to the temporary directory...OK
Stripping ELF binaries and libraries...OK
Compressing man pages...OK
Building file list... FAILED!
Building Debian package...OK
Installing Debian package...OK
Erasing temporary files...OK
Deleting temp dir...OK
**********************************************************************
Done. The new package has been installed and saved to
/tmp/geoclue-provider-1/geoclue-provider_1-1_i386.deb
You can remove it from your system anytime using:
dpkg -r geoclue-provider
**********************************************************************</pre>
<br />
Now you are free to remove the offending package:<br />
<br />
<pre>aptitude purge geoclue-ubuntu-geoip</pre>
<br />
Yay.Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com2tag:blogger.com,1999:blog-9089043401683364319.post-23363647819854823032013-03-05T11:56:00.003-08:002022-03-18T16:58:49.933-07:00NfSpy meets the real worldRecently, <a href="http://www.room362.com/">Rob Fuller</a> a.k.a. <a href="http://www.twitter.com/mubix">mubix</a> posted a how-to for <a href="http://www.room362.com/blog/2013/3/4/mounting-nfs-shares-through-meterpreter-with-nfspy.html">using NfSpy through a Meterpreter pivot</a>. It's always nice to see your tools being used in the real world, and mubix's writeup was detailed and straightforward. It was clear, however, that NfSpy is not as user-friendly as I had hoped. I'll try to address some shortfalls in this post, which may also serve as a roadmap for further development.<br />
<br />
<a name='more'></a><br />
<blockquote class="tr_bq">
While [NfSpy's] original intent was aide in bypassing NFS security controls
it has the right amount of options to make mounting NFS over Meterpreter
possible.</blockquote>
One of the security controls that NfSpy can't bypass also makes using a proxy difficult, and it's turned on by default in almost every instance. The <a href="http://linux.die.net/man/5/exports">exports</a> setting is called <code>secure</code>, and it explicitly rejects connections coming from source ports greater than 1024. In most operating systems, this means that the client process must be running with root privilege. It's no big deal to run NfSpy as root, but I don't know of a good way to convince a proxy to use a specific source port for outgoing connections.<br />
<br />
I specifically put the <code>mountport</code> and <code>nfsport</code> options in to make bypassing network boundaries possible. Many organizations block port 111, because all the standard RPC tools use the portmapper to discover what ports to contact. But as anyone who has used a port scanner can tell you, the portmapper is not the only way to find open ports!<br />
<blockquote class="tr_bq">
<pre>msf > use auxiliary/scanner/nfs/nfsmount</pre>
<pre>msf > use auxiliary/scanner/misc/sunrpc_portmapper</pre>
</blockquote>
So mubix uses some nice Metasploit auxiliary modules to enumerate the exports and RPC ports on the remote system. For directly-connected systems, the standard <a href="http://linux.die.net/man/8/showmount">showmount</a> and <a href="http://linux.die.net/man/8/rpcinfo">rpcinfo</a> commands work great, but they can't be easily forced to use TCP, which makes proxying difficult. There is another option, though. <a href="http://nmap.org/">Nmap</a> has a collection of <a href="http://nmap.org/nsedoc/">NSE scripts</a> that work great for discovering RPC information, and they can be proxied with proxychains. Here's how I would have done it:<br />
<br />
<pre># proxychains nmap -p 111 --script <a href="http://nmap.org/nsedoc/scripts/rpcinfo.html">rpcinfo</a>,<a href="http://nmap.org/nsedoc/scripts/nfs-showmount.html">nfs-showmount</a> 192.168.1.50</pre>
<pre><snip> </pre>
<pre>PORT STATE SERVICE
111/tcp open rpcbind
| nfs-showmount:
| /home 192.168.1.0/255.255.255.0</pre>
<pre>|_ /volume/users 192.168.1.0/255.255.255.0 </pre>
<pre>| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/udp nfs
| 100005 1,2,3 37719/tcp mountd
| 100005 1,2,3 52569/udp mountd
| 100021 1,3,4 54167/udp nlockmgr
| 100021 1,3,4 38216/tcp nlockmgr
| 100024 1 55731/tcp status
| 100024 1 46797/udp status</pre>
<pre>| 100227 3 2049/tcp nfs_acl
|_ 100227 3 2049/udp nfs_acl
</pre>
<br />
Note that this shows the versions of each service, too. For any given NFS version (NfSpy works with version 3), you must use the mountd service with a version 1 less (mountd version 2, in this case). I'm guessing that all the extra mountd ports in mubix's output represent different versions of the mount protocol.<br />
<blockquote class="tr_bq">
proxychains nfspy -d -o server=192.168.1.50:/home,nfsport=2049/tcp,mountport=37719/tcp,rw /root/nfspy/mount</blockquote>
These options can be placed in any order. This command is equivalent:<br />
<br />
<pre>proxychains nfspy /root/nfspy/mount -o server=192.168.1.50:/home,nfsport=2049/tcp,rw,mountport=37719/tcp -d</pre>
<br />
The trick of finding the proper nfs and mount ports is actually unnecessary in this case; since the proxy forwards all TCP traffic, all that is required is to tell NfSpy to use TCP for both mounting and NFS communication. It will then use TCP to connect to the RPC portmapper and pull the proper ports for you. So here's the modified command:<br />
<br />
<pre>proxychains nfspy -d -o server=192.168.1.50:/home,nfsport=tcp,mountport=tcp,rw /root/nfspy/mount</pre>
<br />
<blockquote class="tr_bq">
NfSpy uses fuse which can be really silent when problems arise or give
errors that tell you nothing meaningful. That's why I'm using the -d
option that keeps nfspy in the foreground, just so I can detect any
issues.</blockquote>
This issue has been a thorn in my side regarding FUSE (Filesystem in USErspace, a Linux kernel plugin and API). In reality, the problem is with the Python bindings, and perhaps someone has an answer to the problem of properly reporting fsinit failures. I know I could do a little better, but without a proper way of doing it, I just don't have the motivation.<br />
<blockquote class="tr_bq">
Last note, you can't just CTRL-C an nfspy mount, you need to use
`fusermount -u /root/nfspy/mount` to kill it. It's another fuse issue.
If anyone has a better way to do this I'm all ears.</blockquote>
This is a byproduct of the <code>-d</code> flag. If that wasn't being used, then the process would background, and you'd just be left with a mounted directory. fusermount is the program used to unmount FUSE filesystems. Another bug here is that unmounting may not kill the python process either. After I've been testing for a while, I usually have to grep out the process ids and kill -9 them manually.<br />
<br />
Given all the problems with FUSE, you might think it's a steaming pile. On the contrary, the library is great, and lets you create filesystem interfaces for just about anything. I was amazed at how fast NfSpy came together, first as a read-only tool to bypass UID-checking, then as a full-featured NFS client. But the next major milestone for its development will be completely divorcing it from FUSE so that it can be used on Windows, BSD, OS X, and anywhere Python can run. Already, the NfSpy class that handles most of the NFS protocol is separate from the Fuse class that provides the filesystem interface. All that is needed is a readline shell, and to implement some useful commands. I envision something like a FTP client interface: get, put, cd, ls. Suggestions and code contributions can be made on <a href="https://github.com/bonsaiviking/NfSpy">the project's Github page</a>, where you can also get the program itself. <div><br /></div><div>EDIT: I added <span style="font-family: courier;">nfspysh</span><span style="font-family: inherit;"> in 2013, which does not require FUSE. It works great on Windows!</span></div>Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-84949288765460939652012-09-07T12:03:00.000-07:002012-09-07T12:03:03.093-07:00Fixing Metasploit's AXFR supportDNS zone transfers (AXFR requests) are a great source of information about a network, allowing an "interested party" access to all the records on a DNS server. Robin Wood has offered a great resource to the community in the form of <a href="http://www.digininja.org/projects/zonetransferme.php">zonetransfer.me</a>, a domain that allows zone transfers for testing purposes. Here's what it looks like:<br />
<br />
<pre>me@here:~$ dig +short zonetransfer.me NS
ns12.zoneedit.com.
ns16.zoneedit.com.
me@here:~$ dig @ns12.zoneedit.com. zonetransfer.me AXFR
; <<>> DiG 9.8.1-P1 <<>> @ns12.zoneedit.com. zonetransfer.me AXFR
; (1 server found)
;; global options: +cmd
zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2012272996 2400 360 1209600 300
zonetransfer.me. 7200 IN NS ns16.zoneedit.com.
zonetransfer.me. 7200 IN NS ns12.zoneedit.com.
zonetransfer.me. 7200 IN A 217.147.180.162
zonetransfer.me. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.
zonetransfer.me. 301 IN TXT "Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes"
zonetransfer.me. 301 IN TXT "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me.
164.180.147.217.in-addr.arpa.zonetransfer.me. 7200 IN PTR www.zonetransfer.me.
ipv6actnow.org.zonetransfer.me. 7200 IN AAAA 2001:67c:2e8:11::c100:1332
asfdbauthdns.zonetransfer.me. 7900 IN AFSDB 1 asfdbbox.zonetransfer.me.
office.zonetransfer.me. 7200 IN A 4.23.39.254
owa.zonetransfer.me. 7200 IN A 207.46.197.32
info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin Wood - robin@digininja.org. See www.digininja.org/projects/zonetransferme.php for more information."
asfdbbox.zonetransfer.me. 7200 IN A 127.0.0.1
canberra_office.zonetransfer.me. 7200 IN A 202.14.81.230
asfdbvolume.zonetransfer.me. 7800 IN AFSDB 1 asfdbbox.zonetransfer.me.
email.zonetransfer.me. 2222 IN NAPTR 1 1 "" "E2U+email" "" email.zoneedit.com.zonetransfer.me.
dzc.zonetransfer.me. 7200 IN TXT "AbCdEfG"
rp.zonetransfer.me. 321 IN RP robin.zonetransfer.me.zonetransfer.me. robinwood.zonetransfer.me.
dr.zonetransfer.me. 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m
sip.zonetransfer.me. 3333 IN NAPTR 2 3 "au" "E2U+sip" "!^.*$!sip:customer-service@zonetransfer.me!" .
alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A 127.0.0.1
www.zonetransfer.me. 7200 IN A 217.147.180.162
staging.zonetransfer.me. 7200 IN CNAME www.sydneyoperahouse.com.
deadbeef.zonetransfer.me. 7201 IN AAAA dead:beaf::
robinwood.zonetransfer.me. 302 IN TXT "Robin Wood"
vpn.zonetransfer.me. 4000 IN A 174.36.59.154
_sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me.
dc_office.zonetransfer.me. 7200 IN A 143.228.181.132
zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2012272996 2400 360 1209600 300
;; Query time: 61 msec
;; SERVER: 209.62.64.46#53(209.62.64.46)
;; WHEN: Wed Sep 5 17:12:42 2012
;; XFR size: 37 records (messages 37, bytes 2673)
</pre>
<br />
I had previously used this service to <a href="http://seclists.org/nmap-dev/2012/q3/128">update</a> Nmap's <a href="http://nmap.org/nsedoc/scripts/dns-zone-transfer.html">dns-zone-transfer</a> NSE script, so I thought similar updates would be a simple place to start with Metasploit development. Unfortunately (or fortunately!) I ran into a road block: Zone transfers were <a href="https://dev.metasploit.com/redmine/issues/507">broken</a> in Metasploit!<br />
<br />
The module in question was <a href="http://www.metasploit.com/modules/auxiliary/gather/enum_dns">auxiliary/gather/enum_dns</a>, which has lots of other good DNS enumeration functions besides AXFR. The underlying problem, though was a problem with the <a href="https://github.com/bluemonk/net-dns">Net::DNS</a> library that Metasploit uses. First, a little about how AXFR transactions work:<br />
<br />
DNS usually works over UDP, fitting an entire response into a single packet. For zone transfers, though, responses can be much larger. Since zone transfers are used for synchronizing DNS servers, ensuring that no data is lost is critical. For this reason, AXFR transactions are conducted over TCP.<br />
<br />
Most DNS transactions involve a single request with a Questions section being answered by a single response with an Answers section (among other sections). AXFR is different; since it has to transfer an entire zone, the server responds with a series of DNS responses, each of which contains some number of Answers. The responses begin with the Start Of Authority (SOA) record for the zone, and end with the same record.<br />
<br />
Now we come to the broken part. Net::DNS (and Metasploit by extension) was smart enough to switch to TCP when an AXFR request was passed, but it only read the first response. Modifying the method to loop until 2 SOA messages had been seen was a fun exercise in Ruby that I may write about another time. In the meantime, you could check out the <a href="https://github.com/rapid7/metasploit-framework/commit/2edf4a676a2f5c44b24818ee5200b502924ea6fd">commit diff</a>. Here's how it looks now:<br />
<br />
<pre>msf > use auxiliary/gather/enum_dns
msf auxiliary(enum_dns) > show options
Module options (auxiliary/gather/enum_dns):
Name Current Setting Required Description
---- --------------- -------- -----------
DOMAIN yes The target domain name
ENUM_AXFR true yes Initiate a zone transfer against each NS record
ENUM_BRT false yes Brute force subdomains and hostnames via the supplied wordlist
ENUM_IP6 false yes Brute force hosts with IPv6 AAAA records
ENUM_RVL false yes Reverse lookup a range of IP addresses
ENUM_SRV true yes Enumerate the most common SRV records
ENUM_STD true yes Enumerate standard record types (A,MX,NS,TXT and SOA)
ENUM_TLD false yes Perform a TLD expansion by replacing the TLD with the IANA TLD list
IPRANGE no The target address range or CIDR identifier
NS no Specify the nameserver to use for queries (default is system DNS)
STOP_WLDCRD false yes Stops bruteforce enumeration if wildcard resolution is detected
WORDLIST /redacted/file.txt no Wordlist for domain name bruteforcing
msf auxiliary(enum_dns) > set ENUM_SRV false
ENUM_SRV => false
msf auxiliary(enum_dns) > set ENUM_STD false
ENUM_STD => false
msf auxiliary(enum_dns) > set DOMAIN zonetransfer.me
DOMAIN => zonetransfer.me
msf auxiliary(enum_dns) > run
[*] Setting DNS Server to zonetransfer.me NS: 69.64.68.41
[*] Performing zone transfer against all nameservers in zonetransfer.me
[*] Testing nameserver: ns16.zoneedit.com.
AXFR query, switching to TCP
Error parsing axfr response: uninitialized constant Net::DNS::RR::AFSDB
Error parsing axfr response: uninitialized constant Net::DNS::RR::AFSDB
Error parsing axfr response: uninitialized constant Net::DNS::RR::NAPTR
Error parsing axfr response: uninitialized constant Net::DNS::RR::RP
Error parsing axfr response: uninitialized constant Net::DNS::RR::LOC
Error parsing axfr response: uninitialized constant Net::DNS::RR::NAPTR
[*] Zone transfer successful
[*] Name: ns16.zoneedit.com. Record: SOA
[*] Name: ns16.zoneedit.com. Record: NS
[*] Name: ns12.zoneedit.com. Record: NS
[*] Name: zonetransfer.me. IP address: 217.147.180.162 Record: A
[*] Name: ASPMX.L.GOOGLE.COM. Preference: 0 Record: MX
[*] Name: ALT1.ASPMX.L.GOOGLE.COM. Preference: 10 Record: MX
[*] Name: ALT2.ASPMX.L.GOOGLE.COM. Preference: 10 Record: MX
[*] Name: ASPMX2.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX3.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX4.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX5.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Text: zonetransfer.me. 301 IN TXT
[*] Text: zonetransfer.me. 301 IN TXT
[*] Name: www.zonetransfer.me. Record: CNAME
[*] IPv6 Address: 2001:67c:2e8:11::c100:1332 Record: AAAA
[*] Name: office.zonetransfer.me. IP address: 4.23.39.254 Record: A
[*] Name: owa.zonetransfer.me. IP address: 207.46.197.32 Record: A
[*] Text: info.zonetransfer.me. 7200 IN TXT
[*] Name: asfdbbox.zonetransfer.me. IP address: 127.0.0.1 Record: A
[*] Name: canberra_office.zonetransfer.me. IP address: 202.14.81.230 Record: A
[*] Text: dzc.zonetransfer.me. 7200 IN TXT
[*] Name: alltcpportsopen.firewall.test.zonetransfer.me. IP address: 127.0.0.1 Record: A
[*] Name: www.zonetransfer.me. IP address: 217.147.180.162 Record: A
[*] Name: www.sydneyoperahouse.com. Record: CNAME
[*] IPv6 Address: dead:beaf:: Record: AAAA
[*] Text: robinwood.zonetransfer.me. 302 IN TXT
[*] Name: vpn.zonetransfer.me. IP address: 174.36.59.154 Record: A
[*] Host: www.zonetransfer.me. Port: 5060 Priority: 0 Record: SRV
[*] Name: dc_office.zonetransfer.me. IP address: 143.228.181.132 Record: A
[*] Testing nameserver: ns12.zoneedit.com.
AXFR query, switching to TCP
Error parsing axfr response: uninitialized constant Net::DNS::RR::AFSDB
Error parsing axfr response: uninitialized constant Net::DNS::RR::AFSDB
Error parsing axfr response: uninitialized constant Net::DNS::RR::NAPTR
Error parsing axfr response: uninitialized constant Net::DNS::RR::RP
Error parsing axfr response: uninitialized constant Net::DNS::RR::LOC
Error parsing axfr response: uninitialized constant Net::DNS::RR::NAPTR
[*] Zone transfer successful
[*] Name: ns16.zoneedit.com. Record: SOA
[*] Name: ns16.zoneedit.com. Record: NS
[*] Name: ns12.zoneedit.com. Record: NS
[*] Name: zonetransfer.me. IP address: 217.147.180.162 Record: A
[*] Name: ASPMX.L.GOOGLE.COM. Preference: 0 Record: MX
[*] Name: ALT1.ASPMX.L.GOOGLE.COM. Preference: 10 Record: MX
[*] Name: ALT2.ASPMX.L.GOOGLE.COM. Preference: 10 Record: MX
[*] Name: ASPMX2.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX3.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX4.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Name: ASPMX5.GOOGLEMAIL.COM. Preference: 20 Record: MX
[*] Text: zonetransfer.me. 301 IN TXT
[*] Text: zonetransfer.me. 301 IN TXT
[*] Name: www.zonetransfer.me. Record: CNAME
[*] IPv6 Address: 2001:67c:2e8:11::c100:1332 Record: AAAA
[*] Name: office.zonetransfer.me. IP address: 4.23.39.254 Record: A
[*] Name: owa.zonetransfer.me. IP address: 207.46.197.32 Record: A
[*] Text: info.zonetransfer.me. 7200 IN TXT
[*] Name: asfdbbox.zonetransfer.me. IP address: 127.0.0.1 Record: A
[*] Name: canberra_office.zonetransfer.me. IP address: 202.14.81.230 Record: A
[*] Text: dzc.zonetransfer.me. 7200 IN TXT
[*] Name: alltcpportsopen.firewall.test.zonetransfer.me. IP address: 127.0.0.1 Record: A
[*] Name: www.zonetransfer.me. IP address: 217.147.180.162 Record: A
[*] Name: www.sydneyoperahouse.com. Record: CNAME
[*] IPv6 Address: dead:beaf:: Record: AAAA
[*] Text: robinwood.zonetransfer.me. 302 IN TXT
[*] Name: vpn.zonetransfer.me. IP address: 174.36.59.154 Record: A
[*] Host: www.zonetransfer.me. Port: 5060 Priority: 0 Record: SRV
[*] Name: dc_office.zonetransfer.me. IP address: 143.228.181.132 Record: A
[*] Auxiliary module execution completed
msf auxiliary(enum_dns) >
</pre>
<br />
See all the parsing errors? That's what I intended to fix when I started. Well, no time like the present!Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-36022922268370094112012-08-15T04:22:00.000-07:002012-08-15T04:23:50.498-07:00XML output for Nmap's NSE scriptsThe <a href="http://nmap.org/book/nse.html">Nmap Scripting Engine</a> (NSE) is a great feature of <a href="http://nmap.org/">Nmap</a> that turns it into a data-collecting, banner-grabbing, vulnerability-scanning, exploit-finding platform. It gathers information like SSL certs, enumerates users, brute-forces authentication, exploits back-doors, spiders websites, and more. But though Nmap's port scan, version detection, and OS fingerprinting output all have their own elements in Nmap's <a href="http://nmap.org/book/output-formats-xml-output.html">XML output</a>, NSE script output has been stored in a blob of text, formatted in any arbitrary fashion, and shoved into the <code>output</code> attribute of the <code><script></code> element.<br />
<br />
For the last year, I've been working on various prototypes of structured output for NSE scripts. The long and sordid history is mostly traced out on <a href="https://secwiki.org/w/Nmap/Structured_Script_Output">this SecWiki page</a>, but after many rewrites, forks, and the closest thing I've seen to a flame war within the Nmap family, the functionality was finally <a href="http://seclists.org/nmap-dev/2012/q3/572">merged into the trunk in r29570</a>!<br />
<br />
The basic idea is that NSE scripts can now return a data structure in addition to or instead of the usual string output, and that data structure will be recursively converted into XML. What follows is my attempt at pulling together into one place the way the system works and how it is supposed to be used.<br />
<br />
<h3>
What it does</h3>
The NSE engine converts Lua data structures into XML using a recursive algorithm. Lua really only has one data structure, <a href="http://lua-users.org/wiki/TablesTutorial">the table</a>, which can be used to represent arrays/lists and associative arrays/hashes/hashmaps. The only difference is whether the indices are integers (array) or any other value (hash). In keeping with this simplicity, the XML output consists of only 2 new elements: <code><table></code> and <code><elem></code>, each of which can have a <code>key</code> attribute. The string version of the output is still kept in the <code>output</code> attribute of the <code><script></code> element. A good explanation of this is given in the <a href="http://nmap.org/book/nse-api.html#nse-structured-output">NSE API section</a> of the Nmap documentation.<br />
<br />
<h3>
How to use it</h3>
There are basically 4 ways to return output under the new system:<br />
<br />
<h4>
1. Plain string output (ye Olde Way)</h4>
The new system is completely backwards compatible, so your old scripts will work just fine. The string output will continue to be put into the <code>output</code> attribute of the script tag, but no new XML will be generated.<br />
<br />
<h4>
2. Automatically-stringified output</h4>
As your script executes, build a table of output elements, then return that. NSE will automatically create a string output with indentation, "key: value" pairs, and newline-separated lists. This is the easiest way to get XML output, but it can take up some extra screen real estate, since each element of output is displayed on its own line in the Normal output.<br />
<br />
<h4>
3. Structured AND string output</h4>
Your script can return 2 values: a table to be converted into XML, and a string to use for Normal output. It's best if these contain the same information, but the XML must never contain less information than the string output. This is a handy method for wordy output containing explanations of what's been discovered; this information isn't needed in machine-readable XML.<br />
<br />
<h4>
4. Self-stringifying output</h4>
Your script can return a table that contains its own instructions for turning it into a string. This is done by overriding the <a href="http://www.lua.org/manual/5.2/manual.html#pdf-tostring"><code>__tostring</code></a> <a href="http://www.lua.org/manual/5.2/manual.html#2.4">metamethod</a> for the table or any of the nested tables within it. If this sounds confusing, don't worry. I'll be adding a formatting library that hides all this Lua meta-magic behind easy-to-use function calls. The underlying functionality will be the same, though. This method is useful for scripts that want to take advantage of the outline-flavored stringification of option (2) for much of their output, but have special formatting needs for subsections, like a file listing (tabular output) or a horizontal, comma-separated list. This also helps ensure that the XML and string outputs both contain the same information.<br />
<br />
<h3>
Tips for script authors</h3>
Changing the way things work can be confusing. Here are some tips to help you write scripts that work well with XML script output:<br />
<ul>
<li>Use stdnse.output_table() to create a table that remembers the order you assigned keys. Regular Lua tables order their keys in an unpredictable way.</li>
<li>Break down your data into the smallest reasonable chunks. If your script returns a username/domain combination, return it as <code>{username="joe", domain="EXAMPLECOM"}</code> instead if simply <code>{username="EXAMPLECOM\joe"}</code>.</li>
<li>Make sure your script returns <code>nil</code> when you don't want output. Returning <code>false</code> used to work, but now it will show up as "false".</li>
<li>Use the automatic stringification (option 2 above) for testing. Choose one of the other options once you know what output you want, and only if the default doesn't look right.</li>
</ul>
Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-79235190119899046762012-07-20T10:02:00.001-07:002012-07-20T10:02:26.703-07:00Disable NFSv2 on Debian/UbuntuThese instructions apply to the <a href="http://packages.ubuntu.com/lucid/nfs-kernel-server">nfs-kernel-server</a> package on Ubuntu 10.04 LTS and 12.04 LTS, and probably apply to various Debian versions as well.<br />
<br />
The kernel NFS server is called rpc.nfsd, so its options are documented in the <a href="http://linux.die.net/man/8/rpc.nfsd">rpc.nfsd(8) man page</a>. To turn off specific versions of NFS, pass the <code>-N</code> or <code>--no-nfs-version</code> argument to this daemon, as well as the rpc.mountd daemon. The accepted config file to do this is <code>/etc/default/nfs-kernel-server</code>.<br />
<br />
For Ubuntu 12.04, there is a rather obviously-named variable, <code>RPCNFSDARGS</code>, that can be set to pass arguments to rpc.nfsd. Here's one for turning off NFSv2:<br />
<br />
<pre>RPCNFSDARGS="-N 2"</pre>
<br />
On Ubuntu 10.04, there is no such variable, and creating it does nothing, since the init script (/etc/init.d/nfs-kernel-server) does not reference it. Instead, the <code>RPCNFSDCOUNT</code> variable can be used, since it is passed to the rpc.nfsd as well. Here's how to do the same thing on 10.04:<br />
<br />
<pre>RPCNFSDCOUNT="-N 2 8"</pre>
<br />
Remember to keep the "8" (or whatever you choose to set it to).<br />
<br />
For both versions, setting the <code>RPCMOUNTDOPTS</code> variable the same way is recommended, so that clients don't mount the wrong version of your exports:<br />
<br />
<pre>RPCMOUNTDOPTS="-N 2 --manage-gids"</pre>Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-89098246336690570332012-07-13T17:42:00.003-07:002012-07-13T17:42:19.236-07:00Do it faster Makes us stronger<h4>
What</h4>
Improvements to Nmap's <a href="http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html">ssl-enum-ciphers</a> NSE script.<br />
<h4>
Who</h4>
Me! Original script by Mak Kolybabi and Gabriel Lawrence. Workaround for Microsoft servers discovered by Martyn Tovey.<br />
<h4>
Why</h4>
Secure Sockets Layer and <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security">Transport Layer Security</a> (hereinafter called SSL) are protocols for using various hashing and encryption algorithms to provide a secure, mutually authenticated channel for communication between computer systems. By design, the particular algorithms used are pluggable; the client and the server decide between themselves which ones to use for any particular communication. But not all algorithms are created equal, and some are <a href="http://www.openssl.org/docs/apps/ciphers.html#item_eNULL">deliberately neutered</a> for testing purposes, or to avoid <a href="https://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States" style="outline-offset: 0px; outline: 1px dotted;">export restrictions on cryptography.</a><br />
<br />
If a client and a server both support some weak encryption algorithm, they may still never use it if they both favor a strong one they also share. Unfortunately, the decision of which algorithm to choose is neither encrypted nor authenticated, so an attacker in a <a href="https://www.owasp.org/index.php/Man-in-the-middle_attack">man-in-the-middle</a> scenario can perform a downgrade attack, reducing security to the least-strong combination of algorithms, to even include unauthenticated or do-nothing encryption. Server admins, security teams, and penetration testers need a way to determine which servers on a network may be vulnerable to this type of attack.<br />
<br />
Enter <a href="http://nmap.org/">Nmap</a>. Since version 5.30BETA1 (2010-03-29), Nmap has included a script for enumerating the algorithms for each of the 4 modern versions of SSL (SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2). The mechanism this script uses (also used by <a href="http://sourceforge.net/projects/sslscan/">sslscan</a> and other tools) is simple: for each of the 4 SSL versions, try each of the <a href="https://www.iana.org/assignments/tls-parameters/tls-parameters.xml">213 cipher suites</a> (combinations of hashing algorithm, encryption algorithm, key exchange algorithm, and cipher mode) and report back which ones succeeded. That's 4*213=852 exchanges between client and server, no matter how many SSL versions or cipher suites each uses. A run against 30 HTTPS servers on the Internet took me 9.5 minutes. That's slow, especially considering each bunch of 213 cipher suites is tested in parallel. I was sure there had to be a better way.<br />
<h4>
How</h4>
In the <a href="https://tools.ietf.org/html/rfc6101">SSL protocol</a>, the first message sent is from the client, the Client Hello message. It contains a list of cipher suites supported, as well as other information. The Server Hello message sent in reply contains one cipher suite (usually the strongest) that the server shares with the client. The protocol spec allows up to 2^16-1 cipher suites to be sent in the one Client Hello message.<br />
<br />
Removing the multithreading code temporarily, I changed the script to follow this algorithm:<br />
<ol>
<li>Send a Client Hello with <i>all</i> the cipher suites we wish to enumerate. </li>
<li>When the server responds with one, end the connection. </li>
<li>Remove and record the chosen suite, and send a new Client Hello with the remaining cipher suites. </li>
<li>Repeat until the server sends a handshake failure message, indicating that it supports none of the remaining suites.</li>
</ol>
<br />
This worked great! Instead of 213 exchanges, only 1 plus the number of valid cipher suites were performed. Usually this number is between 3 and 16 (most commonly 6, 7, or 8). Moving the threading code to run each protocol in parallel, scan times reduced by two-thirds or more. I cleaned up the code and sent it in to the development mailing list for comment.<br />
<br />
The idea is not new: the original author of the script, Mak Kolybabi, implemented <a href="http://seclists.org/nmap-dev/2010/q1/631">a very similar idea</a> before the final version was added, but scrapped it due to <a href="http://seclists.org/nmap-dev/2010/q1/859">inconsistent results</a>. Unfortunately, comments from the mailing list revealed that my version of the script was faring no better. Specifically, Windows systems running IIS tended to show only 1 or 2 ciphers supported, when previously they had shown 6 or more. Examining the traffic, I found that the server was terminating the underlying TCP connection with a RST, with no handshake failure to show what might be wrong.<br />
<br />
At this point, Martyn sent me a message with the key to the problem: contrary to the protocol spec, some servers only look at the first 64 cipher suites, rejecting or ignoring any higher number. Rushing back to the script, I quickly broke up the scan into 64-suite chunks. Success! This added an extra 3 exchanges per valid protocol, but that's a small price to pay for the overall speedup.<br />
<h4>
When</h4>
The new version of the script was committed to Nmap's Subversion repository in r29206. It should be compatible with the latest release (version 6.01, <a href="http://nmap.org/download.html">available here</a>), so you can <a href="http://nmap.org/svn/scripts/ssl-enum-ciphers.nse">download it directly</a> without recompiling Nmap. Bonus in this update: 147 new cipher suites to check for! With the new script it still comes out faster than the old method. Happy hunting!Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-54968249076166015612012-06-26T10:14:00.000-07:002012-06-26T10:14:24.067-07:00My format: GuardianI come from the Net - through systems, peoples, and cities - to this
place: MAINFRAME. My format: Guardian. To mend and defend - to defend my
new found friends, their hopes and dreams, and to defend them from
their enemies. They say The User lives outside the Net and inputs games
for pleasure. No one knows for sure, but I intend to find out. <a href="http://reboot.wikia.com/wiki/ReBoot_Wiki">ReBoot!</a>Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-41495798372223934272012-06-18T10:14:00.000-07:002017-05-17T19:32:50.206-07:00Hacking, Hollywood styleDear Hollywood,<br />
<br />
The following images and videos do not depict hacking, or even a plausibly realistic use of computers. I laughed, I cried, I wished I was watching something else.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/u8qgehH3kEQ?feature=player_embedded' frameborder='0'></iframe></div>
"One keyboard four hands" is for piano, not computers.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/hkDD03yeLnU?feature=player_embedded' frameborder='0'></iframe></div>
"I'll spout a bunch of fancy words I don't understand, see if I can replicate a capability we should already have."<br />
<br />
<i>Edit: video removed due to copyright. <a href="http://www.imdb.com/title/tt2076424/">"The Crack In The Code" episode of "Bones"</a></i> featured a "fractal code" etched into a bone that when scanned caused the analyst's computer to burst into flames. There's so much wrong with this, I have to limit myself to just one: Computers don't catch fire from viruses. Period.<br />
<br />
Watching a film or TV show shouldn't require me to ignore everything I know about computers.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2l_BZ6BrHk-5TWjr05fmvbtnWTUv_RuCfGCBwEwL78zCzlotvyljNsoVTlgAu-suq-9zpFsSiaHHj-VfmBSbcOfheRUA9W7PFN8g-XUNXE3zDw_Uppt1Z-9wLHb99nY6Iq6_YBO7JEl0/s1600/217521921_7GXmh-L-2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2l_BZ6BrHk-5TWjr05fmvbtnWTUv_RuCfGCBwEwL78zCzlotvyljNsoVTlgAu-suq-9zpFsSiaHHj-VfmBSbcOfheRUA9W7PFN8g-XUNXE3zDw_Uppt1Z-9wLHb99nY6Iq6_YBO7JEl0/s1600/217521921_7GXmh-L-2.jpg" /></a></div>
(Image credit <a href="http://www.penny-arcade.com/comic/2007/07/16">Penny Arcade</a>)<br />
<br />
In closing, <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3Td_jDZAEd0QRysoR2vZd-ZqwXmQVdn8T95z_NMx4UlBjHeda6U_BXU-SMxT02Hq1tBV9kC2pKk3TbOoWtzWtswkeGKuP6aqZBfO54LoIiPCRxym0wbqXc14tVVHLD_RK82gtdJGBH4/s1600/20120220.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv3Td_jDZAEd0QRysoR2vZd-ZqwXmQVdn8T95z_NMx4UlBjHeda6U_BXU-SMxT02Hq1tBV9kC2pKk3TbOoWtzWtswkeGKuP6aqZBfO54LoIiPCRxym0wbqXc14tVVHLD_RK82gtdJGBH4/s1600/20120220.gif" /></a></div>
(Image credit <a href="http://www.smbc-comics.com/index.php?db=comics&id=2526">Saturday Morning Breakfast Cereal</a>)Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-61070327050744734382012-06-04T08:40:00.000-07:002012-06-04T08:40:17.499-07:00The Seven Circles of Linux PurgatoryFor the purification of the geek-spirit:<br />
<ol>
<li>panic: no init found. </li>
<li>Obtaining network card drivers</li>
<li>fatal error: linux/sys.h: No such file or directory</li>
<li>vim </li>
<li>Xorg.conf</li>
<li>Compiling video card drivers</li>
<li>This site is best viewed using current versions of Netscape Navigator or Microsoft Internet Explorer at a screen resolution of 800 x 600 or higher. </li>
</ol>
<ol>
</ol>Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0tag:blogger.com,1999:blog-9089043401683364319.post-1817258119239978552012-05-29T19:16:00.000-07:002012-05-29T19:16:33.062-07:00A list of things to remember when debugging a C programThese go for C++ as well. Assuming gcc/g++ and gdb.<br />
<ul>
<li>Compile with -Wall and pay attention to warnings. </li>
<li>Turn off compiler optimization. Remove -O from your CFLAGS.</li>
<li>Turn on debugging. Add -g to your CFLAGS.</li>
<li>Set appropriate breakpoints.</li>
<li>There is nothing wrong with throwing in a printf statement to narrow down your search. Use fprintf to print to stderr.</li>
<li>gdb --args ./program --program-args</li>
<li>break filename:lineno</li>
<li>Use valgrind to eliminate memory leaks and clean things up. If you can't trigger it while debugging, it's probably a memory bug. (valgrind --leak-check=full -v --log-file=vg.out ./program --program-args)</li>
<li>Define the error condition, then determine how it got that way.</li>
<li>When you find the bug, look for similar bugs in all your other code.</li>
</ul>Daniel Millerhttp://www.blogger.com/profile/03534199136686853844noreply@blogger.com0