I have now completed the first course in my queue! Since the last post, I have been digging into website hacking. This is of course a big area and a massive element of day-to-day information security. I went through various avenues and implementations of SQL injection attacks, XSS (Cross Site Scripting) attacks, and more. I also learned about protecting against these sorts of attacks, and had a brief introduction into how vulnerability scanning can be automated with scanning tools. Of course, once you have your scan output ready, put it into Dradis and produce a custom no-fuss report!

Trying out the SQL injection procedures was based on attacking a fake vulnerable web server in Metasploitable. Insecure database calls in SQL on a website or web application can let attackers extract or modify information, or grant access even without passwords. An SQL injection vulnerability on one site can potentially undermine the security of all sites and applications hosted on that one web server. As the instructor said, if there is an SQL injection vulnerability on the target site, bingo, game over, you as an attacker can ultimately do virtually anything you want with that site.

With XSS vulnerabilities, you essentially insert scripts to run from a site. As an example, there may be a commenting feature on a web page with an XSS vulnerability, which means that this XSS script would run for all visitors to that page. What makes this insidious is that the script would run for visitors to the page, as it’s not part of the base web page. An insecure website could therefore jeopardize the security of third parties – and therefore, owners of web pages, web applications, and web hosts have a responsibility to protect their sites so third parties are not affected.

The course closed with a very brief introduction to ZAP (Zed Attack Proxy), one of many tools to automate scanning for vulnerabilities. The point of this course was to show the theory behind security vulnerabilities, and the sort of attacks that can be carried out by hackers. Now that I have been introduced to the nuts-and-bolts, step-by-step methods of attacking devices and applications, the path is open to learning more about particular focus areas and to think about scripting and automation. I do have some more studies coming up to these ends. I intend to learn more about hacking using Android, I need to learn more about networking vulnerabilities, and I would like to learn more about scripting and vulnerability scan automation through software like ZAP and Burp, both of which have official Dradis plugins. I already manipulate their plugin outputs most days when building Dradis templates, so it would be fun to create those outputs as well!

Lately I have been looking into the details of hacking through networks, and post-exploitation attacks. The idea was to get beyond the idea of trying out attacks on a second VM on the same device, or another device here at home, to the principle of hacking devices on other networks.

First up was freshening up on the basics of networking. From the “information gathering” step I should have multiple ways of potentially feeding backdoors to the target device. Then there was an exercise of doing so, using BeEF – essentially the same exercise as before, with only some minor changes to function with the outside network. That demonstrated the principle, so we moved on to a look at post-exploitation attacks.

Post-exploitation attacks were run with metasploit through veil-evasion. That generated a robust connection with meterpreter that should be essentially undetectable by antivirus programs. The challenge is of course to manage the original connection, but with that accomplished, meterpreter allows all sorts of scripts to be run as well as terminal access.

In effect, that meant running all the sorts of attacks that people should be paranoid about; keylogging, capturing screenshots of the target device, controlling the camera and/or microphone, altering the files on the target device, and so on. Fun! Metasploit has so many functions and capabilities that going through them in detail was beyond the scope of this course.

Now that the possibilities of post-exploitation attacks had been made clear, the course moved back to networking, to cover pivoting. Pivoting allows hackers to target other devices in the same network as an infected device. Even if the hacker’s device has no access to the final target devices, if they can attack a device in the same network as the final target, they can route their attacks through the infected device. That is another cool exploit, and hammers home how important security is on servers and routers.

As the course progresses, I believe I get a far better understanding of our Dradis users’ use cases. When I build custom Dradis templates and configure projects, of course there’s always some variation of issue descriptions, screenshots, and usually evidence output. These post-exploitation attacks and network penetration efforts are exactly the sort of vulnerabilities that Dradis is set up to report, and screenshots of my work would make good evidence output.

I do feel that in the last weeks’ studies I have been heavy on the theory and observation, but light on actual practise. I intend to set up a few devices and VMs to practise attacking, and I have permission to try to attack some other peoples’ personal devices. Let’s see how that goes; beyond that, the rest of the current course covers website hacking, which will also be fun!

Lately my studies have gone over email spoofing and hooking browsers using BeEF. Email spoofing in itself is easy enough, with editable “from” fields in many email apps, but I learned a few new cool approaches to make the spoofing far more accurate, enough to fool Gmail. Browser hooking is very cool, it’s frankly shocking to see just how much can be done to a victim’s device just through a browser. Then I consider that Chromebooks are basically a PC running through a browser. The trend is definitely to make browsers even more central to electronic device usage, and I’m not convinced that the work taking place for improved browser security is commensurate with the needs for it.

