Welcome back to the Patchstack Weekly Security Update! This update is for week 30 of 2022.
This week I will finally get to talk about SSRF! SSRF stands for Server Side Request Forgery. This is a category of application vulnerability that is sometimes overlooked but could allow attackers to bypass security measures and turn a web application into a sort of limited VPN to pivot to systems normally protected by the network topology. Don’t worry if this doesn’t make sense right now, I’ll explain it more later.
This week’s vulnerability news will highlight a patched security bug in a premium theme, which could lead to a very bad day for users. Followed by the unfortunate news of multiple security bugs that went un-patched in a plugin that is now closed in the WordPress.org repository.
Stick around to find out more during the Vulnerability news, but first, it’s time for the weekly knowledge share so I can explain SSRF.
So what is Server Side Request Forgery about?
Much like CSV Injection, this classification of security bug will not harm the web application itself but uses the web application to target another system.
SSRF provides what infosec practitioners call a pivot. Pivots allow attackers to utilize access to system A to reach, and attack, system B. What makes this a pivot, is that system B is a service on a private network or was not intended for public access.
To make matters worse, it is common for systems on private or inaccessible networks to get less security hardening and attention. Assuming a service is secure because it is not publicly accessible lulls the operations teams to neglect security matters on these servers.
The severity is entirely dependent on how the network and server architecture is being managed. But, neglected servers and SSRF vulnerabilities are a very dangerous combination.
How does SSRF work?
SSRF is a security bug, let’s say in a web application, which can lead to attackers being able to communicate with systems not connected to the internet.
Attackers use SSRF security bugs to make the web application make requests to internal services which are controlled by the attacker. A web application with an SSRF bug in it can be turned into a very limited VPN of sorts, allowing attackers to communicate with servers running on internal private networks (e.g.. database, or backup servers) as well as services running on localhost (e.g.. redis, or memcached are two examples.)
The threat from SSRF increases if the network topology relies on network segregation for security. It is more common than you may think, but some IT crews skip performing security tasks (such as regular updates, hardening, and in some cases adding authentication) on servers not connected to the internet because they assume no one can access the service. A bad assumption to make.
SSRF does not always lead to compromise, but it could lead to one if there is a lackadaisical approach to security for internal services.
How to spot SSRF in PHP code?
Whenever you use a function that can pull data from a remote source, if that function is passed user-controlled values for the source, then you need to make sure that data is safe to pass to the function.
The problem is. There are a lot of functions that could make requests to remote resources in PHP. So many that I can not list them all. But I can point you in the right direction for what to look for.
Some obvious examples would be functions like fsockopen or cURL because their purpose is network communication.
Dependent on the server’s PHP configuration, then the include() and require() functions can make remote requests. The specific configuration is if URL include wrappers is enabled, then these functions can make requests from remote sources (this also opens a whole other can of risk related to an easy RCE if you allow include or require to pull from an attacker-controlled URL)
Surprisingly, PHP’s file reading and writing functions support multiple protocols and wrappers like HTTP://, SSH2://, PHAR://, and more. So, you need to watch out when reading file paths that have user-controlled variables in them as well.
There are a lot of ways PHP can read from remote sources. If a function is reading from a source that is generated using a user-controlled values. Then you will want to double-check the documentation, to be sure the value could be manipulated by a malicious user to make network connections.
If you find a function that accepts user input, and also supports network communication then that function could lead to SSRF. If you must use this function, that’s OK! You will just need to defensively code around it to prevent SSRF. This is true even if it only applies to certain configurations, it’s better to code defensively and secure the sites than it is to tell people to change their local configurations (like URL include wrappers I mentioned above.)
How can you patch SSRF?
Use Allow and Deny lists.
Whenever your code must accept user input for a source to read from or write to, your code should be acting like a bouncer at a club or concert. It should perform a quick check to see if the data is on the Approved list, or they check to make sure it’s not on a Deny list for causing trouble.
How to apply this in your code is up to you, but remember:
- You should check both the protocol (if any) and hostname.
- An Allow list works great for protocols. You can restrict requests to only HTTPS hosts, or the local file system only.
- A Deny list works great to make sure the request is not trying to reach out to protected hosts or IP addresses. These could be internal IP ranges (such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16) or hostnames like “localhost”
- Remember: Functions may have an unexpected ability to request remote resources. Double check the documentation.
Vulnerability news
GREYD.SUITE Theme -Unauthenticated File Upload vulnerability
Users of the premium theme GREYD.SUITE should update their site’s theme as soon as possible. Versions prior to and including 1.2.6.1 have a security bug that could allow unauthenticated users to upload arbitrary files. A dangerous bug to leave unpatched.
Easy Student Results plugin – Sensitive Information Disclosure
The Easy Student Results plugin has multiple security bugs reported in it, of which none appear to have been patched at this time. Users should be looking for an alternative plugin, or disable this plugin’s functionality until a patch is made available.
Thanks and appreciation
This week’s thanks goes out to the developers of GREYD.SUITE for patching that dangerous security bug. Great job.
Further thanks goes out to Kathy Zant of Kadence and StellarWP, who last Friday had a live stream chat for Patchstack::helpers. If you haven’t heard of Patchstack::helpers or Kathy’s history of helping others, please go check it out on Youtube!
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
