With the high-profile status that security has these days, you must have heard about the buzz words Malware, Virus, Trojans, Worms, RootKits, and Source-Code Poisoning.
If you think (as a programmer not directly involved with security) that these topics are interesting but don’t affect you personally, you are very wrong. You should be aware of these attack methodologies and know how to identify them.
To explain how these malicious pieces of code operate, I will work around an analogy that uses something very dear to you: your workstation (i.e. the computer you use to program and add code to the main source code repository).
Before getting into the details of how you can be attacked, I just want to explain about why you would be attacked.
As a programmer working for Company X, you are a rare case:
- You have READ access to big sections of your current project’s source code (probably the entire Company X’s source code archive)
- You have WRITE access to specific modules of your current project’s source code (if not the entire project’s source code and Company X’s entire source code archive)
- You log in into your computer using an account with administrative privileges (which means that anything that you execute has full control over your computer)
- You are a trusted person inside your organization and most colleagues implicitly trust you
- Your e-mail contains security-sensitive and confidential information
- Your level of security awareness and security knowledge is very low (unless you have been involved in security projects in the past or taken an active interest in learning and understating security threats)
- You will have very good computers (that are able to execute malicious programs without any noticeable performance degrading)
Due to this unique position of power and internal trustworthiness, from a malicious attacker point of view, your computer is a very ‘tasty’ capture. And although a direct specific attack is rare (i.e. the malicious attacker was explicitly targeting you or your company), a random compromise where you happened to be in a Virus or Worm path, is much more realistic, and potentially as dangerous.
What Would Be the Objective?
What could the malicious user do when control over your system is achieved?
- Insert malicious code in your Project’s source code that will be distributed to all your clients
- Steal your Project’s source code
- Destroy the Project’s source code
- Tamper with the Project’s source code whereby you lose trust in it and have to revert to old code (can you remember what you did last month?)
- Use your computer to launch attacks on other ‘juicy’ internal resources (such as the financial or HR servers)
- Use your computer to launch attacks on other networks that you are connected to:
- other Company X’s offices
- client’s internal networks (to which you have VPN access)
- supplier’s extranets
- computers and servers on the Internet
Note that all these actions would be executed from your computer, under your user account, and with your IP. This makes YOU (and your company) liable for anything that happens.
Now that you know why you are ‘tasty’ and a worthy target, I will create a fictitious scenario, which hopefully is a good description of your work’s environment.
The Victim’s Work Environment
The Victim (i.e. you) works for Company X who specializes in developing custom Windows and Web Applications for a wide range of clients.
Victim’s development environment:
- Two workstations (Desktop Computer and Laptop)
- Visual Studio .NET and Notepad
- VSS used for Source Code management
- Microsoft Office System used for:
- Document editing (MS Word)
- E-mail (MS Outlook)
- Calculator (MS Excel)
- Local work environment:
- Company X’s offices
- Your desk is located in a developer’s room (alongside five other colleagues)
- Development network is located inside the Company X’s internal network:
- your Desktop and your Laptop are plugged into this network
- there is no isolation between the Developer’s network and the other Company’s departments (i.e. a computer located in the Sales department can ‘ping’ your computer)
- protected by a Firewall at the main Internet’s gateway
- Remote work environment 1:
- located in your house
- desk is located in a dark room (hopefully isolated from everybody else)
- Development network is your home network
- you Laptop is plugged in there
- there is no isolation between your work Laptop and the rest of the devices plugged to your home network (your kid’s, wife’s, and nanny’s computers)
- a Wireless access point is plugged directly into your home network (which you use when doing some programming in the garden)
- protected by a Firewall at the main Internet’s gateway
- Remote work environment 2:
- Anywhere where there is a wireless Hot Spot (you need an Internet connection to make it work)
Based on our proposed environment, here are some examples of where the attack (i.e. the ‘infection’) could originate:
- E-mail with malicious attachment (which you have opened)
- E-mail with malicious attachment (automatically executed by exploiting an un-Patched vulnerability in your e-mail client software)
- Other computer
- located in your internal network
- located in a network that can ‘ping’ you (including the malicious user sharing your favourite Starbucks’ wireless service)
- A passing-by malicious user which connected to your home network using your wireless access point
- Your kid’s, wife’s, or nanny’s computer (previously compromised)
- A malicious colleague (who accessed your computer when you went out for five minutes)
As you can see, even in our limited example (I’m not including RAS/VPN connections and other variables) there is a substantial number of ways that your computer could be compromised.
In Part II of this article, the Malware concepts will be explained using a fictitious scenario where an attack is launched using a Virus.Worm.Trojan.Backdoor.RootKit.Malware (V.W.T.B.R.M.) program.
About the Author
Dinis Cruz is an experienced Security consultant based in London (UK) and specialized in Asp.NET Application Security, Active Directory Deployments, and Ethical hacking. Dinis is also the creator and main developer of the OWASP’s Open Source project: Asp.NET Security Analyser (ANSA). You can contact him at Dinis.email@example.com.