Tag: security

TryHackMe – Basic PenTest

A long long time ago in a country far far away I worked briefly in a CyberSecurity organisation that performed pentesting and auditing. My main area of focus was network and network security, thus looking at network reachability, exposure, routing, and auditing (and hardening) network infrastructure, mainly Cisco routers, switches and firewalls.

I’ve focused more on the network side of architecture for the last decade after doing some time as a network security domain architect, so when I came across tryhackme and hack the box I was pretty excited to delve back into it.

I thought I’d start off with something pretty easy and thus what follows is my write up and experience. I’ll likely post a few more writeups as I do more machines as I mostly use this as a place to reflect and capture some of my experience, therefore this is likely not the best or most efficient example of how to pwn these machines, but that is not the point… it is to have some fun and hopefully learn (and dust off) some new skills along the way.

I decided to start off with the ‘room’ called Basic Pentesting which utilises:

  • service enumeration
  • brute forcing
  • hash cracking
  • Linux enumeration

I’ve tried to provide some of the more interesting screen shots but also provided the video if anyone wants to watch me stumble through it.

I typically start of with a NMAP scan:

My typical nmap command variables are:

-sV: Probe open ports to determine service/version info

-sC: equivalent to –script=default

These are typically not to slow and provide a good amount of data to progress with. I normally also use -v so I can see the output in progress for a full command of:

nmap -sC -sV -v -oN <output file> <ip address>

Whilst that is running I’ll check out if the target is running a web service, and look at the html code to see if there is anything obvious or if I can see what languages are being used. The site listed as under maintenance but the source had a comment to check the ‘dev notes section’. I could start busting directories with gobuster or dirbuster but decide to just try some manual directories and after a few tried find the /development directory which has a few notes providing a clue to two users J and K and also that J is using a weak password.

I also note that SMB is running from my nmap scan and as nmap indicated the server was Ubuntu decide to run enum4linux. This is probably a good place to point out that as this is a for purpose ‘hack’ box I’m not worried about being noisy, but in a real world pentest one would typically try and be more stealthy and mask some of the scans and enumeration. Enum4linux shows that SMB has ‘Anonymous’ access enabled so I connect via the command: smbclient //<IP address>/Anonymous and find a text file that provides the users name of ‘Jay’ and ‘Kay’.

I already know that Jay’s using a weak password so it is a good opportunity to try and brute force the password, which I do with hydra, using the command:

hydra -l jan -p <password list> ssh://<IP address>

As you can see I utilised ‘jan’ as the user and ‘rockyou.txt’ as the trusty password list and after a few moments managed to brute force the password. Now having Jan’s password and knowing that SSH is listening from the NMAP scan I connect using Jan’s credentials.

I poke around a bit but decide to upload linpeas which is a great Local Linux Privilege Escalation checklist script. This shows that Kay’s private key is readable from Jan’s access so I grab Kay’s SSH private key ‘id_rsa’.

I first attempt to connect using Kay’s SSH key but it is protected with a passphrase.

It is now time to try and crack Kay’s private key with John the Ripper. I first convert the private key into a format for use with JtR, using ‘ssh2john’ and then get to cracking. I manage to crack Kay’s SSH key with the command:

john <Kay's ssh key> <password list>

Once we have cracked the passphrase we can use Kay’s SSH key and the cracked passphrase to SSH into the target as Kay using these credentials, which enables me to find the final flag for this room.

Final Thoughts

This was a great way to get back into the groove as whilst it was simple it did utilise a few different techniques to achieve the goal of obtaining access to the target. There are a few other methods that I would potentially try if doing this again as whilst this room is easily achieved with tools or scripts there are more manual methods that could achieve the same outcome, but hey why reinvent the wheel…

I really think that regardless of your level or experience these hacking sites are a great way to improve your skills but perhaps more importantly provide some insight into how to consider deploying and managing your own network, specifically hwo they can be protected, be it at home or for the organisation you work for.

As mentioned this room was basic and didn’t require any new or not already established vulnerability, but as a lot of people in the IT industry know, most breaches are via know and published vulnerabilities and exploits, but further to that it also leans into how technology is connected and security really is only as strong as the weakest link.

