Moderate
CVE-2020-28948
Add Reference
Description
URL
Type
CVE-2020-28948
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Description
Archive_Tar through 1.4.10 allows an unserialization attack because phar: is blocked but PHAR: is not blocked.
Add Assessment
Ratings
-
Attacker ValueMedium
-
ExploitabilityHigh
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.
CVSS V3 Severity and Metrics
General Information
References
Advisory
Miscellaneous
Additional Info
Technical Analysis
Report as Exploited in the Wild
What do we mean by "exploited in the wild"?
By selecting this, you are verifying to the AttackerKB community that either you, or a reputable source (example: a security vendor or researcher), has observed an active attempt by attackers, or IOCs related, to exploit this vulnerability outside of a research environment.
A vulnerability should also be considered "exploited in the wild" if there is a publicly available PoC or exploit (example: in an exploitation framework like Metasploit).