CPU-World Cross-site Scripting vulnerability
The silicon database GOAT
CPU-World maintains a large archive of historical CPU specifications, utilizing user submitted entries to catalogue many different CPUs from various manufacturers. One of the components of this service is the search feature which can be used to filter and narrow results based on some parameters that are sent to the backend which makes finding information about the mystery CPUs I have lying around WAY easy to find.
Their service is highly useful so I find myself referencing their data regularly throughout the year but one day during some research I noticed an unusual response from the search component and decided to investigate, this inevitably led to finding an XSS vulnerability in a Fast CGI component of their web application.
Here's the scoop!
Discovery
Normally performing a search will send a GET request to the /cgi-bin/ajax/parts.fcgi fast CGI component with a handful of URL parameters then return an HTML table of results.
Below is an example of a normal GET request to the vulnerable feature:
GET /cgi-bin/ajax/parts.fcgi?PART2=ryzen+5&ACTION=Go&CGI=OUTPUT%3DW%26PART%3DPART2%26ACTION%3DMATCHFP%26WANT%3DURL%26FIELD%3DPART2 HTTP/2
Host: www.cpu-world.com
Referer: https://www.cpu-world.com/CPUs/CPU.html
If we inspect the GET request and look at the URL parameters we can see that there are a handful of options that can be manually changed by the end-user that are not normally accessible.
Lets feed this uri into cyberchef (❤️ my beloved ❤️) with the 'Parse URI' recipe and give it a looksee:
Path name: /cgi-bin/ajax/parts.fcgi
Arguments:
PART2 = ryzen 5
ACTION = Go
CGI = OUTPUT=W&PART=PART2&ACTION=MATCHFP&WANT=URL&FIELD=PART2
Wow! Much easier to look at! There are only a few parameters, the most interesting being the CGI param. This parameter appears to be responsible for telling the backend CGI script how we want the data returned for the user. Something notable is what appears to be sub-parameters being passed via the CGI param. Maybe the contents of this gets passed to a backend script?
If we adjust the inline OUTPUT value to anything other than 'W' the server responds with what appears to be the HTML template for the results, interesting.
What is probably happening here is a lack of input sanitization on the CGI parameter. I'm assuming that when the GET request by the client is performed it will then perform another backend request, this second request coming from an internal server has less input validation/sanitzation so it slips past into the response data.
Vulnerability validation
Just for giggles we'll try to stick some arbitrary HTML and javascript in there aaaand whammo, we're convincing the server to serve our 'malicious code' as part of the response HTML:
I think this serves to demonstrate that the vulnerability indeed exists and can be exploited trivially.
With a little bit of effort an attacker can craft URLs that can then be sent to an unsuspecting user, upon being clicked the malicious code will execute in their browser. The scary part is that it's being served by a legitimate host so an unsuspecting user will be none the wiser, unless they inspect every link very closely (and understand XSS flaws).
Here is an example of the crafted URL that opened a javascript alert box:
GET /cgi-bin/ajax/parts.fcgi?PART2=ryzen+5&ACTION=Go&CGI=OUTPUT%3DF%26PART%3DPART2%26ACTION%3DMATCHFP%26WANT%3DURL%26FIELD%3DPART2%3Cscript%3Ealert(%27hello%27)%3C/script%3E HTTP/2
Host: www.cpu-world.com
Path name: /cgi-bin/ajax/parts.fcgi
Arguments:
PART2 = ryzen 5
ACTION = Go
CGI = OUTPUT=F&PART=PART2&ACTION=MATCHFP&WANT=URL&FIELD=PART2<script>alert('hello')</script>
Overall this is a decently risky vulnerability to have available to attackers. It is highly recommended that web applications sanitize any input that is exposed to the end-user whether it be URL parameters or header data, even if the input values are not directly visible through the application view!
As we can see, when a user has access to modify these parameters we can send arbitrary data to the server and if we're (un)lucky the server will process this data, manipulate the output of the response, and send it back to the user tampered.
Given that cpu-world does not appear to handle a lot of sensitive data the risk may be lower however this can still be a vector for malware and other shady activities and it would definitely be a reputation risk if anyone was able to utilize this for evil. For example, an attacker could craft a link that steals a user's login details, or deliver a malicious download, all appearing to come from cpu-world. Yikes!
References
Portswigger Cross-site-scripting
OWASP Cross-site-scripting
Disclosure timeline
2022-12-26. cpu-world was contacted to disclose this vulnerability, no response received
2022-12-30. contacted again to follow-up, no response received. I attempted to validate whether or not the vulnerability was fixed and my source address had been blocked
2023-02-20. re-visited cpu-world website, no longer blocked. Attempted to validate the vulnerability again and it appears to have been fixed! Woo!