Rocket.Chat will open links to the same domain within the main application window, with the abilitry to upload files an attacker can run Javascript and gain RCE (thanks to nodeIntegration being enabled).

Rocket.Chat will add a _blank target to all links by default, but when the link is to the same domain as the rocket chat application, this is not used. It is also possible for a user to upload arbitrary files, these files are uploaded to S3, and a link is generated that is on the same domain that will redirect to the S3 location. By chaining these two issues an attacker can upload an arbitrary HTML file, have a same-domain link generated for it which will result in the link, once clicked being navigated to and javascript executed inside the electron browser. Since nodeIntegration in enabled, Javascript execution results in easy command execution on the client’s machine.

tl;dr There are two key issues with Flickr’s use of AWS Cognito for their authentication, first, is that only the sub attribute is guaranteed to be unique and should be used to identify users, second is that the access_token provided can be used to modify user attributes. These issues can be chained to modify the email attribute (which is the attribute Flickr is using to identify accounts) and have one Cognito account map to another user’s Flickr account.

Not all SSRF vulnerabilities are equal, a common mitigation is to limit the locations that can be accessed; in the case of WebSphere Portal, this is exactly what was found, yet it could still be exploited.

In the Portal server they found a proxy endpoint that would proxy requests to Portal to a set of whitelisted domains:

• http://www.ibm.com/
• http://www-03.ibm.com/
• http://www.redbooks.ibm.com/

As the configuration also allowed following redirects, the author was able to chain this with an Open redirect in Lotus Domino running on redbooks.ibm.com to redirect to an arbitrary location.

There is not much said about exploiting this issue, though if running within a cloud envrionment, the metadata server is a good target. They also looked at targeting the Admin control for WebSphere which runs on the local machine, but shouldn’t be exposed to the internet. Unfortunately they did not manage to find an attack path, but local resources are another good target to escalate an SSRF.

Polygon places the blame for this bug on not checking that the from address in a transfer actually has the balance to cover the transfer in the first-place. While I don’t doubt that as a core issue it feels like that may only be part of the issue, the other part being a lack of error checking, or perhaps improper error handling.

Getting into the actual issue, the root issue is that the it is never checked if from is able to fulfil the transfer. Beyond that it seems that error handling might also be an issue, in that transferWithSig does not check if ecrecovery returned an appropiate address, as it returns address(0x0) on error conditions. It also seems noteworthy that ecrecovery itself only raises an error its call to ecrecover fails and returns 0x0. I’m not too familiar with dapp development so I’m not sure if this is expected but it seems that it should be raising an error in all error situations rather than just returning a special value.

So, as exrecovery returns address(0x0) without any other error indicator when the length of the hash is not 65 is can very easily be triggered. transferWithSig will use this address as the from address, resulting in a transfer from the “genesis contract” of any amount.

Patch: This was resolved by switching to a fork and entirely disabling the transferWithSig function.