## 6 Lessons Learned
### Limitations of Code Signing  
Code signing is extensively used today to authenticate the identity of the producer of a software and the integrity of the code. A common assumption is that signed code can be trusted. As a consequence, \begin{table}
\begin{tabular}{l l} \hline \hline
**Tool with hook detection capabilities** & **Results on Duqu** \\ \hline CMC CodeWalker (2008) & 16 hooks in lss.exe (BSoD during test) \\  & inline hooks in lss.exe (PID: 1176, 1236, 1930, 2016) \\  & inline hooks in svhost.exe (PID: 996, 1084) \\  & inline hooks in svhost.exe (PID: 1084) \\  & NoVirusThanks Anti-Rootkit v1.2 \\  & - (detects only unrelated Message hooks in csrss.exe) \\  & McAfee Rootkit Detective 1.0 \\  & RKDetector v2.0 IAT API Hooks Analyser \\  & & IAT hook in explorer.exe \\  & & inline hooks in svhost.exe (PID: 996) \\  & & IAT hook in explorer.exe \\  & inline and IAT hooks in lsss.exe (PID: 1236, 1176, 1048, 1416) \\  & Sysinternals RootkitReveler & - \\  & TrendMicro Rootkit Buster v5.0 2011 \\  & Usec Radix v1.0.0.13 \\  & & IAT hook in explorer.exe \\  & inline and IAT hooks in svhost.exe (PID: 1084, 996) \\  & & IAT hook in explorer.exe \\  & inline and IAT hooks in lsss.exe (PID:1176, 1920, 2016, 1236 ) \\  & (IAT hooks in every process use the hooked function) \\ \hline
**Tool with hook detection capabilities** & **Results on Flame** \\ \hline CMC CodeWalker (2008) & - (BSoD during test) \\  & minle hook explorer.exe \\  & NoVirusThanks Anti-Rootkit v1.2 \\  & McAfee Rootkit Detective 1.0 (2005-2007) \\  & RKDetector v2.0 IAT API Hooks Analyser \\  & Rootkit Unhooker LE v3.7.300.509 \\  & Sysinternals RootkitReveler \\  & TrendMicro Rootkit Buster v5.0 2011 \\  & Usec Radix v1.0.0.13 \\  & & IAT hook in explorer.exe \\  & inline and IAT hooks in explorer.exe \\  & & (IAT hooks in every process use the hooked function) \\ \hline \hline \end{tabular}
\end{table} 
Table 9: Usermode hook detection by free anti-rootkit tools. many automated verification tools do not even check signed files, or they rely on the validity of signatures to filter false alarms. However, a valid digital signature does not necessarily mean that the code is trustworthy. Technically, the validity of the signature only tells the verifier that the code has been signed by someone who possesses the private key, which does not exclude the possibility that the key is compromised (as in case of Stuxnet and Duqu) or that the certificate vouching for the authenticity of the key is illegitimate (as in case of Flame). In addition, a valid signature does not tell anything about the trustworthiness of the signer, even if the key is intact and the certificate is legitimate. Generating fake certificates is not an easy process. CAs usually follow strict policies and use various security measures to protect their services. In the case of Flame, the attackers were able to generate a fake certificate, because the CA used a weak cryptographic component, namely the MD5 hash function. However, if sufficiently strong cryptography is used, then such an attack becomes practically infeasible for the attackers. Thus, with reasonable effort, certificate forging can be made too expensive for the attackers, and less of an issue to worry about. We believe that the management of code signing keys by software manufacturers is a much weaker point in the system. Code signing keys are often stored on developer machines that are connected to the Internet, either without any protection or protected with a password that is in turn stored in a batch file for convenience. While CAs have strict authentication policies when evaluating a certificate request, we are not aware of any periodic audits after the issuing of the certificate aiming at the verification of how the private keys are handled and used by the certificate owner. Similarly, we have not heard about any case when the certificate of a software maker was revoked due to its negligence in the key management and code signing procedures.