Wednesday, November 22, 2017

New blog site

I won't be posting on this site anymore. Click here to visit my shiny new blog powered by the fancy

Peace out!

Sunday, July 4, 2010

CRS report RL32114

CRS Report for Congress, Order Code RL32114, updated January 29, 2008, by Clay Wilson (Specialist in Technology and National Security of Foreign Affairs, Defense, and Trade Division), phew... is entitled "Botnets, Cybercrime, and Cyberterrorism: Vulnerabilities and Policy Issues for Congress" [1]. I will proceed to describe the report, and provide comments, according to its title.

On Botnets. Bot Networks (Botnets) are networks of computers that are enslaved by the botmasters, this is done my infecting the computers with malicious codes, such that they can be controlled remotely. Users of the machines that are part of the botnets doesn't necessarily know that their computers are infected. Botnets could consists of hundreds or thousands of computers which is more that enough to be utilized to disrupt a targeted internet service.

This brings us to the significance of botnets in this report. Botnets are one of the most dangerous weapon to cause a Distributed Denial-Of-Service (DDoS) attack. This attack causes unavailability of a particular network service that was targeted. The worst part is the first D, because of its distributed nature it is hard to determine where the primary attacker machine is. As a result, it will be harder to solve the problem causing lengthened disruption.

An example of a DDoS was describe in the report, which was the 2007 attack on the Estonia government computer systems. It quickly became a major interest to US, obvious by the sending of a team of experts to investigate the incident and help bring services back up (NATO also sent computer security experts). An interesting finding I'd like to point out is that the attack was not conducted by a group, but was a result of posting the malicious code on a online forum. I could imagine, who could resist trying to "hack" a government site? So, all the Curious George with access to the post, plus the ones with the political reasons, followed the instructions and tried out the code. Walla! A DDoS.

Good news to them, bad news to US. And Estonia, of course, but we'll leave them for now, last I checked their OK now, except for over-due maintenance [click 2]. Why does this "little" incident
interest US so much? The answer must be Cybercrime and Cyberterrorism.

On Cybercrime and Cyberterrorism. The Estonian DDoS is an example of a cybercrime where it is hard to pinpoint the culprit. Even though there have been arrests relating to the attack, I do not believe that next time around such attack would not happen. This goes down to vulnerabilities and policy. While creating policies will certainly help in exercising justice, a solution that could bring the most effect must be finding and fixing vulnerabilities. While politicians should be aware of the issues with the help of experts, computer system administrators must be more vigilant in securing systems.

Back to the issue of US, these cybercrime could easily be turned into cyberterrorism. At the moment, it could be said that US is the leader in computer system research and implementation. Many services crucial to the mass is dependant on computer systems. The concern is a DDoS attack on American computer infrastructures, especially if it has terrorism motives. Would it be possible to perform such an attack? What could be the most devastating effect? What should be done in case of a successful attempt? How to trace the "actual" attacker? These questions are the ones that I think should be answered after the report.

I am particularly interested in the different attack methods that are mentioned in the report, which are:
  • Physical attack,
  • Electronic attack, and
  • Computer network attack.
In developing computer systems, we need to pay attention to these attacks. In my opinion, physical attacks could be limited by policies or security procedures, electronic attacks should be anticipated by back-ups (EMP is hard to anticipate though), and computer network attacks is where the battle becomes interesting. Although there are cautions about secure coding and safe practices in system administration, most of the time the "good guys" still has to play catch with the black hat hackers.

1. C. Wilson: Botnets, Cybercrime, and Cyberterrorism: Vulnerabilities and Policy Issues for Congress (Updated 29 January 2008).
2. Estonian state: Main Page [] (Last accessed 4 July 2010).

Wednesday, June 16, 2010

Trust a program?

In the lecture entitled "Reflection on Trusting Trust" [1], Ken Thompson raises the issue of trusting a software to be free of malicious code. He started by describing two simple programs, a self-reproducing program and a learning program. These two concepts were then used to build a UNIX login program that contains a Trojan horse. The program, which allows access to the system as any user, writes itself into the compiler (self-reproducing), then removes trace of the deliberate bug (learning). This untrusted code, demonstrated to be easy to produce, will be hard to detect, even becomes more difficult if written using lower level languages (demo source code was in C).

The paper makes me think about the large software systems that we currently use. How can we be sure that these systems are not violating our privacy? In a bigger picture, the government and major private entities are also using computer systems in managing critical resources to the mass. These systems are operated using softwares that could not be said to be perfectly secure.

Relating the paper to my research interest, this problem is in the spotlight when considering e-voting systems. When adopting an e-voting system, a democratic state has to convince its people that the system is trustworthy. Citizens want to be assured that the machines acts correctly. To address this issue, one of the security measure is to perform a source code review. We can find a detailed example of a source code review for e-voting machines in [2]. Vulnerability as described in the paper is one of the many reasons for this procedure. The difficulty of performing a thorough source code review should not stop us from trying. While source code review is usually done by a selected group of experts, another concept that could help detect such vulnerabilities is developing an open-source software. This has been practised in Australia, reported in [3]. By posting the source code of the software, the public could review and gain more trust in it. We should not rely on security by obfuscation. The more scrutiny, the higher the possibility to detect and fix existing vulnerabilities.

There are too many advantages of employing a computer system with its set of softwares. Although we cannot be completely sure that a system is safe, we can implement procedures that can increase trust.

1. K. Thompson: Reflections on Trusting Trust (August 1984).
2. California Secretary of State: Top-to-Bottom Review [] (Last accessed 16 June 2010).
3. WIRED: Aussies Do It Right: E-voting [] (Last accessed 16 June 2010).