Malware teaching considered harmful?

2008-09-01

Richard Ford

Florida Institute of Technology, USA

William H. Allen

Florida Institute of Technology, USA
Editor: Helen Martin

Abstract

Richard Ford and William Allen, both teachers of malware courses at Florida Institute of Technology, present their views on the teaching of virus writing as part of security courses.


A short article in the 11 August 2008 issue of Newsweek magazine highlighted a ‘virus-writing’ class taught by Professor George Ledin at Sonoma State University in California [1]. Since then, there have been several discussions of the class online, and it has become, albeit briefly, something of a talking point in the industry. Although Ledin’s stated goal is to ‘…teach students to think like hackers so they can devise antidotes’, there is also a clear subtext in his presentation – AV vendors are not doing enough to deal with the spread of malware and are, in his opinion, obstructing independent research in anti-virus defence.

Reaction to the Newsweek article has been strong, with many negative comments made about the AV industry by users and IT professionals alike. Clearly, there is a public perception that industry-led anti-virus research is insufficient and that vendors do not support alternatives. Here, we will take a brief look at the history of teaching malware and whether such courses are valuable, as well as describe our own approach to teaching the subject to undergraduate and graduate students.

Everything old is new again!

Perhaps the most important point to note is that Ledin’s malware class is hardly the first of its kind. For example, in 2003, Dr John Aycock put himself firmly in the industry’s cross hairs with his own ‘virus-writing’ class at the University of Calgary. At the time, there was significant discussion in the industry questioning the efficacy of the class and the thinking behind it, and even a public letter ‘concerning the writing of viruses and how it does not teach about virus prevention’ signed by more than 160 industry members [2]. Since then, many of Virus Bulletin’s readers have had the opportunity to meet Dr Aycock at Virus Bulletin conferences, and discovered him to be a reasonable man doing what he considers the right thing. Furthermore, leaving aside issues regarding perception and the legitimization of virus writing, there appears to have been no immediate damage caused by his classes or by any of his students.

Dr Aycock’s class was not the first example of controversy regarding the best way to teach malware concepts. Ludwig’s Little Black Book of Computer Viruses, the writings of the soon-disbanded ARCV, and Burger’s publication of viral source code also all predate Ledin’s class, and all raised very similar issues. As such, it is important to recognize that this argument has gone on for as long as viruses have been studied. Nevertheless, the topic merits re-examination given today’s complex threat environment and the sometimes vocal support of these types of classes by anti-virus industry ‘outsiders’.

Arguments for a teaching approach that requires students to create malware generally boil down to the assertion that this activity is an important part of the educational process – that is, that this knowledge is crucial to being able to understand malware and defend against it. To address this, educators should ask three questions in turn: ‘Is it effective?’, ‘Is it ethical?’, and ‘If it is ethically questionable, are there other effective ways of teaching the subject?’. In this article, we will explore these questions based on our own first-hand experience of teaching a course on malicious mobile code at the Florida Institute of Technology.

Is it effective?

It may seem strange to begin by essentially making the case for classes that require students to write malcode of various types, yet the educational value has been the mainstay of almost every argument in support of this approach (see, for example, Ledin’s arguments in [3]). Furthermore, if the technique has no educational value, there is little point in taking the approach and provoking the arguments that ensue.

In terms of skill set, it is difficult to argue that virus writing is the only way to understand viruses. In our own course, no malware writing is involved (indeed, each student is asked to sign an ethics statement at the beginning of the semester that forbids it) and yet graduating students have a solid grasp of the fundamentals of malware analysis and defence. Stealth and hooking, for example, can easily be taught without creating something that is inherently harmful.

Researchers are often confronted with flawed analogies that show that one needs to be able to write viruses in order to prevent them. These arguments are beguiling at first, but rapidly fall apart. The statement ‘To be able to prevent Action X one needs to have engaged in Action X…’ is nonsense. Similarly, to defend against viruses and other malware, one does not need to have written them. One needs to understand them. The former does not require the latter. Writing a virus may assist by showing just how simple it is, but other than that, it teaches very little.

The second argument, however, is much more complex: students learn better in this context. Here, effective data is lacking with respect to computer security, but is bountiful in general (see, for example [4], [5]). To the best of our knowledge, there have been no real studies that even attempt to measure the effectiveness of teaching with respect to malware. As such, it is left to the individual teacher to assess the utility of his or her teaching technique. Clearly students learn better when their interest is piqued, and the sense of being given some new and restricted knowledge can be powerful.

This may come as a surprise to those not involved in teaching at the university level, but capturing the students’ attention is actually one of the key skills required by a truly effective teacher. While it would be nice to live in a world where students come to class motivated and prepared to learn, the reality is that it can require significant effort to engage a class full of students. This is made worse by the modular American university education approach, which seems to encourage compartmentalization of knowledge. Classes are frequently seen as individual units to be completed in isolation, as opposed to a more integrative world view. To the extent that virus writing excites the student, there is a fairly strong argument that knowledge will be acquired and retained more easily.

Thus, in our opinion and without yet addressing the ethical issues, there is likely to be some educational benefit to classes that feature the creation of live malware. Given this, we turn our attention to the question of possible ethical challenges with this approach.

Is it ethical?

The problem of ethics is that one’s interpretation of ‘unethical’ depends greatly on the particular ethical model one follows. In order to avoid going off on tangents, for the remainder of this article we will acknowledge these cultural issues, but focus on the western educational system.

The primary ethical challenges with ‘virus-writing’ courses are that they:

  • Pose an unnecessary risk to the health of other computers.

  • Directly promote the writing of viruses by legitimizing virus writing and experimentation.

