A few months ago reports appeared claiming that security researchers have warned WhatsApp users against a serious vulnerability which is allowing cybercriminals to cause a group chat to crash using a destructive app-killing message and delete their entire group chat history forever.
Recently, a researcher who once noticed a security flaw in 2017 that Check Point published a few months later, decided to conduct a search operation focusing popular messaging platform, WhatsApp, as he had some clue of existing security flaws in WhatsApp mobile and web application.
The researcher found and helped parent company Facebook to patch multiple critical security flaws in the messaging application, all the way from Open-Redirect through a Persistent-XSS and CSP-bypass to a full cross-platform Read From The Local File System on both Windows and Mac.
The security issues
In a blog post, the security researcher, Gal Weizman said he thought that by using WhatsApp web he will be able to find the line of code where the object containing "The metadata of the message is being formed, tamper with it, and then let the app continue in its natural message-sending flow, thus crafting my message while bypassing the UI filtering mechanism."
During the research, he found that WhatsApp texts with rich preview banners are messages that include banners with added information regarding a link that is in the body of the message. So for example, while sending a message with "https://facebook.com" as its body, the receiver will get this:
It should be mentioned that as per the researcher anybody can tamper with the banner properties before sending it to the receiver. So Weizman created a message that will include a legitimate-looking banner but will redirect to another domain (https://example.com!) instead of by simply replacing the link and as a result, he got the image below:
The researcher stated that "Being familiar with all sorts of tricks used by malicious actors in the world of web, I experimented with this idea to see if this open redirect can be made more dangerous. I managed to not only mess with the banner's link but also crafted a message with a link that looks like it belongs to https://facebook.com while the link will always redirect to https://example.com!"
The researcher claimed that such activities are dangerous because it appears authentic since both the banner and the link look like they belong to https://facebook.com.
The role of '@'
Weizman says that the purpose of "@" in URLs is to pass username and password to visited domains in the following way: https://USERNAME:PASSWORD@DOMAIN.COM. If a threat actor wants he can abuse this with anything else such as https://DOMAIN-A.COM@DOMAIN-B.com and still it will work. However, it should be noted that as per the researcher Firefox is the only browser that warns users, by default, in case this method is used without providing a username and password.
After a few failed attempts when Weizman thought that whether he can tamper with the message and send any link he thought that maybe the failure occurs because "WhatsApp looks at the link that is attached to the banner and expects it to include a legitimate https: scheme URI?" and changed his technique as well as gained a one-click Persistent-XSS.
He mentioned that for WhatsApp, Chromium-based browsers added a defence mechanism against javascript: URIs just when I found this vulnerability and unfortunately for this Facebook acquired messaging platform, on other browsers such as Safari and Edge, this vulnerability was still wide open.
"I couldn't achieve a state in which the payload is not a visible part of the message. This is because WhatsApp has a part in their code that checks whether the content of the link URI is included in the body of the message when the messages are being loaded. If there is no match, WhatsApp will omit the banner and the exploit won't work," said the researcher.
In this case, the best option will be creating a long message so that Read More option will turn on. To check the vulnerability, the researcher also made sure that the actual payload would be at the very bottom of the body of the message where you could only see it if you click Read more.
Bypassing WhatsApp's CSP rules
Google's CSP Evaluator has made this process easier as said by Weizman while adding that "You just throw the URL address of the target website into the text box, and it immediately tells you it's CSP configuration and how safe (or unsafe) the website is."
He then by using the javascript injected the following payload to a malicious message:
"I simply use the XSS to load the iframe and then listen to the messages that are posted by different windows. I then use the iframe to post a message to the top window with the content of the external code. The top window, where the XSS was executed, receives the message from the iframe, parses the external payload provided by it and executes it in its context (web.whatsapp.com)," said Weizman, who then successfully fetched and executed the external payload in the context of WhatsApp.
Persistent-XSS to Reading from the File System on Mac or Windows
When he clicked the same malicious message which he used on the web app through the message, he was surprised to see that the document domain part didn't really work - but the alert() part sure did.
When Weizman decided to use XSS to alert the userAgent of the currently running application, and the following major security flaw it was unbelievable. He added that "Chrome/69 - the latest version of the WhatsApp desktop applications provided by WhatsApp is Chrome/69 based. This vulnerability was found when Chrome/78 was the stable version! A few versions before Chrome/78, the ability to use the javascript: trick was patched, and if WhatsApp would have updated their Electron web application from 4.1.4 to the latest which was 7.x.x at the time this vulnerability was found(!) - this XSS would never have existed!"
