24 Feb 10 UDP Tunneling to avoid hotspot or firewall restrictions

UDP tunneling is an attack that is often overlooked when manufacturers design wireless hotspot and other firewall/proxy based devices.

When you try and resolve a domain name, you make a request to a name server on UDP port 53. The way that a lot of wireless hotspot, firewalls and proxies work, is that your DNS request is allowed out, you get the IP for the machine you’re looking for, and then your request to the IP is redirected to the wireless hotspot login page, or through a web proxy server.

The problem is, that all port 53 UDP traffic is allowed out to anywhere, without any kind of authentication. You can therefore install OpenVPN on a remote server which by default listens in on UDP port 1194. You can change this with one configuration option to 53, and then edit your client config to connect to the server on port 53 instead. Often, other TCP/UDP ports might be allowed out, and ICMP is also sometimes a possibility. It is possible to easily tunnel your data out over TCP, UDP or ICMP as a worst case.

This type of attack worked on 5 out of 6 different wireless hotspot systems to gain access without authentication.

The one that it didn’t work on, captured all outbound 53 UDP requests, and silently redirected them to it’s own local DNS server. This is simple enough to do, so I’m not sure why more manufacturers haven’t done the same. Using iptables:

${IPTABLES} -t nat -A PREROUTING -i eth0 -p udp -m udp –dport 53 -j REDIRECT –to-port 53

These are the same type of rules used to configure transparent proxying for Squid.

Tags: 53, firewall, hotspot, iptables, openvpn, squid, transparent proxying, udp, udp tunneling

19 Jan 10 Website Security Scan

Websites get hacked every day, customers details taken, and it’s usually REALLY EASY to do. As a security consultant,  I often get a call after a Google search turns up with my details as the guy to contact when this happens.

Shameless plug: Why not contact me BEFORE this happens for a FREE basic web scan.

Shameless plug over, why not consider some of the things that can be done to help prevent a website breach..
(more…)

Tags: Apache, backups, code, cookie, cross site scripting, htaccess, LAMP, logs, mod_security, MySQL, PHP, php security, rate limit, restrict limit, Security Consultant, session, sniffing, sql injection, website security scan, xss

11 Oct 09 Linux Consultant – How to recover a compromised server

As a security consultant I often have to deal with machines that are already compromised. The ‘official’ standpoint is always to wipe the machine alltogether, reinstall your OS, and restore your data and configurations from the backups that you obviously have.

The above not always being possible, and as a second best alternative, you’ll have to recover the machine.

The first thing to do is compare each command line utility to that of a known good identical system before using it, so you can rely on the results that it returns. A hacker will often drop a modified ‘ls’, ‘lsmod’, ‘ps’ and various other tools onto your system to hide the various other things that he may have installed.

You’ll need to use md5sum and ls to check the size and checksum of each utility before you use it, although of course, md5sum and ls themselves could be hardcoded with predefined responses. You could also use ’strings’ to check the ASCII contents of those tools, although the ’strings’ could just as easily be rigged. If you’re that paranoid, you’ve got no choice but to wipe the machine alltogether.

So firstly, check the integrity, of each of your core utilities. If your Debian 5.0 with the latest updates installed system was compromised, you’ll need to check against another Debian 5.0 system with the same updates and tools installed. Or, if you can find a listing online somewhere of what binaries should be what sizes and have what MD5s then you should be fine.

Once you have confirmed your ‘md5sum’ utility, you should be able to just start comparing MD5s and not worrying about file sizes and strings. Check your package management utilities and check that you’re happy with them, then apt-get install rkhunter this will check a number of issues. There are other ‘root kit hunters’ that you can use as well if you wish. Once this has been run, check your ps utility and ensure that it is as you expect. Then once done just run ps auxw and check each running process in the same way. Assuming that all of that is done and has not shown up anything, all is good so far. If something has been found and one of your binaries is compromised. Assuming your package manager is in good order, dpkg -P <package> and reinstall. If it is a core package that can not be removed/purged without affecting the rest of the system, then just scp over a new binary. Check again that the libc6 version and package version is IDENTICAL, and check of course that scp itself is in good order.

At this point, we can assume that your binaries themselves are in good order. Check for any new SUID utilities with find / -perm +4000 and once done, firstly make sure that everything on that list is as expected, and secondly, double check your md5sums of each and everyone of those.

This all being OK, continue to check by looking at your /etc/passwd, /etc/group and /etc/shadow files checking for user accounts that you don’t recognise. Then check syslog, wtmp, lastlog, etc, and check the IPs and last logins of each account. Also check directories such as /tmp/ especially with ls -al to check for directories beginning with a ‘.’ which would otherwise be hidden.

If everything above returns success, then it’s unlikely that your system was directly compromised. There is always the chance that your web application or database was compromised, but then that’s outside of the scope of this article. In short though, check your webserver log files as that should give you the information on what was compromised, and how it was done. Obviously ensure that any 3rd party software that you may be using such as wordpress, vBulletin, etc, etc are always up to the latest version.

