Discourse SNS project is used for mailing list, discussion forums and chat rooms. They have a very nice
Security Guide as well, if you are looking for something to look at.
While staring at the code in this project, they saw an interesting piece of code open(subscribe_url). The open function in Ruby can be injected into for OS command injection.
The problem is that this code has a ton of verification, including having a proper AWS PEM file from SNS. It must be within the SNS service and has an extension sending with a .pem extension. Since we do not control the PEM file going in from SNS, this causes us issues.
The code itself is intended to send push notifications to registered endpoints. The code snippet is for grabbing the .pem file. Could this verification by bypassed?
The regex verification allows all SNS services to be used, which allows for any SNS operation to be used. The first option was crafting a X509 certificate error by sending a strange looking URL. But, we need a 200 response for this to work, darn.
The SNS operation GetEndpointAttributes has a field called CustomUserData. By using this endpoint, it was possible to create a valid X509 certificate that would be returned from the API.
With this out of the way, the SubscribeURL on the message being sent with the certificate could be used for command injection. At this point, we could pop a shell on the Discourse instance, even though we clearly should not be able to!
Overall, great writeup on how to read the docs and source code in order to find impactful exploits. Using cloud services to build your service is a complicated affair, which really reminds me of a
HashiCorp Vault vulnerability.