A review of Encription’s QSTM training course

July 23rd, 2013

I took the QSTM training course from Encription at the beginning of the year, and I wanted to put together a quick review. From the outset, I found Ian who was my trainer on the course to be highly professional and technically competent. He had a thorough grasp of the material being taught and was able to answer a whole range of my questions without any difficulty.

TigerScheme

TigerScheme

My best advice is to come prepared with some basic Linux command line knowledge (I’d recommend the Backtrack/Kali distribution), and an understanding of networking and common protocols. The course itself covers a range of both technical and non technical theory, however practical techniques are taught from the outset and the pace of this increases throughout the course. This course was anything but a ‘death by powerpoint’ seminar! The QSTM itself is a certification provided by TigerScheme, and a portion of the course is dedicated to the requisite understanding of the TigerScheme structure and code of conduct.

Once done, we moved immediately on to the different steps required during a penetration test and started some practical work in the controlled lab environment. The pace picked up quickly from there with each day including some theory followed by lots of practical hands on work ranging from Windows and Linux exploitation to web application and social engineering techniques.

The course itself is relatively entry level and I highly recommend it for junior pen testers as well as developers, system administrators and technical managers looking for a solid foundation in penetration testing. Encription has a relationship with a nearby hotel, and the room, dining and facilities there were more than sufficient. Everything else needed during the week including lunches and materials are included.

The last day of the week’s course was dedicated to the exam, covering a multiple choice, essay based questions, a practical assessment and a viva (spoken). The viva involves discussing the findings of the practical assessment with the assessor and answering his questions to confirm that you have a good understanding of what you’ve done and why during the practical assessment rather than just regurgitating commands. The exam wasn’t tough and I was pleased with my performance.

Once complete, the exam output is sent to the University of Glamorgan for assessment and marking, and there’s a 2-3 week wait for the results. I was pretty confident and fortunately I passed! I can’t recommend the course enough – not only was it educational and a good course to have under my belt, but it was also good fun and highly enjoyable. Encription made me feel very comfortable throughout the course.

I’m currently studying and practicing for the TigerScheme SST (Senior Security Tester) which is significantly more difficult for the QSTM. I’m not sure that I expect to pass first time, although I’m going to go as prepared as possible and give it my best.

Why I like CertiVox’s new M-Pin

July 19th, 2013

Cryptographic standards are years ahead of the crackers. To take one example, a 256 bit AES key has 1.1 x 1077 possible combinations. Assuming a very optimistic brute force rate, that’s still going to take about 3.31 x 1056 years to crack [source]. Great right? Well the biggest weakness in the cryptography arena is not the standards themselves but the way that they are (mis)implemented. For a couple of examples; just take a look at the weaknesses in the now obsolete WEP standard, which don’t target the RC4 algorithm itself but rather the implementation. Don’t also forget the Debian OpenSSL blunder.

M-Pin

M-Pin

Certivox have launched their new M-Pin Strong Authentication System and one of the most encouraging features is the 15 minute integration. The multi-factor authentication system based on proven elliptic curve cryptography is housed within the M-Pin code which means that application developers don’t need to worry about the cryptographic principles, just a simple API integration. This dramatically improves the security of custom applications that are built around the M-Pin system leaving no room for bad cryptographic implementations.

M-Pin supports HTML5 web integration, and they also provide a C client library allowing developers to integrate the M-Pin protocol into software applications of their choosing and also allow for additional layers of authentication to be utilised such as biometrics.

From CertiVox’s press release – Brian Spector, CEO, CertiVox, said: “M-Pin is a game changer in the authentication industry, a true alternative to username / password authentication that scales for the web. M-Pin is an open source multi-factor authentication system that can be deployed in minutes at a fraction of the cost of existing solutions while offering a degree of security greater than many existing solutions that cost an order of magnitude more. M-Pin is the only open source authentication solution that removes the threat vulnerability of username / passwords at the client and server level and replaces it with two-factor authentication based on a strong cryptographic protocol built for tomorrow’s internet.”

Contributing to the community is a huge plus point in my book, and providing a free community tier means that I’ll be giving this a go in my next authentication project!

Two paid wifi attacks to bypass hotspot payment

July 4th, 2013

Most hotels around the world offer paid wireless internet services. There are various different ways that these operate on a technical level, however in general terms;

  1. Your device connects to the paid network
  2. The network router puts your ‘MAC address’ into the unpaid pool
  3. Any traffic from your device is blocked aside from DNS traffic which is hijacked by the router and resolves any query to the router’s IP, and web traffic which is also hijacked by the router and redirected to a page presenting a signup and payment page
  4. The router will only allow traffic to the internal payment system and perhaps allowed IPs such as the hotel web site servers.
  5. Once payment is made, the payment system notifies the router and your MAC address is added into the paid list
  6. Enjoy surfing the net
