Lack of Input Validation on User Certificates
Target: Private key and certificate embedded in the Android client’s OpenVPN configuration.
Description: The Android client downloads the certificate from /1/cert, splits it into the private key and certificate and adds them directly to the OpenVPN configuration. There are no checks done to ensure that the certificate and key are properly formed or do not contain other OpenVPN configuration options. If the provider is malicious this will give them the ability to execute arbitrary commands on the user’s Android device using OpenVPN’s up, down or other script execution commands. These commands are normally explicitly ignored by the client’s configuration parser. An example of a user certificate that executes arbitrary commands on the user’s Android device may be found in Appendix B on page . The type of newline is important after the dashes due to how the certificates are separated.
Exploit Scenario: An attacker sets up a provider and advertises to get a large client base. The attacker then modifies their API to embed an OpenVPN route-‐up command into the user certificate if the user is an Android client. The attacker can now use LEAP’s permissions to execute a script that intercepts all of the user’s Internet traffic.
Short Term Solution: The key and certificate should only contain a very limited character set due to its base encoding. Create a whitelist of these characters and reject any key/certificate download that has characters outside the whitelist.
Long Term Solution: Create a very strict whitelist of what OpenVPN options and what option arguments providers are allowed to specify. Each option and argument should have a strict whitelist of values they are allowed to contain (ex. OpenVPN options should not contain new lines). Any configuration that does not match these rules should be rejected and the user alerted.
(from redmine: created on 2013-07-30, closed on 2013-08-13)