A quick post to share with you my feedback about an issue I faced after a SET (“Social Engineering Toolkit“) upgrade to the latest version (5.0.3). SET is a wonderful tool that you must master. I’m using SET on a EC2 instance because it does not interfere with my other IP addresses and I can enable all ports without any issue (nothing else is running on this instance). Note that Amazon has a specific policy to make pentesting from their infrastructure, have a look here).
Finally, I found some time to write my review of another book: “BackTrack 5 Wireless Penetration Testing“. The book was written by Vivek Ramachadran. Good coincidence? Vivek was present during the last edition of BruCON and gave a workshop called “Wi-Fi malware for fun and profit“. Being quite busy during the conference, I didn’t have lot of free time to attend workshops. This book was a good opportunity to learn new stuff…
Wireless networks have something “exciting” from a security perspective: Everybody use them daily even if we agree that lot of them are completely insecure. Everything has been said, tested and … exploited!
Let’s review the book! The first chapter starts with the classic steps to build your own lab (Reminder: never test your attacks against a network you don’t own). Then a chapter is dedicated to a review the bases of Wireless networks: the different types of frames, how to sniff and inject packets.
The chapters three and four explain how to bypass Wireless authentication mechanisms. First, simple protections like hidden SSID, MAC filtering and shared-key authentication. Then, classic encryption protocols (WEB, WPA, WPA2). Protocols are reviewed (how they work) then an attack scenario is described step by step. Maybe the most important conclusion of this chapter is:
“WPA/WPA2 is cryptographically un-crackable currently, however, under special circumstances, such as when a weak passphrase is chosen in WPA/WPA2-PSK, it is possible to retrieve the passphrase using dictionary attacks.“
The fifth chapter focuses on the Wireless infrastructure: How to attack the access points (DoS, MAC spoofing and rogue access points). After the infrastructure, the next chapters (seven & height) address the client: honeypot attacks, the Caffe Latte attack (created by Vivek himselve), MitM attacks and sessions hijacking. The chapter nine covers WPA-enterprise (with RADIUS authentication). Finally, the last chapter is a big resume: How to conduct a pentest using all the techniques describe previously.
What did I learn by reading this book? I’m just a dump occasional aircrack-ng user. I already cracked some WEP & WPA keys during audits or in labs, no more no less. In fact they are plenty of interesting options and techniques to stress-test Wireless networks (always without breaking any law of course!). Regarding the way the book is organized, I liked the numerous screenshots! All commands are described with copy of screens. It’s written like a recipe. Just follow all the steps! If your job requires knowledges of Wireless network security, this book is a must!
More information about the book here.
If you are working in the “information security” field, you must know the BackTrack distribution (otherwise you must be an alien coming from a far away planet!). If you search for the word “backtrack” on Amazon, you will find lot of references but only one book is fully dedicated to the Linux distribution: “BackTrack 4: Assuring Security by Penetration Testing“. I received a copy directly from the publisher and here is my review.
Just for those who are not familiar with BackTrack, it’s a Linux distribution made by security professionals for security professionals: It contains hundreds of tools to perform security assessments and penetration tests. Some of them are well-known like Metasploit, WebScarab or sqlmap and others are real gems (example: ua-tester which was added recently) and increase the quality of the toolbox version after version.
Even if BackTrack 5 was released a few weeks ago, it does not reduce the book quality. There are so many tools that a single volume is not enough to cover all of them. I was also surprised to read the name of my friend Peter “corelanc0d3r” Van Eeckhoutte as a reviewer of the book.
The first chapter can be quickly skipped, except if you are a beginner with BackTrack. It gives the required information to install your distribution on a computer. Nothing fancy, the readers must have Linux/UNIX knowledge!
The second chapter is more interesting and discusses about the different penetration testing methodologies. I’ll skip the difference between white- and black-testing. The review of different frameworks is useful and gives a good idea how to start a project. If you are new in pentesting, you have to know that it’s maybe the most boring task ever: Following a strict methodology and writing your report! Just one remark, the book remains focused on classic methodologies. You have to know that things are moving: There are new projects (like the PTES or “Penetration Testing Execution Standard“) which will take more and more importance in the future (IMHO).
The following chapters covered the classic penetration testing schema:
- Target scoping
- Information gathering
- Target discovery
- Enumerating target
- Vulnerability mapping
- Social engineering
- Target exploitation
- Privilege escalation
- Maintaining access
- Documentation and reporting
Each chapter reviews the most interesting tools (according to the authors) to achieve the chapter topic. Tools are briefly explained with examples. Straight to the point!
So, who’s need this book? The author’s goal is certainly not to give recipes on “how to hack a website“. The book must been see as a reference for those who already know the BackTrack distribution or who want to learn it. Don’t forget: this is just a toolbox, it does not prevent you to use your brain!
More information about the book here.
When talking about security, companies often focus on the “security perimeter“. Inside this perimeter, you have the “good” guys and all the rest is considered as the “wild” world, the Internet. Once you passed the access controls, you are free to walk and do what you want. Can you approve this from a security point of view? And this is true for physical security as well as network security. So often, I found myself alone in corporate buildings where I could perform so many malicious actions! (I insist here on the “could” verb ;-))
A new wave of gadgets, called the “PlugBot” or the “Pwnie Express“, are available for sale on the Internet. The work “gadget” is not the most appropriate in this case. I would say “killer tools” instead. Those small boxes have the same size as a PLC adapter. This makes them extremely portable and discrete. They integrate a powerful toolbox:
- 1.2Ghz CPU.
- Local storage (expendable via memory cards).
- Linux based.
- Several communication ports (Ethernet, WiFi, 3G, Bluetooth) depending on the model.
- A full set of useful tools (Metasploit, SET, nmap & co).
A full package for only a few bucks (starting from $220 for a Pwnie Express). This is a ridiculous investment compared to the profit that could be made by stealing data from companies. With the help of social engineering, it’s very easy to enter a company building and find an unprotected network patch! Some examples of scenario:
- Coffee & soda suppliers have full access to building to recharge their devices
- Fax/Printers maintenance is performed by external companies
- Cleaning people / gardeners
- Inside intruders (don’t under estimate them!)
Pentesters will like this! Once connected to your network, game over, you are 0wn3d! The device will be remotely accessible via WiFi or 3G. The attacker will have plenty of time to plan his attacks without fear of being discovered. It completely changes the pentester’s perspective. Really nice. But from the other point of view, how to protect yourself against this type of intrusion? They are two approaches that must be combined: enforce a physical security policy and enforce network controls.
The first one, physical security, is easy to understand but not always easy to implement. The golden rule is: Nobody can be allowed to access your premises without a prior identity control, a valid access reason and a contact person:
- Visitors must be clearly identified and access logged (time-in, time-out). They must wear a visible “visitor” badge.
- Visitors cannot be left alone and must always be accompanied by a team-member
- Visitors must stay in their allowed area (ex: a meeting room).
- Visitors must leave their luggage at the reception and carry on only the required stuff.
About the network security, some best practices could reduce the risk. First, implement network segmentation! Networks must be classified based on the data passing over them and access to them must be restricted based on their classification. Why allowing access to the servers VLAN from a meeting room? Tools and configurations can be used to increase your network security. They can be grouped in two categories: prevention and detection.
Prevention is the techniques and solution that will (or at least, try to) avoid attacks from happening. At the opposite, detection is the implementation of controls to detect and to notify about ongoing attacks. Both are part of a defense-in-depth model. If prevention fails (and keep in mind that it will!), detection will ring an alert.
Here are some recommendations:
|Shutdown unused port on switches. “shut” is your best friend command on Cisco switches. Don’t let ports “open” or at least set them in a default (safe) VLAN.||x|
|Active MAC address learning on switches. Major switches implement a control on the MAC addresses. If a new MAC address is detected, the port can be automatically disabled.||x|
|Implement a NAC (“Network Access Control“) solution. Based on free (like PacketFense) or commercial tools/protocols: (802.1x, VPMS), a NAC can allow/deny access to your network and report problems.||x||x|
|Implement network segmentation (Read: don’t put all you eggs in the same bag). Unknown devices must be connected to an untrusted VLAN. A “guest” VLAN can be created for temporary Internet access (on demand!)||x|
|Implement MAC address detection. Using tools like arpwatch, unknown MAC addresses can be detected on a network.||x|
|Monitor ports status on switches. Except on access switches, once a device is connected, it remains in the same state. Monitor the port status changes on your switches. They could hide suspicious activity.||x|
|Lock public network ports / wall plugs. Don’t leave unattended ports in public area (reception, meeting rooms, etc). Use locks.||x|
|Look for suspicious traffic! It’s always interesting to analyze your network flows for suspicious traffic.||x|
|Enable host based firewalls / ACL’s. All hosts must implement ACL/firewall to restrict access to authorized people/hosts only.||x|
|Use WiFi scanners to detect rogue wireless access points.||x||x|
This proves, once again, that the good old security perimeter is definitively dead! Don’t trust any device nor traffic seen on the “internal” side of your network. If we can still call it “internal”…
OpenSSH is a common tool for most of network and system administrators. It is used daily to open remote sessions on hosts to perform administrative tasks. But, it is also used to automate tasks between trusted hosts. Based on public/private key pairs, hosts can exchange data or execute commands via a safe (encrypted) pipe. When you ssh to a remote server, your ssh client records the hostname, IP address and public key of the remote server in a flat file called “known_hosts“. The next time you start a ssh session, the ssh client compares the server information with the one saved in the “known_hosts” file. If they differ, an error message is displayed. The primary goal of this mechanism is to block MITM (“Man-In-The-Middle“) attacks.
But, this file (stored by default in your “$HOME/.ssh” directory) introduces security risks. If an attacker has access to your home directory, he will have access to the file which may contains hundreds of hosts on which you also have an access. Did you ever eared about “Island Hopping” attack? Wikipedia defines this attack as following:
“In computer security, for example in intrusion detection and penetration testing, island hopping is the act of entering a secured system through a weak link and then “hopping” around on the computer nodes within the internal systems. In this field, island hopping is also known as pivoting.“
A potential worm could take advantage of the information stored in the file to spread across multiple hosts. OpenSSH introduced a countermeasure against this attack since the version 4.0. The ssh client is able to store the host information in a hash format. The old format was:
host.rootshell.be,10.0.0.2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0ei6KvTUHnmCjdsEwpCCaOHZWvjS \ jytm/5/Vv1Dc6ToaxTnqJ7ocBb7NI/HUQEc23eUYjFrZQDS0JRml3RnsG0UzvtIfAPDP1x7h6HHy4ixjAP7slXgqj3c \ fOV5ThNjYI0mEbIh1ezGWovwoy0IxRK9Lq29CacqQH8407b1jEj/zfOzUi3FgRlsKZTsc3UIoWSY0KPSSPlcSTInviG \ oNi+9gC8eqXHURsvOWyQMH5K5isvc/Wp1DiMxXSQ+uchBl6AoqSj6FTkRAQ9oAe8p1GekxuLh2PJ+dMDIuhGeZ60fIh \ eq15kzZGsDWkNF6hc/HmkJDSPn3bRmo3xmFP02sNw==
With the version 4.0, hosts are stored in this new format:
|1|U8gOHG/S5rH9uRH3cXgdUNF13F4=|cNimv6148Swl6QcwqBOjgRnHnKs= ssh-rsa AAAAB3NzaC1yc2EAAAABIw \ AAAQEAvAtd04lhxzzqW57464mhkubDixZpy+qxvXBVodNmbM8culkfYtmq0Ynd+1G1s3hcBSEa8XHhNdcxTx51MbIjO \ dCbFyx6rbvTIU/5T2z0/TMjeQyL3SZttbYWM2U0agKp/86FdaQF6V87loNcDq/26JLBSaZgViZS4gKZbflZCdD6aB2s \ 2sqEV4k7zU2OMHPy7W6ghNQzEu+Ep/44w4RCdI5OYFfids9B0JSUefR9eiumjRwyI0dCPyq9jrQZy47AI7oiQJqSjvu \ eMIwZrrlmECYSvOru0MiyeKwsm7m8dyzAE+f2CkdUh6tQleLRLnEMH+25EAB56AhkpWSuMPJX1w==
As you can see, the hostname is not readable anymore. To achieve this result, a new configuration directive has been added in version 4.0 and above: “HashKnownHosts [Yes|No]“. Note that this feature is not enabled by default. Some Linux (or other UNIX flavors) enable it by default. Check your configuration. If you switch the hashing feature on, do not forget to hash your existing known_hosts file:
$ ssh-keygen -H -f $HOME/.ssh/known_hosts
Hashing ssh keys is definitively the right way to go but introduce problems. First, the good guys cannot easily manage their SSH hosts! How to perform a cleanup? (My “known_hosts” file has 239 entries!). In case of security incident management or forensics investigations, it can be useful to know the list of hosts where the user connected. It’s also an issue for pentesters. If you have access to a file containing hashed SSH hosts, it can be interesting to discover the hostnames or IP addresses and use the server to “jump” to another target. Remember: people are weak and re-use the same passwords on multiple servers.
By looking into the OpenSSH client source code (more precisely in “hostfile.c“), I found how are hashed the hostnames. Here is an example:
“|1|” is the HASH_MAGIC. The first part between the separators “|” is the salt encoded in Base64. When a new host is added, the salt is generated randomly. The second one is the hostname HMAC (“Hash-based Message Authentication Code“) generated via SHA1 using the decoded salt and then encoded in Base64. Once the hashing performed, it’s not possible to decode it. Like UNIX passwords, the only way to find back a hostname is to apply the same hash function and compare the results.
I wrote a Perl script to bruteforce the “known_hosts” file. It generates hostnames or IP addresses, hash them and compare the results with the information stored in the SSH file. The script syntax is:
$ ./known_hosts_bruteforcer.pl -h
Usage: known_hosts_bruteforcer.pl [options]
-d <domain> Specify a domain name to append to hostnames (default: none) -f <file> Specify the known_hosts file to bruteforce (default: /.ssh/known_hosts) -i Bruteforce IP addresses (default: hostnames) -l <integer> Specify the hostname maximum length (default: 8 ) -s <string> Specify an initial IP address or password (default: none) -v Verbose output -h Print this help, then exit
Without arguments, the script will bruteforce your $HOME/.ssh/known_hosts by generating hostnames with a maximum length of 8 characters. If a match is found, the hostname is displayed with the corresponding line in the file. If your hosts are FQDN, a domain can be specify using the flag “-d“. It will be automatically appended to all generated hostnames. By using the “-i” flag, the script generates IP addresses instead of hostnames. To spread the log across multiple computers or if you know the first letters of the used hostnames or the first bytes of the IP addresses, you can specify an initial value with the “-s” flag.
Examples: If your server names are based on the template “srvxxx” and belongs to the rootshell.be domain, use the following syntax:
$ ./known_hosts_bruteforcer.pl -d rootshell.be -s srv000
If your DMZ uses IP addresses in the range 192.168.0.0/24, use the following syntax:
$ ./known_hosts_bruteforcer.pl -i -s 192.168.0.0
When hosts are found, there are displayed as below:
$ ./known_hosts_bruteforcer.pl -i -s 10.255.0.0 *** Found host: 10.255.1.17 (line 31) *** *** Found host: 10.255.1.74 (line 165) *** *** Found host: 10.255.1.75 (line 69) *** *** Found host: 10.255.1.76 (line 28) *** *** Found host: 10.255.1.78 (line 56) *** *** Found host: 10.255.1.91 (line 51) *** ^C
My first idea was to bruteforce using a dictionary. Unfortunately, hostnames are sometimes based on templates like “svr000” or “dmzsrv-000” which make the dictionary unreliable. And about the performance? I’m not a developer and my code could for sure be optimized. The performance is directly related to the size of your “known_hosts” file. Be patient! The script is available here. Comments are always welcome.
Usual disclaimer: this code is provided “as is” without any warranty or support. It is provided for educational or personal use only. I’ll not be held responsible for any illegal activity performed with this code.
There was an interesting thread on the email@example.com mailing list a few days ago. A member asked how to detect illegal or “rogue” gateways in a big international organization. Rogue devices can be seen from different point of views. For the network administrators or the security auditors, it’s really a pain. Users may connect prohibited devices on the network. Those are often poorly or even not configured at all (running with the factory settings). But from an attacker point of view, it’s a great opportunity to bypass controls in place like firewalls or IDS. Rogue devices are not a new threat. Already in 2008, I wrote a Nagios plug-in to detect rogue DHCP servers (also extremely dangerous in a LAN).
For evident security reasons, a network must have only one default gateway. This single network point is the way out to the Internet and must be configured to enforce security rules and control the traffic. If a rogue gateway is available, users can change their default gateway in their TCP/IP stack and they will evade all the security filters in place. A good example is a small ADSL SO-HO router connected on a corporate LAN. But a server or a workstation can also act as a gateway (a badly configuration workstation with a Tethered iPhone is very risky).
Basic detection can be achieved by using scanners like Nmap. Based on the MAC addresses or their fingerprints, major devices like Cisco or Juniper routers can be easily detected. Using SNMP, some OID’s may reveal sensible devices. But gateways can be hardened to not answer to ICMP requests or have SNMP disabled (or properly protected). To probe for rogue gateways, we need to test their routing capabilities using tools like traceroute.
Testing a big network is a pain and requires a lot of time. I wrote a Perl script to automate the following task: For every IP address in a given range, a static route for an external host is created pointing to the current scanned IP and a traceroute is performed. The results are analyzed and produce an output like in the example below. A valid gateway will report several hops.
# ./roguegw.pl -h Usage: roguegw.pl --startip x.x.x.x --endip x.x.x.x --target x.x.x.x \ [--randomize] [--help] startip / endip : Define the range of IP addresses to scan. target : Defines the target IP address to reach via the gateway. (Can be a public IP address or another organization subnet. randomize : Randomizes the IP range (usefull to work below the radar). # ./roguegw.pl --startip 192.168.254.1 --endip 192.168.254.10 Scanning IP range: 192.168.254.1 - 192.168.254.10 ... Testing: 192.168.254.1... Found 5 hops! 1: 192.168.254.1 (0.531ms) 2: * 3: 22.214.171.124 (29.207ms) 4: 126.96.36.199 (37.407ms) 5: 188.8.131.52 (45.358ms) Testing: 192.168.254.2... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.3... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.4... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.5... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.6... Host up but no packet forwarding. Testing: 192.168.254.7... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.8... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.9... Host reported unreachable from 192.168.254.229 Testing: 192.168.254.10... Host reported unreachable from 192.168.254.229 Done.
The script accepts some arguments: an IP range delimited by a starting and ending addresses and an optional target IP address (by default an IP address of www.google.com is used). The target can be a public IP address (on the Internet) or another private IP address. If the argument “–randomize” is given, the IP range will be first randomized. This can be helpful to work “below the radar”. Note that the script limits the traceroute to the first five hops for speed reason (it should be sufficient in most cases). To execute the script you need the following Perl modules installed: Net::IP and Net::Traceroute.
My first idea was to grab the TCP/IP settings from the host running the Perl scripts but it looks to be difficult due to the high number of systems running Perl. By providing an IP range you can restrict the scan to only a few IP addresses like to ten first or the ten last of your subnet (where are usually assigned gateway IP addresses). This will also be less intrusive.
The Perl script is available here: roguegw.pl.txt. Same disclaimer as usual, it is provided “as is” without any warranty. Feel free to re-use it or adapt it.
MetaSploit 3.2 has been released!
“Austin, Texas, November 19th, 2008 — The Metasploit Project announced today the free, world-wide availability of version 3.2 of their exploit development and attack framework. The latest version is provided under a true open source software license (BSD) and is backed by a community-based development team.
Metasploit runs on all modern operating systems, including Linux, Windows, Mac OS X, and most flavors of BSD. Metasploit has been used on a wide range of hardware platforms, from massive Unix mainframes to the iPhone. Users can access Metasploit using the tab-completing console interface, the Gtk GUI, the command line scripting interface, or the AJAX-enabled web interface. The Windows version of Metasploit includes all software dependencies and a selection of useful networking tools.
The latest version of the Metasploit Framework, as well as screen shots, video demonstrations, documentation and installation instructions for many platforms, can be found online at http://metasploit.com/framework/”
For a review of new features, see here.
The next part (part 3) is now online! Read it here: http://synjunkie.blogspot.com/2008/11/story-of-hack-part-3-kung-fu-shopping.html.
In a recent post, I talked about SynJunkie who described a nice pentest scenario against a fictive company. The second part is now online! Read it here: http://synjunkie.blogspot.com/2008/11/story-of-hack-part-2-breaking-in.html.