Activity Feed
Technical Analysis
This exploit is ok. When running on my attack box I had to modify the code. Not the worse case. Just a few commands threw syntax errors. In the end the CVE was able to provide a salt and hash that gave me credentials to get into the box.
Technical Analysis
This is a rather neat vulnerability IMO.
Easy WP SMTP versions <= 1.4.2 has a non-default debug option. When set, the WordPress plugin creates a [a-z0-9]{5,15}_debug_log.txt file in the wp-content/plugins/easy-wp-smtp/ directory. Problem is, this folder allows directory listings, so the file can easily be accessed. The debug log file contains SMTP logs for the Wordpress instance.
Attack chain is as follows:
- find the debug_log file
- request a password reset for an account
- read the debug_log file which will have the password reset link for that user
- use the link to change the password for that user.
Pretty easy to exploit, but but not necessarily in an automated way since the password change may have unknown requirements. Easy to do manually though!
The file may also contain creds for the SMTP server!
Technical Analysis
Blind SQLi in Chop Slider 3 by iDangero.us. The true value of this exploit is low, simply because the company stopped supporting the plugin several years before the exploit was discovered. Most users had therefore moved away from the plug-in before disclosure.
The iDangero.us Chop Slider 3 WordPress plugin prior to version 3.4 contains a blind SQL injection in the id parameter of the get_sript/index.php page. The injection is passed through GET parameters, and thus must be encoded, and magic_quotes is applied at the server.
Exploitable in default config, a valid id is not required.
Technical Analysis
Original advisory and PoC can be found at https://github.com/pear/Archive_Tar/issues/33
This vulnerability is very similar to CVE-2020-28948, with a couple of key differences. In the case of CVE-2020-28948, the root issue was that the code within Archive_Tar didn’t use case sensitive checks to ensure file names didn’t start with phar://. Here the issue is the same however it stems from a lack of checks. More specifically as mentioned in my writeup on CVE-2020-28948, Archive_Tar prior to 1.4.11 checked, using strpos(), that filenames within a TAR archive did not start with the characters phar:// and did not contain the characters ../ or ..\.
Notice however that there is a problem here: we can still use any other file stream wrapper other than the phar:// file handler within a file name to trigger the corresponding wrapper handler. A full list of PHP file stream wrappers can be found at https://www.php.net/manual/en/wrappers.php.
Looking at these stream wrappers reveals there are a few that might help with file writes. In fact, as shown in the PoC at https://github.com/pear/Archive_Tar/issues/33, if one creates a file within a TAR archive with a name such as file:///etc/passwd, then when the TAR archive is extracted, the corresponding file, which in this case would be /etc/passwd, will be overwritten with attacker controlled contents, assuming the user that PHP is running as has permissions to create or overwrite that file.
This leads to an arbitrary file upload vulnerability whereby an attacker could potentially overwrite existing files with arbitrary content. The attacker would however need to know the exact path on disk to the file that they wished to write: remember that ..\ and ../ are not allowed in filenames and even if they were, the file:// stream wrapper requires the use of absolute paths.
Again as noted in my writeup on CVE-2020-28948, this bug entirely depends on the fact that a vulnerable application makes use of this library and also extracts the contents of the TAR file as part of its operations. If the application only allows TAR file uploads but it doesn’t actually try to extract the contents of the TAR file as part of its operations, then this vulnerability will never be triggered.
That being said assuming an attacker does know the right path and the application is set up in to extract TAR files, then this can easily lead to RCE via overwriting existing PHP files on the target system.
Technical Analysis
Description
On January 12, 2021, Steven Seeley (aka mr_me) published a blog post on a zero-day patch bypass for Microsoft Exchange CVE-2020-17132, a post-authentication code execution vulnerability that was itself a patch bypass for CVE-2020-16875. The patch for CVE-2020-17132 is effectively a series of six checks that are run against cmdlets passed to Exchange Server to ensure exploit attempts against CVE-2020-16875 are rejected. As described in Seeley’s blog post, this latest patch bypass allows attackers to use call operators to circumvent all mitigations applied in the patch for CVE-2020-17132; this allows attackers to execute commands with SYSTEM privileges.
There have been no reports of active exploitation at the time of writing, but an unpatched zero-day vulnerability makes a high-value target for attackers. We consider this new vulnerability to be an impending threat, and active exploitation is likely before long.
Affected products
Currently, the following supported versions of Exchange Server 2019 and 2016 are vulnerable:
- Exchange Server 2019 (CU8 CU7)
- Exchange Server 2016 (CU19 CU18)
Rapid7 analysis
As of January 12, 2020, both rich technical detail and proof-of-concept (PoC) code are readily available to the public, including researchers and attackers looking to build exploit chains of their own. Rapid7 researchers were able to reproduce the RCE on a vulnerable instance of Exchange Server 2016 CU19 on Windows Server 2016. Authentication presents somewhat of a barrier to exploitation, but it should not be relied upon as a long-term preventative hurdle. As we have seen with previous Exchange vulnerabilities, once attackers gain authenticated access (e.g., via phishing), the impact of exploitation is high.
Guidance
Microsoft Exchange customers who have Exchange Servers that are internet-facing should strongly consider investigating their environments for signs of compromise and suspicious activity. We also urge all defenders to ensure Exchange Server is not exposed to the internet until the appropriate patches have been released by Microsoft.
Technical Analysis
Edit: PoC code for this can be found at https://github.com/pear/Archive_Tar/issues/33 along with the original advisory.
An interesting vulnerability using the concepts of PHAR file deserialization as first discussed at BlackHat in this video: https://www.youtube.com/watch?v=OrEar0TiS90. For those who don’t know, the phar:// file stream handler allows opening PHAR files, which are basically PHP archive files containing a bunch of related files (mostly tends to be PHP files within the archive, but can be other things as well). Whats interesting about PHAR files is that their metadata is formed via a serialize() call when their created, and when files are extracted, unserialize() will automatically be called on that metadata string. This leads to the potential for serialization attacks even when the application doesn’t explicitly use unserialize() calls.
In this case, the Archive_Tar developers were aware of this prior research and attempted to explicitly block phar://, ../, and ..\ within any file name contained with the tar archive by performing a strpos call using these strings and erroring out if the string contained these characters. Unfortunately that check is really poor for a number of reasons.
The specific reason related to this CVE, aka CVE-2020-28948, is that users can simply use PHAR:// to bypass this check. In other words, the check performed by strpos() is not case sensitive, so one can easily bypass it by simply changing the case of the string. They could also mix the case, so an example like pHaR:// might also work.
This then allows attackers to perform attacks where they can load a local PHAR file on the target system and use a deserialization attack to perform some malicious action. Assuming an app is already extracting the contents of the TAR files locally, an attacker would simply have to upload a TAR file containing a malicious PHAR file and have the app extract and save the PHAR file locally, after which they could upload a second TAR file containing a file named PHAR://*malicious PHAR file location* and the PHP app would attempt to access and extract the local PHAR file, thereby triggering the vulnerability.
Notice that the PHAR:// file handler does not allow for accessing remote files, which is why this procedure is required.
Research into deserialization gadgets for this exploit showed that most of the potential possibilities seem mostly restricted to file operations. The PoC showed that it would be possible to delete a file using this vulnerability but I was not able to determine any other useful actions that could be performed. Potential impact would depend both on the privileges of the user running PHP as well as what operations the app was doing; again remember the program will only be able to do file operations so most likely an attacker would have to package a malicious PHP file within the PHAR archive, have that be extracted somehow along with the malicious PHAR file, and then also have a file within the TAR archive that has a filename of PHAR://*path to malicious PHAR archive that was uploaded* to form a full end to end payload and get RCE.
Overall I’d say this is an interesting bug but its exploitability is somewhat limited and depends highly on the underlying application it is used within.
