So once in a while you hear about some backdoor which was slipped into some source code. Mostly in C applications…so I was thinking how would this be done in Java? Most of the times the backdoors you hear about are very nasty and difficult to track down “bugs” in the source code like buffer overflows, race conditions and the likes. Since Java doesn’t really have buffer overflows(I’m ignoring faulty VM implementations for the moment) I was wondering what an other *hopefully* good way would be to introduce bugs you can exploit?
So after waking up in the middle of the night(no kidding, it was 3.30 am) I remembered something from back in the day when I coded in Java. Most of the time when working with SSL and Java I got all frustrated because the companies we worked with where not capable of delivering a test environment which had a valid certificate…so it sucked. A invalid certificate meant, Java would reject the SSL connection and you’d be wondering why the application didn’t work. If I’m correct .NET has something like this to. Like all lazy programmers I used the following code to bypass that(courtesy of google, thanks to the original author though):
private TrustManager[] acceptAllCerts(){
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
return trustAllCerts;
}
Then just create your SSL socket, which uses the above function to accept all certificates.
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, acceptAllCerts(), new java.security.SecureRandom());
SSLSocketFactory factory = (SSLSocketFactory) sc.getSocketFactory();
sslSocket = (SSLSocket) factory.createSocket(iAddr,this.port);
So you are probably wondering why I’m classifying this as a possible backdoor? Well just imagine…some big application which relies upon SSL to be sure it has a secure connection. If you normally man in the middle it, with a self signed certificate it will complain, with the above code in place it will not complain about your mitm attack. So you can sniff all the sensitive information you want. Personally I think it’s best used in combination with a little bit of social engineering, for example add some comments to the code stating one of the following things:
- will be fixed by @author: DO NOT TOUCH
- only used until the acceptance phase has been completed
- hate working overtime? Don’t touch this code
- will be fixed in the next release
It actually works…I’ve seen code floating around with similar comments and nobody seems to care. Of course this will not always work and a programmer which actually does his job will notice this. Still if you get it to work ones it’s a real nice way to get data, without breaching the computer which runs the application and thus leaving less traces around.
DiabloHorn 