Most of this Social Engineering section has been based around one simple trojan, easily created and capable of bypassing antivirus programs. Whether it’s through spoofed emails, browser redirection, fake updates, or other BeEF tricks, the delivery of the trojan has been simple. The approaches are also fairly convincing on the face of it – getting someone to open a zipped .pdf or .png which is secretly a trojan is not hard when they are convinced it comes from someone they know and trust. At first approach, the browser hooking techniques I have seen appear a little more crude and unsophisticated – why would Firefox need to redirect you for an update, for example? – but could definitely work on more casual users. Phishing login data through a fake login window is still effective, especially when it’s from a frame in the user’s current page and doesn’t involve a redirect or an obviously fake URL in the header. Capturing screenshots, and even commandeering the webcam and microphone, is of course far more insidious and unlikely to be detected once the browser is hooked.

My main takeaway from this so far is that I’m gaining a lot more respect for proper preparation work in information gathering before making the first attack. Proper research with Maltego, or just careful use of Google and social media, clearly make an attack far more likely to succeed. As I’ve noted before, this suggests we should all be far more protective of our data and privacy – but how realistic is that really in the modern age, when simply applying for jobs or keeping in touch with your friends all but requires social media accounts?

I’m also surprised at the suggested measures for detecting trojans like the ones I have made – far too manual, like checking file properties. Fortunately the OSes I use will not run malicious code without my active consent, but the way I had my Windows rig set up (back when I had one) would be far more vulnerable despite the firewall, antivirus, and VPN.

Next up is some more work on networks, e.g. for using BeEF outside the user’s network, and then going into post-exploitation attacks in more depth. Fun!

This week my studies took a bit of a left turn into Social Engineering.  Whereas everything else so far was technical in nature, using and abusing hardware and software issues and their vulnerabilities, the most recent classes covered the most defective element of any security system – the meatbag in front of the monitor.  PEBKAC indeed!

In terms of systems, I got started with Maltego CE.  The interface is very user-unfriendly, but with the right walkthrough and plugins, it’s the tool I never knew I wanted!  By doing plugin-based searches on all sorts of media on nodes such as persons, websites, servers, and so on, it becomes possible to draw intricate networks of connections between nodes – like a conspiracy theorist’s corkboard, only for cyber-stalking.  Fun stuff!

Next up on the technical side was spoofing to bundle malicious code with a legitimate file and obscure the executable extension, as well as spoofing emails and accessing email servers to send spoof emails without getting immediately flagged as spam.

The downside of this part of the course is that it feels like it’s stretching the concept of “ethical hacking” to the limits of what can be considered “ethical”.  If I spoof a VM, or a real device with the owner’s permission, for the sake of attempting a man-in-the-middle attack, I’m not hurting the device’s feelings.  To even test out a social engineering attack I have to try to fool someone.  I have no problems with pushing the limits of what I can find out about an entity online through publicly accessible information, as the entity in question can use that data for good (e.g. improving their personal privacy by restricting apps’ access to their data), but getting someone to “click here” feels too close to Nigerian royalty.

Even so, the shock value of a successful engineering attack can have positive effects in the sense of raising awareness.  A BBC journalist agreed to let a cyber-security firm try to phish him, and they succeeded.

Did you click that link?  Considering the subject of this post, did you even check if it was legit?  This time it was – but what if it hadn’t been?

This week I got started with Veil.  By using this software together with other techniques from the course, I could open backdoors to target devices in short order.  There are two clever aspects to the approaches used.  First, I was forcing the client device to connect to my Kali VM to execute the attack, rather than me connecting to the target directly.  This approach sidesteps the typical defences in regular firewalls and routers.  Second, the payload delivery was made to spoof the download of genuine updates, with redirects to the appropriate “Update successful!” pages once the download was complete.  Alternatively, the payload could be set to be delivered together with any other download of an executable file.  It could also be combined with the use of your own web server, which comes conveniently included with Kali.

I haven’t yet played around with all the things that can actually be done once this backdoor is open, but ultimately, it looks like all that is required for me to get complete access to another device are fairly innocuous things – using a WiFi hotspot I set up, or clicking a link, or attempting to update their own software.  Even more striking was the demonstration that the Veil software payloads were considered “clean” by all antivirus software.