Edit/Addition:
In response to a reader’s comments, I would add that should you be able to remove the network connection to the compromised machine and still access it, then do. Your login and anything you type could be being sent to an attacker without you even realising it.

Additionally, there is no point in simply recovering a hacked server without knowing how it was compromised in the first place. Arguably you should have worked it out though by following the steps above.

Tags: apt-get, compromised, debian, dpkg, find, hacker, lsmod, md5, md5sum, ps, rkhunter, Security Consultant, strings, tools

03 Oct 09 Linux Security Freelancer – Securing a node – Where to start?

As a Linux Security Freelancer, I’m often asked where best to start when securing a single linux host. Whereas most would suggest configuring iptables or similar, the most effective first step in my opinion is to remove unnecessary services.

There are a number of methods that you can use to show open sockets at least:
lsof -U will list open sockets
nmap -sT -sU localhost will scan your local machine for open TCP or UDP ports
netstat -a | grep LISTEN will show all listening sockets.

Forgive me for stating the obvious, but the first thing to do is disable any open sockets or services that aren’t required. On a default install, this could include the likes of the portmapper service, identd and an smtpd.

Next, you want to suitably lock down user accounts, check passwords, and perhaps consider enforcing a secure password policy, at minimum I generally prefer at least 8 characters, at least one uppercase, one lowercase and one integer. Obviously this shouldn’t be easily guessible, nor should it just end in a ‘1′.

Once done, the next thing that you want to do is to suitably firewall the services that you do require open, and perhaps also restrict the rate of ICMPs, etc, with iptables.
(more…)

Tags: buffer overflow, freelancer, icmp, identd, iptables, Linux, linux security freelancer, lsof, netstat, nmap, node, ping, portmapper, root, security, Security Consultant, setuid, smtpd, suid

02 Oct 09 Security Consultant – Man In The Middle Attacks (MITM)

A Man In The Middle (MITM) attack is a popular network based attack in order to hijack a connection or to sniff traffic. A MITM attack actually covers a variety of different methods. A MITM attack is literally positioning yourself as the attacker between the two communicating parties. Whether you do that via an ARP attack, some type of cryptographic attack, or a physical attack depends on the requirements and scenario. As a security consultant it is important to ensure that the network and it’s communications are as secure as possible against this type of attack. I will cover a simple physical MITM attack, then an ARP attack, and then prevention techniques.
(more…)

Tags: arp, arp attack, arp poisoning, cryptographic attack, default gateway, gateway, layer 2, layer 3, man in the middle, managed switch, MITM, network bridge, nic, openvpn, router, Security Consultant, self signed certificate, SSL, switch

30 Sep 09 Self Signed Certificates

SSL – ‘Secure Sockets Layer’ is an encryption protocol. How it works is beyond the scope of this article, our only concern for now is self signed certificates. Sufficient to say, that SSL is based upon public key cryptography (PKI). It makes use of a private key and a public key. Being a Linux Security Freelancer it’s important to be able to advise on when certain technologies are acceptable, and when they aren’t.

If SSL certificates rely on public key cryptography, why do we need a certificate? Simply put, the certificate is usually signed by a ‘trusted’ Certificate Authority (CA)  thus informing the other party that the host is who he claims to be.

Whether the certificate is signed by a CA, or not, your level of encryption and underlying SSL is the same. You might want your CSR (Certificate Signing Request) signed by a trusted CA certain instances. Most websites that use ‘SSL’ today have their certificates signed by a trusted CA. If your web visitors trust you, and your CA has verified that you are who you claim to be, then logic follows that your visitors trust your signed certificate.

You may decide to use a self signed certificate in the instance that you want your data encrypted between your host and the remote host, and know that the remote host is who he claims to be, without needing to convince anyone else of it. In the instance that you are using SSL over HTTP, your browser would warn you that the certificate has not been signed by a known authority. As long as you accept this, your connection is just as encrypted as it would have been should a trusted CA have signed it.

One often overlooked problem though is the potential for a MITM (Man In The Middle) attack. A machine between yours and the remote host could sniff but as of writing, not decrypt your data. However should he perform a MITM attack and essentially fool you into connecting to his webservice with his self signed certificate, you wouldn’t know any better.. You’d receive the same popup warning, which you’d dismiss, and begin your session with an attacker instead of the remote host you were expecting.  One way of confirming, is that you could inspect the certificate, and look at it’s fingerprint. How many people would do that though?

Tags: CA, certificate authority, CSR, http, man in the middle, MITM, PKI, public key cryptography, SSL

30 Sep 09 Security Consultant – London Site Visits

The majority of my onsite visits as far as security consulting goes are in London City. The time budgeted for an onsite visit by a Client is almost never enough, and trying to squeeze two and a half day’s worth of testing into a single day has it’s challenges. Due to the sensitive nature of a lot of the material, more often than not, I’m also not able to take notes offsite. This means that I either need an incredibly good memory, or more practically, I need to be able to complete the majority of the report whilst onsite as well. Being a London Security Consultant can be very challenging at times, however the rushed nature of the average engagement means that more often than not I don’t get to go into some of the detail I would have liked.

