Blog

  •

    [CTF] HTB Tabby write-up walkthrough

    4.87 of 109 votes

    This is my write-up and walkthrough for the Tabby (10.10.10.194) box user flag. Tabby is a Linux machine with some interesting web app CVEs to play with. I enjoyed using the Pwnbox feature in my last hackthebox write-up so decided I'd give it another go on this one. When commencing this engagement, Tabby was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough I spun up a new Pwnbox instance from the HTB dashboard and installed my VPN server key for my region. Once the VPN server key was installed, I then pinged the target 10.10.10.194 to check if my instance could reach the Tabby machine. To make things easier moving forward, I always opt to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label tabby Now this was set, I could begin some basic recon. As part of my standard recon routine I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV tabby -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated ports 22, 80, and 8080 were open. This confirmed the server was running a web service and SSH. I visited the IP address in my browser (port 80). I had a look around and noticed that the statement at the bottom of the landing page relating to a data breach hyperlinked to the address http://megahosting.htb/news.php?file=statement As this was unreachable, I added the domain to my existing hosts file for 10.10.10.194 so I could also reach it at tabby I was unable to find anything of interest in the page content for the issued statement, but noticed the requested statement was being passed in the file parameter. I wondered if it might be vulnerable to path traversal or SQLi. I decided to use Burp to automate a fuzzing technique demonstrated in my previous path traversal attack tutorial. This fires a list of common path traversal attack strings as requests and compiles a list of the HTTP status code responses. After reviewing this list, I could see there were some anomalies indicating traversal was possible. The first location I reached was the /etc/passwd located at http://tabby/news.php?file=../../../../../../../../etc/passwd I could see at the bottom of the file, the users tomcat and ash existed. The next location I reached was the /etc/hosts located at http://tabby/news.php?file=../../../../../../../../etc/hosts This confirmed information I already knew and concluded my port 80 recon so I moved on to port 8080 and visited http://tabby:8080 to see if it was reachable. This confirmed the server was running Apache Tomcat 9 and at the bottom indicated more user information might be present at http://tabby/news.php?file=../../../../../../../../etc/tomcat9/tomcat-users.xml However, when I tried this file location it didn’t exist. I was also conscious at this point that my earlier path traversal fuzzing had not enumerated this path and file location in the results. I then tried manually amending the path until I reached a blank page at http://tabby/news.php?file=../../../../../usr/share/tomcat9/tomcat-users.xml Viewing the source of this page then gave me the XML file markup. This file provided user credential information for the user tomcat with password $3cureP4s5w0rd123! I got stuck at this point for a while so ended up looking back at my notes and searching on Google to see if there were any vulnerabilities in Apache Tomcat 9 that might help me get a shell. My research showed me that Apache Tomcat 9 uses WAR (Web Application Archive) files to deploy web apps via servlets. These are a bit like JAR files, but contain everything the web app needs (such as JavaScript, CSS, etc), and according to Apache Tomcat 9 support documentation are controlled via commands from the manager application located here: There was evidence in the public domain that Apache Tomcat 9 was previously vulnerable to a malicious WAR file upload vulnerability, but I had no idea if the specific version running on this server was patched or not. I decided to try anyway. My first step was to search for a module I could use in Metasploit, then see if I could leverage that to craft and upload a tailored WAR file backdoor. I went for the java/jsp_shell_reverse_tcp module and configured a reverse shell to listen for a connection from my machine 10.10.14.62 on port 1338. I then used curl to push the newly generated WAR file to the Apache Tomcat 9 manager application using the credentials I had found before. However, before I executed this, I needed to setup a listener using netcat on my own machine to listen for connection requests on the desired port 1338 Now I could execute the reverse shell. netcat confirmed the reverse shell was active and I could see I was connected as the user tomcat I then spawned a tty shell to help me navigate and interact. I had a look around and moved into the /var/www/html/files directory which listed what appeared to be a backup file. I converted the compressed file to base64 and copied the verbose output, then used echo to rebuild the file locally on my machine. When I attempted to access the file I could see it was password protected. I fired up frackzip and ran it against the famous rockyou.txt wordlist to see if I could bruteforce the password. After about 15 seconds, frackzip found the password admin@it Recognising that passwords are sometimes shared, I then went back to my shell and tried to use this password for privilege escalation. I found it worked successfully on the user ash. I then listed the contents within the directory and opened the file user.txt which gave me the user flag.  

  •

    DDoS attacks and how to mitigate them

    • General
    • by Jacob Riggs
    • 01-07-2020
    4.99 of 97 votes

    In this era, cyber-attacks are gaining in popularity with more sophisticated techniques and attack deployment strategies being seen in the wild than ever before. DDoS (Distributed Denial of Service) attacks have gained popularity over the years, and as network systems advanced these types of attacks grew to become more refined. Many types of DDoS attacks now exist including HTTP flood attacks, SYN flood attacks, volumetric attacks, DNS amplification attacks, UDP flooding, ICMP flood attacks, and many others. In this blog post, I will walkthrough the basic and advanced concepts of a DDoS attack, what they are, the different types, and how companies can mitigate DDoS attacks with preventive techniques or measures to mitigate their effects. What are DDoS attacks? DDoS attacks or Denial of Service attacks are a malicious attempt to disrupt services offered by a server. In a typical DDoS attack, the intent of the attacker is to disrupt normal traffic of the target by maliciously overwhelming it with a coordinated flood of traffic, consequently denying any legitimate traffic access to the service. This attack is possible by bridging various types of computers and devices into a centrally controlled botnet and collectively pointing them all towards a target endpoint. As multiple systems are required to carry out a DDoS attack successfully, IoT devices are the low-hanging fruit for attackers aiming to grow their own botnet. This is because the nature of the IoT market means manufacturing processes are often rushed and security controls are considered secondary. As a result, many IoT devices are released with high severity vulnerabilities which are trivial for opportunistic hackers to exploit. Types of DDoS attacks There are many ways to disrupt or suspend a server’s resources or computing operations, and hackers have found various ways to overwhelm servers using various simple techniques. Approaches like using botnets and automation to issue requests demand the targeted servers employ more computational power to handle them. Thus, most of the time, such attacks are successful. DDoS attacks can be broadly divided into three types, which reside within specific layers of the OSI model. The layers of the OSI Model The first type are volumetric attacks. In this type, the attacker intends to saturate bandwidth of the target server and measures the intensity in bits per second. These include spoofed packet floods, ICMP floods, and UDP floods. The second type of attacks are protocol attacks, which are together termed Layer 3 and Layer 4 attacks. These are initiated by targeting vulnerabilities in the network and transport layers of the OSI model. In this type, the main intention is to consume computational resources and can impact the infrastructure used to manage network traffic, such as firewalls and load balancers. The third type are known as application layer Attacks. These include flooding GET / POST requests for images, files, or other large file size assets. These attacks are intended to crash the server and the intensity is measured in requests per second (rp/s). A higher rp/s rate leads to a faster server crash. Layer 3 (L3) attacks This type of attack takes advantage of flaws within the network layer protocols of the OSI model, and commonly include: Ping flood attacks – in this type of attack, the attacker attempts to crash the server by flooding it with ping requests until the server crashes. Smurf DDoS attack – early implementations of ICMP inherently had poor validation measures which made it easy for an attacker to spoof an IP address in an ICMP request. When using this in the context of a DDoS attack, the attacker sends a series of ping requests to thousands of servers. Once the requests are sent, the attacker then spoofs the target IP address and directs the response to the target system rather than their own IP address. However, this is now an uncommon attack vector as modern infrastructure is rarely vulnerable to this type of attack. ICMP ping of death attack – in this type of attack, the attacker deliberately sends ping requests with IP packets that are greater in size than the maximum allowed by the IP protocol. The network infrastructure, in accordance with TCP/IP, then divides the whole request into chunks that are processed and sent in request fragments. However, when all these fragments are combined together at the target server for processing, the server is unable to handle the computational demand and crashes. For this reason, many modern servers block ICMP requests altogether to prevent any variations of this attack getting through.   Layer 4 (L4) attacks In this type, the objective is to increase the number of packets sent in under a second to the point that the server crashes. The impact is measured by packet per second (pp/s). In this type of attack, a service running on the server is usually targeted rather than the server itself. SYN DoS/DDoS attack – in this attack, the attackers exploit the ‘three-way hand shake’. This is done by exhausting the target’s resources by waiting through the TCP Timeout period one after another. In this way, the TCP handshake is never completed and the buffer is full of other waiting TCP handshake requests coming from legitimate sources. Eventually, the server crashes due to timeout requests and an overwhelming amount of resource consumption. SYN-ACK flood attack – In this attack, the attacker attempts to occupy all the space in a target server state space by sending SYN requests from spoofed IP addresses. Once the state space of the target server is full, it has insufficient free space to handle legitimate requests.   Layer 7 (L7) attacks These attacks are prevalent on the application layer of the OSI model, and commonly include: HTTP Flood attack – in this attack, the upper layer of the of the target application is overwhelmed with HTTP requests. The attacker exhausts the server’s resources by saturating it with GET and POST requests for images, files, or some other asset from a targeted server. DNS amplification attack – in this attack, the goal is to flood a target with fake DNS lookup requests from open DNS servers that consume network bandwidth to the point that the site fails. WordPress DoS/DDoS attack – in this attack, the concept of XML-RPC (Remote Procedure Call) is leveraged by an attacker. The pingback feature is exploited when multiple links can be generated from a compromised host which sends more requests for data from a WordPress server than the target can handle.   The impact to companies DDoS attacks create more requests to a server than it can handle, thus refusing the incoming requests of legitimate traffic and customers. As websites are the common gateway to a company’s services, disrupting a web server’s capacity to handle requests can temporarily take a company offline. Where business operations might rely on consistent uptime and availability, service disruptions and outages have the potential to cause significant financial loss and may result in irreparable reputational damage. This not only affects customer trust and satisfaction, but also makes customers move away from online platforms which ultimately brings the customer base down. With a lower customer base, companies are likely to experience reduced revenue and lower conversions. This is why DDoS mitigation measures and techniques are important to consider befoe they occur. DDoS Attack Detection Detection of an active DDoS attack depends on the attack size, the targeted server’s capacity to handle the incoming requests, and whether or not any uptime or performance monitoring systems are already deployed to trigger alerts. The immediate impact of attacks can range from intermittent performance issues such as slow form submissions and page rendering, to issuing 503 error responses and complete server crashes. The following server-side commands can help manually investigate and identify an attack source: Windows: netstat -ano Lists all the listening ports and their connections to remote IPs. netstat -ano | find /i /c “80” Lists all active IP connections being made to port 80. netstat -na 1 | find “{216.58.204.238}” Lists all active IP connections being made to 216.58.204.238 (example IP). Linux: netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n Lists the number of connections each IP address makes to the server. netstat -anp | grep 'tcp|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n Lists the number of connections the IP's are making to the server using the TCP or UDP protocol. netstat -ntu | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr Lists only ESTABLISHED connections, and displays the number of connections for each IP address. netstat -plan | grep :80 | awk {'print $5'} | cut -d: -f 1| sort | uniq -c| sort -nk 1 Shows a list of IP addresses and the number of connections that are connecting to port 80 on the server. For coordinated attacks from multiple source IP addresses, it can be useful to determine whether or not the connections originate from common subnets (such as /16 or /24). netstat -ntu | awk '{print $5}' | cut -d: -f1 -s | cut -f1,2 -d'.' | sed 's/$/.0.0/' | sort | uniq -c | sort -nk1 -r Lists any connected IPs from the same /16 subnet which start with the same two octets (e.g. 216.58.xxx.xxx), and their number of connections. netstat -ntu | awk '{print $5}' | cut -d: -f1 -s | cut -f1,2,3 -d'.' | sed 's/$/.0/' | sort | uniq -c | sort -nk1 -r Lists any connected IPs from the same /24 subnet which start with the same three octets (e.g. 216.58.204.xxx), and their number of connections. DDoS Attack Mitigation DDoS attacks require proficient knowledge and understanding of network security controls to properly mitigate. Once an attack has been detected and the abusing IP address identified, manual steps can be taken to block it. route add 216.58.204.238 reject Blocks 216.58.204.238 from reaching the server. route -n | grep 216.58.204.238 A way to validate if the block was successful. For automation, one or more of following solutions are typically deployed in hardened network infrastructure: Intelligent DDoS mitigation solutions – these are full-fledged systems which deflect and absorb large DDoS attack requests. The providers of such solutions provide load balancing with a scalable distributed architecture and allow for assets to be served through a CDN. Blocking bad traffic – protocol attacks can be mitigated by blocking bad traffic and allowing only legitimate traffic from authorised hosts. These solutions rely on a system which determines from request characteristics whether or not specific requests to a server are legitimate (through a human) or an attack (through a bot or automated). Absorbing based mitigation –a global network of scrubbing centers that scale, as needed and on demand, to absorb large-scale DDoS attacks. DDoS protection for IPs – this mitigation technique includes protection for L7 attacks that target particular websites or services hosted in the cloud. This is now mostly adopted by companies who opt to use cloud-based infrastructure. DDoS protection for websites – this approach detects malicious requests to web servers and protects websites against L7 attacks that target web applications. It is achieved by deploying a cloud-based web application firewall (WAF) to block malicious bots and requests. DDoS protection for networks – this type of solution protects networks with high-packet processing capabilities which mitigate some of the largest DDoS attacks. The various deployment models used to achieve this mitigation technique include GRE tunnels, Equinix Cloud Exchange, and Cross Connect. A flow-based monitoring approach is also deployed where needed along with support for automatic switch-over. Top DDoS Mitigation Solution Providers There are a number of third-party providers on the market offering high-capacity on-demand DDoS attack prevention, detection, and mitigation services. Below are some of the top providers I would recommend. Cloudflare Akamai Imperva  

  •

    [CTF] HTB Traceback write-up walkthrough

    4.91 of 92 votes

    This is my write-up and walkthrough for the Traceback (10.10.10.181) box user flag. Traceback is a Linux machine which was a little more challenging for me than I expected. This was my first CTF effort in quite some time and I wanted to refresh my learning. HTB (hackthebox) has also introduced a new Pwnbox feature, which is a custom web-based Parrot OS VM. This utility is a perk of HTB's VIP membership, and I was keen to test it out in practice. When commencing this engagement, Traceback was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough First I spun up a new Pwnbox instance. Once this instance was running, I then installed my VPN server key for my desired region. Once the VPN server key was installed, I then pinged the target 10.10.10.181 to check if my instance could reach the Traceback machine. To make things easier moving forward, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label trace Now this was set, I could begin some basic recon. For this I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV trace -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated ports 22 and 80 were open. This confirmed the server was running a web service and SSH. I visited the IP address in my browser (port 80). I could see the web server running indicated a backdoor existed. I decided to take a look at the source code of the page to see if there was anything of interest. A comment left behind suggested ‘some of the best web shells’, hinting the backdoor might be a popular web shell. I decided to Google some of the most known web shells to compile a list. I then ran the list in Gobuster, which is a tool designed to aid in directory traversal and discovery, which enumerates any directories, pages, scripts, assets, and files that exist by submitting predefined names as requests and looking for HTTP 200 status code responses. Success! Gobuster was able to identify that smevk.php existed in the root domain. I visited this in my browser as https://10.10.10.181/smevk.php to see if I could reach it. I was presented with an admin login page. I wasn’t familiar with this web shell, but knew that most come with default credentials, so I tried some of the most obvious. Luckily, the form accepted username admin with the password admin on my first try. I could see a command line field within the interactive web shell, so I tried to identify if the server had Python or Perl installed. My objective now was to set up a reverse shell. This would allow me to instruct the target machine to connect to my machine and accept commands. I could see the server supported and understood Perl, so now I needed a reverse shell written in Perl. I searched Google for a reverse shell cheat sheet to see if I could grab a template for one. This code would open a socket and establish a connection on a specific IP and a specific port. Once I amended the IP and port values to reflect my own IP 10.10.14.252 and the desired port 1338 I was reserving for this attack, I could run this in the interactive web shell command line to start my reverse shell. However, before I executed this, I needed to setup a listener using netcat on my own machine to listen for connection requests on the desired port 1338. Now I could execute the reverse shell. netcat confirmed the reverse shell was active. I could see I was in the home directory as user webadmin. As netcat had previously indicated tty was inactive, I used /usr/bin/script -qc /bin/bash /dev/null to spawn a tty shell to help me navigate and interact. I then checked what was in the home directory and found sysadmin and webadmin. From here navigated to the webadmin directory and used ls -lah to list the folder contents. I could see there was an .ssh folder so proceeded to generate my own public key to add to the authorized_keys subfolder. I then navigated to my newly generated public key and opened it in a text editor. This allowed me to copy the key and write it into a command which would insert it into the target machine's authorized_keys subfolder. I could then use ssh -i key webadmin@trace to establish an active and stable SSH connection to the target machine. From here I list the directory contents and see two files note.txt and exploit.lua. I opened the note.txt using cat note.txt This message from the sysadmin suggested there was a tool coded in lua, which matches the exploit.lua in the same directory.. I opened the exploit.lua using cat exploit.lua I have little experience in the lua language, so I Googled this specific syntax and identified this is a common command for spawning an interactive system shell. Running sudo -l identifies that the user webadmin can access /home/sysadmin/luvit using sysadmin without a password. I chained this to the lua command to attempt privilege escalation. This was successful. From here I navigated to the /home/sysadmin directory and listed the folder contents. Opening the file user.txt gave me the user flag.

  • Nothing is more monstrous than man

    4.84 of 95 votes

    Fiction can teach real and important lessons. Contrary to popular belief, Frankenstein was actually the name of the doctor that created the infamous monster. There is an almost poetic irony in the fact pop-culture always fails to recognise this important distinction between Frankenstein and his creation. Much like the symbolic nature of the unknown, unnatural, and unexplained, the hideous creature Frankenstein created was nameless. What was done to the nameless creature was monstrous, and this is what eventually created a monster. In my experience, this story seems to echo the natural consequence of social participation today. Interior feelings trump facts and anything unknown, unnatural, and unexplained that doesn’t align with the narrowly defined status quo is often expelled or petitioned for censorship. Any discourse against the curve of political correctness can quickly turn hostile, resulting in polemic attacks and ad hominem arguments that create more monsters than they target. The misunderstood are outcast. Why? Because we’ve allowed ourselves to be consumed by the serenity of convenient truths and the comfort of insulated exposure. We were raised in an environment of Fisher-Price rounded corners, talking costumed animals, and irenic fairy-tale endings to believe the world is one of cordial culture and civility. This lie has made many of us intolerant toward dissent, and now we’ve shamefully become a content moderated collective that can only accept the world through the lens of filtered selfies, Hollywood heroes, and picturesque celebrity lifestyles. This comes at a social cost. Silenced outcasts become nameless. Anonymous prey-turned-predators left to wander the deep dark recesses of their own minds, assembling hideous thoughts from parts of exhumed ideas until their voice someday returns to life. As if rising from the lab table something different, the troll inhabitants of the Internet, but far from folklore. Nietzsche nailed it. Real monsters live in the abyss of every mind – and when you gaze long enough into your reflection and the monster inside you gazes back, consider that maybe just on the other side of this life is another. Like an unfinished book you muse over until you reach a blank page where the story ends and you’re left alone with yourself and your thoughts. There lives the scariest monster. Nameless and frightful. One that even the most powerful drugs cannot slay, and one that you may someday need to face yourself, lest someone else face it first.If we don’t like these monsters we’re creating then maybe we should consider the Frankensteins we have ourselves become — as like most, they become a part of our imagination or a part of ourselves. Much is monstrous, but nothing more monstrous than man.

  •

    Useful network posters you can download and print

    • General
    • by Jacob Riggs
    • 03-06-2020
    4.93 of 97 votes

    I decided to put together some minimalistic posters on network fundamentals that people can download and print for free. I hope these might help individuals, academic institutions, or maybe even companies with an IT ops function looking to decorate their office space with useful reference material. Download OSI + TCP/IP Common Ports Network Topologies All posters are A3 (297mm x 420mm) in size. I therefore recommend that if you wish to print these, you do so in A3 format between 600 and 1200 dpi for optimal print quality.If you like these posters or find them useful for your work, please consider sharing them with friends and colleagues.

  •

    In memory of my friend Craig Warden

    4.92 of 121 votes

    My colleague and friend unexpectedly passed away last year and I wanted to share a few lasting words which I hope might venerate our friendship and pay tribute to his memory. Craig Allen Warden 16 December 1970  —  13 April 2019 I’ve considered writing something for a long time, but my personal blog is hardly a podium for obituaries and mournful proclamations. Finding the right words has been difficult. I met Craig whilst working at the Guardian newspaper. He was the Head of HR at the time and we met during the natural course of our employment. Working with Craig was always entertaining due to his eloquence. He was quick-witted, had a jovial personality, and always knew how to bring out the best in those he worked with. He would always greet me with his signature “Hello matey!” in a skewed accent (which took me a while to place). Our social relationship was never linear. More often than not we would end up in protracted conversations. Even impromptu corridor banter would at times overrun and command a fleeting wave or a witty one-liner adieu. I like to think this was testament to our discussion value, but looking back I think we just got along well. We always had to rush back to work to avoid being late, but every chat was refreshing and worthwhile. I think about Craig a lot, and often find myself revisiting the moments we shared. This short blog post does the salient volume of his life little justice, but I find solace in knowing it might resonate with the people that were lucky enough to have known him, and maybe serve as insight to those that never had the chance. See you in another life, matey.