In each case, there are some reasons for concern. The most obvious objection – the inadvertent contamination of computers – is clearly a valid risk. While the risk can be reduced by strict isolation, it is impossible to eliminate it entirely. Furthermore, students may be tempted to experiment, armed with their new knowledge. Even though there may be absolutely no malicious intent, unintentional spread is clearly possible.

Similarly, many researchers have vocally objected to the idea that such efforts legitimize the work of virus writers. Once again, there is clearly an element of truth in this – the idea is that somehow an attacker is cleverly exposing a weakness in current signature-based solutions. Thus, one can argue, the virus writers are casting an unwelcome spotlight into the supposed inner workings of the industry, and are showing the truth to the masses.

As this is an argument that every serious virus researcher has heard, the danger clearly rings true. However, the facts really don’t support the position: scientists are wholly aware of the limitations of signature-based products. No new malware is required to illustrate this. However, by buying into the idea, we risk once again elevating the status of the malware author from pest (or criminal) to folk hero. Developing malcode that highlights well-known weaknesses in defence is not useful.

Finally, there is a concern that the act of virus writing makes subsequent virus/malware creation easier. Once a student has written viruses in the lab, they may be tempted to go on and become involved in virus writing. This complaint is, of course, equally applicable to classes that teach the underlying skills used by malware writers (which, frankly, should be possessed by any strong low-level programmer). As such, it is probably the weakest of the arguments against such classes.

As there is considerable debate regarding these classes, it is prudent to see whether such controversy can be sidestepped. Are there suitable alternative approaches?

A more excellent way

At Florida Tech., we have several years’ experience of teaching classes related to Internet security and malicious code. At no time during these classes have we asked students to write malcode – indeed, students are required to agree before the class not to use any of the skills they learn to do so.

The outline of the Florida Tech. course (taught at the undergraduate and graduate level) is fairly straightforward. Technical content is provided primarily by Péter Ször’s (excellent) book, The Art of Computer Virus Research and Defense, and additional content on ethics, epidemiology, metrics and policy provided by the instructor. To date, the course has worked extremely well, with good learning outcomes (as measured by student examination performance) and no reported malware incidents.

Structurally, the course requires prior knowledge of assembly language. This is necessary, as it is vital to understanding some of the underlying properties of malware (such as how stealth actually works). A working knowledge of C/C++ and debugging is also required. Armed with this knowledge, the course first discusses legislation related to computer viruses, the university’s acceptable use policy, and the ethics of malware research and defence.

From here, a historical overview of malcode is given, before following many of the topics in Ször’s book. Finally, the course uses this knowledge as a foundation for exploring prevention techniques, at both the local and group level.

The primary challenge with this course is finding the appropriate way to engage students and synthesize knowledge without having to accept the risk of working with live malware. Overall, our approach has been a heavy emphasis on hands-on experimentation using benign programs that illustrate some of the issues typically encountered when studying malicious code. For example, it is sufficient to build a user-mode hook into the operating system to illustrate the potential for stealth – there is no need to build a virus. Similarly, we have found that simulation has provided our students with excellent insight into the techniques used to spread malware and the effectiveness of various defences.

There is certainly a good argument that our approach is more difficult than those which require the writing of attack code. However, our experience is that the primary challenge is not covering the material but presenting it in such a way that it is engaging and applicable.

Perception is reality?

In summary, at least based on our own experiences in education, we believe that the challenges associated with laboratory creation of malware outweigh the possible educational benefits. However, overall it seems that these classes have had little impact, and while they may raise the blood pressure of some researchers, they are outside the scope of control. Loud complaints raise the profile of such classes, over and above their contribution to science.

Before closing, there are two side issues that bear acknowledgement. In each case, the primary issue is perception, and it is in these areas that we, as a group, are failing.

First, courses that ‘teach’ virus writing almost always generate significant publicity; in contrast, our quiet course has received almost no press – it is simply not newsworthy. Reading the comments on the Newsweek piece one gets a deep sense from the public that this sort of educational endeavour is perceived to be hugely beneficial to the student – that it will revolutionize security. In a university environment, as in business, publicity is very valuable, and the buzz surrounding this course will encourage others to follow the same path, even if the educational benefits are de minimis. The idea that one must know how to write viruses in order to stop them is only partly true. There is a difference between having the technical knowledge and actually exercising it. As researchers, we have clear ideas about what is possible, and this is sufficient.

Second, online discussion regarding this latest course has revealed a deep dissatisfaction with anti-malware companies. Only a fool would refuse to acknowledge that the anti-malware industry is not universally seen as the protector of computers; instead it is regarded almost as a parasite, using out-dated technologies to provide second-rate protection. Such an image is not attractive, but it is certainly reflected in the comments of many users. Spending time on a global image makeover might be a more productive use of time for members of the AV industry than fuelling the publicity behind courses that are simply a storm in a teacup.

Bibliography

[1] Kushner, A.B. This bug man is a pest. http://www.newsweek.com/id/150465.

[2] Public letter concerning the writing of viruses & how it does not teach about virus prevention. http://www.avien.org/publicletter.htm.

[3] Ledin, G. Not teaching viruses and worms is harmful. Communications of the ACM, vol. 48, no. 1, p.144, ISSN 0001-0782, 2005.

[4] Clark, R.C.; Mayer, R.E. e-Learning and the Science of Instruction. Jossey-Bass/Pfeiffer, San Francisco, CA, 2003.

[5] Gagne, E.D.; Yekovich, C.W.; Yekovich, F.R. The Cognitive Psychology of School Learning. HarperCollins, New York, 1994.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.