Speaking to colleagues in the field, more often than not it is perfectly acceptable to assess the network and simply point out potential flaws. I personally thought though that there was more though to being a penetration tester than spending a day running nmap against various devices. When under time pressure, it’s particularly important to be able to multitask, although ensuring that one test and perhaps it’s bandwidth consumption will not interfere with other tests being run is also important to keep in mind. It should be obvious by now that I test in too much depth as opposed to too little, and if time doesn’t permit, I guess certain areas will have to remain untested until we can get a time extension..

For more information on my London Security Consultancy and availability, please view my Security Consultancy page or alternatively just contact me!

Tags: nmap, pen tester, Security Consultant, security consultant london

28 Sep 09 Security Consultant – Scope of work

As a Security Consultant, I’ve always had a difficult time with the scope of work and just how much detail to go into during the test. What to pen test is more often than not strictly defined, however what detail to go in to, is often not. In some cases the time constraints dictate the detail of the penetration test itself, however often with pen testing, more time is allowed than is necessary.

I have a specific example in mind, whereby I identified a possible DoS (Denial of Service) attack against a service running on a particular vendor’s hardware. The attack was only vaguely theoretically possible, however given the spare time, I did spend a number of hours writing an actual implementation of the Denial of Service attack, and then demonstrating proof of it’s functionality. At that point, the Client changed various configuration options which prevented this DoS, whilst technically mildly limiting functionality.
(more…)

Tags: consultant, denial of service, dos, pen test, penetration test, PHP Developer, Security Consultant, web developer

18 Sep 09 Web Application Security Consultant Methodology

I wanted to share some thoughts on my general methodology when approaching web application pen testing. Depending on size, scope of work, complexity and a number of factors, there are two separate angles, usually both or a hybrid of both that I will take.

The first angle has to be the network security itself, all the way down the the physical security. As a penetration tester, I’ll test the web, database, storage and any other related networked devices inside and out. Port scanning their interfaces, spoofing IPs and MACs, asking myself questions such as “Does the database accept direct connections from any IP? Does Apache keep too many spare threads waiting?” We need to work our way from bottom to top of the OSI Model, a lot of which can be done using nc (Netcat) and a combination of scripts, as well as nmap.

Secondly, as the security consultant, I would then test the application itself and dependant or otherwise related applications. Crawl the site and it’s file hierarchy using wget or similar, and then run automated test tools, such as burpsuite, acunetix and a combination of curl/wget and shell scripts before manually drilling down into anything suspicious. Unfortunately for the user, the majority of web applications are insecure. A web crawl using a recursive wget, followed by some blind SQL injection checks will more often than not turn up the opportunity for SQL injection. Once this is done, the next query is how far I can go with the SQL injection. Do I have root access now to the database? Does the database user have unnecessary permissions? I should be able to SELECT and possible INSERT/UPDATE data. It’s unlikely that I should be able to actually alter, or even drop the database from the web user. Having table update priviledge on all tables is just as good as being able to drop the database itself though in terms of potential damage. This combination of security issues could lead to even further damage once the initial compromise has been made.

The next question is how far to proceed once an opportunity has been identified. Is demonstrating an opportunity for SQL injection sufficient, or does the opportunity need to be exploited? Once done, does data actually need reading or writing to the database or code changed? This generally depends on the scope of the work and purpose/setting of the systems under test. More will be discussed on this in later articles.

Once complete, I will generally report and rate the issues found from 1 to 5. 1 being informational, 2 being low severity, 3 being medium severity, 4 being high severity and 5 being critical severity. The database user having additional priviledges may fall into categories 3 or 4. An outdated but currently secure version of the webserver running may fall in to category 1, whilst an SQL injection opportunity will for sure fall in to category 5.

Scope depending, I can either discuss the issues and advise on strategies to resolve, or alternatively provide the report ready for the Client to pass on to his own IT consultant.

Tags: acunetix, axunetix, burpsuite, curl, netcat, nmap, osi model, pen test, penetration test, script, Security Consultant, shell, sql, sql injection, web application, wget

10 Sep 09 Security Consultant – Ports & Port Knocking

Port Knocking is a clever and interesting method of allowing remote firewall manipulation whilst leaving all ports closed to all IPs. When I attempt to initiate a TCP connection to a remote host I send a packet with a ‘SYN’ flag, indicating my intention, along with other information such as a source port, destination port, source IP and destination IP. The target machine has the option of responding by accepting, responding by rejecting, or simply ignoring the packet alltogether, known under iptables and most other firewalls as ACCEPT, REJECT or DROP.
(more…)

Tags: accept, connection, drop, firewall, IP, iptables, port, port knocking, protocol, reject, source ip, syn, target, tcp