Much like “Defense against the dark arts” classes, the sequence of lectures on attack methods and vectors ended with a lecture on how to defend oneself against these sorts of attacks.  Worryingly, these again boiled down to:

1. Always make sure you’re using HTTPS
2. Don’t use networks you don’t control and/or trust completely
3. Verify checksums of all your downloads

These measures are all more active than convenient.  “I think the base consideration of one’s security is insufficiently paranoid unless one is optimistic enough about their fellow humans to not believe that anyone will go to the effort of trying to steal their data.”

There might be a point there, though.  Why bother stealing data when most people give it to Google, Apple, and Facebook for free?

Now I have got into vulnerability testing tools from the users’ perspective!  This week I set up a Metasploitable machine, to use Metasploit from my Kali VM to scan for vulnerabilities and generate tool output.  It’s very cool to see how Metasploit had writeups on the individual vulnerabilities and procedures to exploit them right from the command line.

Even cooler was Nexpose.  Again I got a solid overview of the sort of vulnerabilities found and how they could be exploited.  By referring to material outside the Metasploit Community, it feels very connected to the wider InfoSec world out on the internet.  The automatic report generation and automated scans were also handy features.

I have been working on some improvements to the base Dradis CE application this week as well, so this tied in neatly with the studies.  I have only just started with tool output generation, and already I’m manipulating data from Metasploit, Nexpose, and Nmap, all of which are supported in Dradis.  Now that I’m getting the actual user’s view of tool usage I can better put myself in the shoes of hackers starting out with Dradis for the first time to generate customised reports using data from multiple sources.

Having spent so much time with Dradis Pro, it’s fun to get back to basics with Dradis CE.  I’m not bothered by not having access to Word templates.  I gave up using Windows years ago, even my Steam library wasn’t worth the hassle of dealing with it – and I think there’s a lot of potential in well-made HTML templates.  For my purposes, learning and experimenting at home, and showing off to the people at the sailing club bar, it’s a good tool to play with; scan with all the tools and plug all the results into a simple collated report.

Next up in the course is client-side attacks; technical exploits as well as the social engineering exploits of the PEBKAC vulnerabilities!

The view from the bar

This week I finished up the section of the course regarding basic network hacking.  I learned some more about man-in-the-middle attacks, and got started with Wireshark to start actually analysing the data packets flowing through the network. Combined with attacks to make users use HTTP instead of HTTPS, that made target data (including usernames and passwords) totally readable and even searchable.

The obvious next step was “honeypot” attacks, creating a fake wi-fi access point using mana-toolkit. Combined with methods I learned earlier, this would make every user’s data transmitting through my fake network openly visible.  Once again I am struck by how easy all of this is, with freely available easy-to-use software and a cheap USB wi-fi device.  I am right next to a luxury marina and I have excellent mobile internet; it would be trivial to set up a fake hotspot to appear to be set up by the town for foreign visitors, and then ultimately read the visiting yacht owners’ data.

Having covered attacks and basic fake access point creation, I learned about preventing these sorts of attacks, for example by using Wireshark to look for unusual network activity and using XArp to detect ARP poisoning.  It was interesting to get a better look at more good reasons why the sysadmins of an organisation with a medium-sized or larger pool of devices face challenges protecting all their devices – hardly convenient to make the ARP tables static for hundreds of devices at once without good scripting and a good deployment system.

I have noted before that people and organisations in general seem to have a more lax view of data security than I would be comfortable with, but here at the system level, it feels a little more disturbing.  Perhaps I’m missing something, but I would think standard mass-market OSes like Windows, Ubuntu, Android, and such ought to have built-in tools for monitoring network safety and at least natively allow pop-up messages to show that your router appears to have changed its MAC address or that there are duplicates in the ARP table?  Microsoft regularly gets a lot of criticism for its update services, but how can their multi-GB updates not include simple utilities for guarding against MITM attacks?

By coincidence I’m looking into appropriate hardware for better internet connections on my boat, like a powerful active wi-fi range extender combined with mobile internet connections bridged into a router with failover.  If I’m going to be setting up a powered wi-fi antenna on the masthead, perhaps I should look at getting one with AP and Monitor mode capability…

Anyone for free wi-fi?