Basic WiFi Hotspot Network

Basic WiFi Hotspot Network

A basic wifi hotspot will contain a wireless access point allowing wireless devices to connect, and a router that performs, you guessed it, routing, hotspot authentication and so on acting as the ‘gatekeeper’. This router will then be connected to the internet. More complex systems may include more access points to span multiple floors or locations, more routers, separate authentication servers and so on, although the basic principle is the same, and the network layout is largely irrelevant to our attack scenario in any case.

To the non technical readers, there are a few terms we are interested in –

MAC Addresses & IP Addresses: A MAC address is a hardware address assigned to your network device – the ethernet (network) card has one, the wireless card has one, the wireless device in a mobile phone has one. It’s not the same as an IP address. A MAC address is (or should be) unique to your device but most importantly, unique to the current network segment. In this case, the network segment that we are on extends through the wireless network and up to the top connection on the internet router. The secondary connection between the router and the internet provider is a second segment. Routers break up segments and MAC addresses do not pass through the router. To simplify, in this case, every device connected to the wireless network will have a different MAC. IP addresses are ‘routed’ i.e. passed across the internet and translated, MAC addresses are not. This point is important to know in understanding one of the attacks. Of course as with every rule there are exceptions and for more advanced reading, ‘proxy ARP’ is one such exception however this scenario has specifically been kept basic to illustrate a successful attack.

DHCP: When you connected to the wireless network, your device sent out a ‘DHCP request’. Basically – “I’m new to this network, please let me have the details”. The DHCP server then responds providing a private IP address, router, DNS server and so on. As all of your traffic is passed through the network router, the network router can mangle it and modify it in any way that it wishes.

DNS: DNS is the service that turns addresses such as ‘www.adampalmer.me/iodigitalsec’ into an IP address such as 54.236.191.54 which are what the IP networks on the internet run on. Other protocols also exist that we don’t need to be concerned with here. DNS actually does a lot more than just turning names into IP addresses but that’s all that’s relevant here. As an unpaid user, when you fire up your browser and visit www.adampalmer.me/iodigitalsec your browser will contact the DNS server (router in this case) and ask for the IP address. The router will respond with it’s own address, perhaps 192.168.0.1 rather than the real address. This means that your browser will then attempt to connect to the web server on 192.168.0.1 – the paid hotspot signup page. Attempting to enter 54.236.191.54 in to your browser directly will bypass the DNS query, but the router will nevertheless hijack the request and redirect it to the payment page – if it didn’t that would be a simple method for bypassing the payment system.

Read the rest of this entry »

Security Through Obscurity – Fail

July 3rd, 2013

I was pen testing a web application last week, when I fired up ‘wfuzz’ using a custom large dictionary for file and directory brute forcing. To the non technical readers, this means that whilst there might be links on the site to say /login, /register, /contact-us and so on, I’m looking for files and directories on the web server (site) that don’t have links to them. Perhaps hidden functionality or testing and debugging files that the developers left behind and so on. I often find ‘phpinfo.php’ or ‘test.php’ type files and I once even remember finding a ‘psd.zip’ which was a zip file containing PSD files for the entire site layout.

Another common issue I find, is that while ‘index.php’ will be interpreted on the server side and the resulting data sent to the client as expected, ‘index.php.old’ and ‘index.bak’ will be sent directly to the client. This is down to the server being configured that .php files are interpreted by php, whilst unknown extensions such as .old and .bak are assumed to be plain text assets. The problem with this, is that these files will contain all kinds of goodies such as variable names, paths, business information and possibly database or other credentials. Whilst under development, pages will often undergo editing and revisions, and developers often forget to remove old versions, test and backup files. This inadvertently leaves them available to the public through the web server with just a little poking around.

You did WHAT?!

You did WHAT?!

Last week was something entirely different when I found ‘/nickreport’. This directory contained scripts allowing me to download a full report of customer signups and sales stats for the past 14 days for, you guessed it, Nick the sales director. The authentication prompt was defeated with credentials of ‘nick/nick’. When I confronted the application developer about this complete fail, his response was that the password authentication wasn’t for security but was just to prevent Google from crawling the site, and that there was no way that anyone would guess the URL anyway. He didn’t seem to understand the link between that statement and the fact that a) I HAD ‘guessed’ it and b) his password authentication was an attempt to prevent Google from indexing it. This alone implies that he was aware that search engines had or may in future have ‘guessed’ it.

Read the rest of this entry »