How to profile an RMI service from 0-day knowledge
By Adam Boulton, October 15th, 2008.
On 25 September 2008, at OWASP NYC, I performed a live demonstration of how to profile an RMI service from 0-day knowledge. My presentation was eagerly awaited by the 600 members that attended this year’s conference. Let me explain why.
Most security professionals are aware that the software security scene has been hotting up over the years and that applications are secured from the ground up. That said, imagine building your services off an insecure architecture which can potentially expose your business logic to attackers? Not a great start to your product!
As a developer, this is a situation many of you may be faced with time and time again when developing RMI services. This is mostly due to implementation flaws which reside on the server, within the skeleton layer of the RMI service. In order for a client to communicate with a RMI service, a stub must be distributed to the clients. The stub will have been generated by the developers of the RMI service.
Until my presentation, there was a misconception that unless the developers made the stub available it would not be possible to communicate to the service. Unfortunately, I managed to highlight that due to the implementation flaws within the skeleton layer which are generated by Sun Microsystem’s tools, shipped with the JDK, it is possible for an attacker to profile the service and therefore construct a custom stub and client. Let me explain how I did it.
During my presentation I used a customised suite of tools, currently known as RMI Spii. The tool which I developed over a few weeks within Corsaire’s labs determines any objects bound to the server and establishes the method prototypes. I then began to dynamically invoke the hosted functionality. I wanted to highlight that the importance of RMI Spii was to remove the misconception of security through obscurity - a trap many developers fall into when developing RMI services. I also warned that developers need to be vigilant when developing these types of services and to be aware of the risks i.e., how easy an attacker can profile a service and begin to design their customised client. Furthermore that it is important to consider that an attacker can invoke functionality in any order they desire, which may break the authentication and authorisation model.