This week I have been learning about man-in-the-middle attacks.  This section of my course started out with learning more about network discovery, including my first hands-on experience with Nmap as an actual user.  First impressions of Nmap: it’s amazing how much data you can gather so simply.  Just discovering which devices are visible and which ports are open is very powerful information.  And then we get into the possibilities for exploiting that information!

Noodling around with MITMF is a lot of fun.  With just a few short commands and plugins, I could do cool tricks in no time:

• ARP spoofing for my Kali VM to become the MITM
• DNS spoofing – I get to decide which pages the victim’s browser gets sent to
• Screenshotting – I see what the victim sees
• Keylogging – obfuscated password field? Not to me!
• Javascript and HTML injection – here, have some popups

Two things really strike me here.  First, once again I’m astounded by how little is done for security or at least security-consciousness.  The above tricks were tested out using the MITM to turn HTTPS pages into HTTP.  Of course that’s a huge security issue, but the user-facing warnings in the browsers – particularly to people not in IT and not interested in computers, like my parents for example – are easy to ignore.  How likely are they to spot the missing padlock icon, how likely are they to even understand Firefox’s warning that the password field they are seeing is not secure?

Second, I’m always amazed by how powerful and excellent free open-source software can be.  MITMF, and indeed Linux (and Kali as a subset) are all free and anyone can modify them, yet a simple video guide showing a few simple canned commands allow anyone to potentially access very sensitive data.

I think there will always be a game of cat-and-mouse, with major developers trying to construct more secure software and communication, and the open-source world finding the vulnerabilities and exploits.  State actors will continue to try to exploit infosec vulnerabilities for snooping, and the open-source world will find ways to protect their data, for those with the will and know-how to do so.  I used to play with VPN setups, and I found that one that I made based on SoftEther circumvented state censorship easily – very cool stuff with a day’s configuration of a spare server.  Will the Great Firewall of China ultimately harm information security, or in the long term, will it lead to improving it?

China built and maintained the Great Wall to keep out foreign invaders. Even so, the Mongols invaded and built a Chinese dynasty

Earlier I looked at the security and privacy issues surrounding AIS (the Automatic Identification System) and other navigational aids aboard ships.  Today there was an interesting article about this on the BBC.  Essentially, while commercial vessels are generally required to carry AIS transponders on board, it is also possible to switch them off.  Vessels have therefore been able to bust sanctions by switching off their transponders, e.g. to make deliveries or enter ports that they are not supposed to.  However, satellite imagery combined with big data analysis is being used to combat this.

Surface ships do not really have anywhere to hide on the sea, so they can be tracked by satellite imagery.  Their shadows will change depending on the size of the load they are carrying.  Data is available regarding which ports in which locations typically load or unload which types of cargo.  The result is that it is now proving possible to track shipping and even types of cargo on the high seas, using data and satellites.  Not only does this make it possible to detect when ships are carrying out illegal activity, such as ship-to-ship transfers circumventing sanctions, but also shows changes in the flow of trade, such as oil tankers diverting en-route to new destinations based on fluctuations in oil prices.

I’m concerned about privacy implications.  Once again it shows how actors with access to significant resources – hardware manufacturers, state intelligence agencies, software companies – can extract more data from users (and even non-users!) of seemingly straightforward products and services than we may be aware of or be prepared to accept.  As the resources required for big data decrease, with cloud computing and accessible user platforms, the barrier to entry will also decrease.  If a country’s coast guard is capable of identifying vessels and their cargo on the high seas, that’s one thing – if a RIBload of pirates are able to do so as well, that’s another.

One of the techniques I enjoy for hiding data is steganography, hiding a message in plain sight disguised as something else.  After all, even the best cryptography is susceptible to “ball peen hammer decryption” if someone knows you have something to hide.  Incredibly, the principle of steganography has even been used at sea.

During the Second World War, the Japanese invasion of the Dutch East Indies left the Dutch navy in the area in grave danger.  Their ships tried to escape to Australia, but were all soon sunk – except for one.  The captain of HNLMS Abraham Crijnssen realised that their ship was all too visible at sea from the air – so in a stroke of mad genius, he had the warship disguised as an island!  Moving only at night, and slowly, they evaded detection and arrived safely in Australia 8 days later.  HNLMS Abraham Crijnssen served out the rest of the war operating out of Australia, and well done to the ship and her crew. Read more here!

HNLMS Abraham Crijnssen at sea