Security Information Week 32, 2003
![]() |
Introduction
During the latest years there has been an increased focus on security holes in popular applications. Software vendors have been heavily criticized for lack of focus on security in their applications.
We have seen several examples of malicious programs using application vulnerabilities to propagate more efficiently. One may wonder if this has as an outcome that authors of malicious programs use security flaws as an additional tool for their programs to spread in almost each and every situation.
This Security Information will examine such a hypothesis.
Selecting data for examining
Several data sources might be used to investigate. The ambition in this context, however, is not to make a scientifically sound proofing of the hypothesis, but to examine whether the correctness of the hypothesis seems obvious.
We will therefore use the most new widespread programs as our data source.
During 2003 Norman has issued alerts against malicious programs several times. Let us use these to see how they agree with the hypothesis above.
- 9 January 2003:
- W32/Lirva.A Exploits the security hole from 2001 "Incorrect MIME Header Can Cause IE to Execute E-mail Attachment". Information and patch available from: http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/security/bulletin/MS01-020.asp - W32/Lirva.C Exploits the security hole from 2001 "Incorrect MIME Header Can Cause IE to Execute E-mail Attachment". Information and patch available from: http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/security/bulletin/MS01-020.asp
- W32/Lirva.A Exploits the security hole from 2001 "Incorrect MIME Header Can Cause IE to Execute E-mail Attachment". Information and patch available from: http://www.microsoft.com/technet/treeview/default.asp?
- 11 January 2003: W32/Sobig.A Does not utilize any known exploits.
- 24 February 2003: W32/Lovgate.B Does not utilize any known exploits.
- 26 March 2003: W32/Lovgate.F Does not utilize any known exploits.
- 12 May 2003: W32/Fizzer.A Does not utilize any known exploits.
- 19 May 2003: W32/ Palyh.A Does not utilize any known exploits.
- 1 June 2003: W32/Sobig.C Does not utilize any known exploits.
- 5 June 2003: W32/Bugbear.B Exploits the security hole from 2001 "Incorrect MIME Header Can Cause IE to Execute E-mail Attachment". Information and patch available from: http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/security/bulletin/MS01-020.asp - 26 June 2003: W32/Sobig.E Does not utilize any known exploits.
- 2 August 2003: W32/Mimail.A Exploits a security hole in Outlook Express. A patch has been available since April 2003 - see the following Bulletin from Microsoft: http://support.microsoft.com/default.aspx?scid=kb;en-us;330994
Reviewing the results
Perhaps surprisingly, we find that of the total eleven alerts, (only?) four of those used any known application vulnerability to spread, nor in any other way.
There may be several reasons why so (relatively) few malicious programs from our data source used program exploits. One of these reasons is probably that some of the exploits are detected generically by antivirus programs, thus stopping new, unknown malicious software. Another is that some organizations may implement techniques on their perimeters, stopping malware that is using particular techniques.
One may therefore be tempted to speculate that malware using well-known, older, exploits are not getting any assistance from this in its propagation, while new exploits may.
Another issue that is obviously relevant, is how widespread the malicious programs are over how long time frame. Further analysis of our data above is needed to be able to see if the use of application vulnerabilities has any effect on this compared to techniques that do not use such exploits. Norman's Security Information for week 34/2002 discusses characteristics about malicious programs that were successfull both in infecting lots of computers, and were persistant over a long period of time.
Conclusion
Based on the non-scientific test above, we are not able to say that our hypothesis in the introduction is valid.
However, this may well change at a later point in time, and Norman will monitor this situation.
Per Olav Førland
