Goal

Our third video write-up covers abuse of cloud services. By signing up for free accounts, it is possible to gain access to small amounts of free resources, specifically processing time and bandwidth. However these resources are tightly controlled to maintain fairness across the many thousands of users who share the same platform.

We aim to circumvent some of these controls in order to access more resources than should be allowed, and we demonstrate this on the Force.com platform which supports the ability for a developer to upload and execute custom code. Our proof-of-concept was to port Nikto into a Force.com application, and we named it Sifto.

Background

SalesForce’s primary offering is a web-based CRM solution which they manage, and they also provide developers with the ability to write custom applications that run on the Force.com platform. They are a major player in the cloud universe with almost 60 000 customers, revenue over $1 billion and are a member of the S&P 500 index.

In order to write applications on Force.com, a developer account is required (this is freely available). Applications are coded in the Apex language, a Java-like language for business logic, and is proprietary to the Force.com platform. This platform supports datastore operations through built-in language constructs and the API enables a developer to make HTTP callouts, tie Apex code to WS endpoints within Force.com, send emails as well as tie Apex code to an email endpoint within Force.com. The datastore is useful for maintaining state between multiple iterations of the event loop (described shortly) as well as providing a way to send emails for free via update triggers (emails sent from within Apex count against the daily limit).

With all this in mind, we focused on creating event loops the were initiated by a single user action, to show how significant free computing resources were available if one is prepared to put in the legwork of learning new languages and platforms.

Video 1

1. The first part of the video runs through the setup required within the Force.com account to create the Sifto application. This included the custom Apex, custom objects, datastore trigger that sent an email, email endpoint that received the trigger and invoked our Apex and showed that the target was not added to the “Allowed endpoints”. (The last point might require more explanation: while Apex code can make HTTP requests, the platform only permits HTTP requests to previously allowed sites. An administrator can allow a given site by navigating the Force.com administration interface and adding it, but this requires a manual process for each new Sifto target so we needed to automate this process.)
2. Part two of the video runs through the initialisation of a Sifto scan against a new target. The attacker shows us his wrapper script for kicking off the scan; all it does it send a specially formatted email to a specific Force.com address. Meanwhile, we tail the victim’s httpd access_log to show the scan as it comes through. Incidentally, the ‘tail’ in the video was not sped up and shows the actual speed at which results came through. What’s also noticeable is that as results are found, they’re returned via email to the attacker.
3. In part three we simply show that the target site was automatically added as an allowed endpoint within Force.com. We achieved this by auto-browsing the Force.com site from within Apex code, a surprisingly kludgey bit of code, but nicely demonstrates that all configurations options are available from within Apex, and so Apex can modify the environment within which it operates.
4. Part four depicts the scanning as it continues.
5. Part five reveals the results of the scan as they slowly arrive via email.
6. The scan ends in part six.
7. Finally, part 7 shows the overall results of the scan listed in a single email, and importantly shows how the entire scan of almost 3000 tests ran in about 11 minutes.

Video 2

The event loop method shown in video 1 was still subject to unpublished limits, and so instead of scaling by extending the number of iterations of the event loop, we decided to try and scale by registering many accounts. This was useful since accounts had zero cost. All that remained was to automate the registration process (see the slides for more details on this), and we accomplished this as shown in video 2, where a shell script automatically registered a bunch of accounts. The trick that allowed us to bypass the CAPTCHA in the registration page was a bug in the CAPTCHA script that also provided the image’s text in ASCII-text (look for the lines “captcha captured:” in the video).

Of minor interest was that each account was registered in a different country. Since SalesForce assign accounts to instances (or geographically dispersed clusters) according to the customer’s claimed location, we were able to register accounts on both the NA6 and AP1 instance, or North America and Asia Pacific respectively.

Conclusion

Cloud computing provides us with a tantalizing taste of vastly expanded resources and the plethora of services means that free or trial accounts abound. It’s possible to stitch together the free resources to to produce a useable computing platform that can take advantage of the expanded resources without incurring cost to the attacker; the downside is that this is platform-specific and may require the learning of new technologies.