Security Assessments of Java RMI Services
By Adam Boulton, October 15, 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.
