Welcome to the Patchstack Weekly Security Update, Episode 49! This update is for week 47 of 2022.
This week’s knowledge share will be all about how to find bugs in code – security bugs that is. I will share techniques I use for basic static code analysis and provide examples of what to look out for.
This week’s vulnerability roundup will once again highlight only WordPress components with unpatched security bugs.
Hunting security bugs with static code analysis
Knowing where to look is the key to finding what you’re looking for. When it comes to finding security bugs in code though, knowing where to look is essential.
In this week’s knowledge share, I will share with you a basic process for finding security bugs using static code analysis also known as SAST (static application security testing.)
All you need to bring with you is knowledge of what to look for, so I will share a few things to look for today.
Unauthenticated API actions
Let’s start with not a vulnerability, but something that would make a security bug much higher risk. We can all agree if we can find a security bug without the need for an authorized user account, then that bug is more severe.
So, how can we find a list of unauthorized actions in the WordPress API? We just need to search for API endpoints (AJAX actions) being created that require no authorization.
WordPress uses add_action() to create new endpoints, and if the “hook” for the endpoint starts with “wp_ajax_nopriv” then no authentication is required.
Searching for add_action(“wp_ajax_nopriv will give you a list of no authentication required endpoints, but you will still need to review every function that is being called by each endpoint. So, there is still a lot of manual work to do, but you have a starting point.
Object injection
PHP object injection or insecure deserialization bugs are easy to spot, you will want to look for any time user-controlled variables (like $_POST, $_GET, $_COOKIE, $_REQUEST etc..) are passed directly to unserialize().
It may look like this:
$lorem = unserialize($_COOKIE['ipsum']);Insecure instantiation
Finding insecure instantiation bugs is easy as well. To unearth this risk, look for code that passes user-controlled variables to the “new” constructor.
It may look like this:
$dolor = new $_GET['sit'];Insecure option update
This WordPress specific security bug happens whenever code allows user-controlled variables to choose both the key and value pair values sent to the update_option() function.
It may look like this:
update_option($_POST['amet', $_POST['consectetur']);Commonly misused functions
Sometimes what you want to look for is a common mistake, such as a function commonly misused for the wrong purpose.
Here are two examples I have seen in the wild:
is_admin() tells you if the request is from /wp-admin/, but I have seen many WordPress developers use this for Authorization checks. What they meant to use was current_user_can()
maybe_unserialize() will re-instantiate any string as long as it is a valid serialized string. Attackers will use valid serialized string to create valid objects found in the code base, so this function contains no protection against object injection.
Searching en masse
Now you know what to look for, but is there a way to look for bugs at scale? Of course there is – in fact, you have two options.
You can download the entire repository’s code base yourself and use a tool to search the source code directly. I personally use grep (because I am old school). You can scan any plugin’s source code that you have a local copy of.
If you want to get started ASAP, you can use a site like WPDirectory.net. Which is significantly faster than grep (I have first-hand experience with) at scanning the entire WordPress.org plugin repository.
Congratulations, now you’re doing SAST. This is a fundamental process for bug bounty hunting or for any project just get started with having a mature security model.
Vulnerability roundup
This week’s vulnerability roundup is once again a list of plugins without security patches added to the Patchstack database in the last 7 days. You may be surprised how many there are …
- ifeature-slider – Stored Cross Site Scripting
- wooswipe – Broken Access Controls
- ultimate-tables – Reflected Cross Site Scripting
- profilegrid-user-profiles-groups-and-communities – CSV Injection
- user-export-with-their-meta-data – CSV Injection
- wpb-show-core – Reflected Cross Site Scripting
- dpt-oauth-client – CSRF
- transposh-translation-filter-for-wordpress – Authorization Bypass
- add-multiple-marker – Missing Access Controls
- activity-reactions-for-buddypress – Broken Access Controls
- activity-reactions-for-buddypress – CSRF
- postmagthemes-demo-import – Authenticated File Upload
That is 12 unpatched security bugs in the last 7 days. Better than last week’s 20 unpatched bugs, but again I hope some of these developers were just delayed in providing a patch, and for their users’ sake, a patch can be released soon. But time will tell.
Thanks and appreciation
This week’s thanks go out to the members of the Patchstack Alliance who continue to identify and respectfully report security bugs in open-source components to our team so we can triage, verify and inform the developers of those projects.
If this week’s knowledge share sounded interesting to you, perhaps you too could join the Patchstack Alliance. If you join you will learn new skills or improve existing skills in security bug hunting and make the open-source world a better place.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