Addendum: As I have started playing around more with tryhackme and hackthebox, I’ve come across many great experts in the community that provide a much more detailed, correct and entertaining view into cybersecurity and I’d like to shout out to some of my favorites, being John Hammond and IppSec. I recommend you search them up on youtube as they have a lot of great content!

Update 12/07/21: I recently re-did this room so I could record it and provide a link here: https://youtu.be/pFnSCaN4kGA

Passwords are so passe

Passwords are ubiquitous when dealing with user authentication but are perhaps also the weakest link in security authentication. They generally require the user to maintain a complex yet easy to remember string which can be somewhat of a contradiction as the requirement to recall the string, generally leads to it being, based on, or related to, a known word or something personal to the user, and ultimately easy for a human to remember, and hence reduces complexity and randomness. A possible work around to this issue is to not allow user (human) generated passwords, and rather have the password automatically generated by an application using suitable complexity, however this tends to lead to other issues such as users documenting their password or reusing the same password on many systems.

Perhaps the best method to date is to use a password manager. I started doing this myself a couple of years back and while each have their pros and cons, I’ve never looked back

In 2010 an analysis was performed on the 32 million passwords that were publicly published from the December 2009 Rockyou.com breach.

Some of the key findings of the study include:

  • About 30% of users chose passwords whose length is equal or below six characters.
  • Moreover, almost 60% of users chose their passwords from a limited set of alpha-numeric characters.
  • Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on). The most common password among Rockyou.com account owners is “123456”.

Additionally, further studies show that this insecure trend sadly doesn’t shift as 26% of users reuse the same password for important accounts such as email, banking or shopping and social networking sites.

To provide some context the following tables represent the approximate maximum time required to guess each password using a simple brute force “key-search” attack.

mixed-62

As can be seen using only mixed alpha and numerical characters even for a password with a character length of 8 it is still feasible to retrieve the password in a short time. It also should be noted that there are many ways to improve the speed that these passwords could be cracked.

mixed-96

Even using all 96 mixed alpha, numerical and symbols for a 6 character length password does not provide enough complexity.

The NASA guidelines, recommend that all passwords be at least eight characters, and contain a mix of four different types of characters – upper case letters, lower case letters, numbers, and special characters such as !@#$%^&*,;” If there is only one letter or special character, it should not be either the first or last character in the password.

Additional to password complexity guidelines other factors should be taken into account such as:

  • Not displaying the password as it is being entered or obscuring it as it is typed by using asterisks (*) or bullets (•).
  • Requiring users to re-enter their password after a period of inactivity (screensaver)
  • Using encrypted tunnels / protocols (SSH, IPSec, SSL) to protect transmitted passwords.
  • Limiting the number of allowed failures within a given time period (to prevent repeated password guessing).
  • Introducing a delay between password submission attempts to slow down automated password guessing programs.
  • Requiring passwords are not shared between users / systems.
  • * Requiring periodic password changes.
  • The frequency for periodic password changes is a widely debated topic and whilst the accepted dogma was to force password changes somewhere between 3-6 months, recently some more evidence has come about that suggests that forcing password change is perhaps, not a good idea, in fact less secure.

More details can be found here.

However given the general insecurity of relying on passwords for authentication it is recommended that these be coupled with some other form of security, such as, two-factor authentication, limiting access, and regular password assessments.

My View:

All systems should enforce that mixed alpha, numerals & symbols be used, with a minimum of 8 characters to ensure suitable complexity.

Additionally, user and administrator passwords are periodically audited to ensure they meet the requirements for complexity and are not based on easy guessable or brute forced dictionary words, and the same passwords are not used by the same person on multiple systems with differing security risk levels.

If possible a password manager should be mandated. Whilst this is a cost for the company this is IMHO far outweighed by the increased security and ease of use which can be applied. Most modern password management applications also support auto filling in forms and passwords which can greatly improve the user experience whilst only requiring the user to remember one secure password.

If possible users should be encouraged to use passphrases rather than passwords as these are generally longer and more complex than passwords.

Finally, one of the biggest security concerns with passwords is protecting them, thus ensuring they are salted and encrypted when stored on any system is paramount, so if when they are stolen it is not feasible for the attacker to decrypt them.