07 October 2010

Bruce Schneier: The Story Behind The Stuxnet Virus

A government-produced worm that may be aimed at an Iranian nuclear plant? Of course it's made headlines.

Computer security experts are often surprised at which stories get picked up by the mainstream media. Sometimes it makes no sense. Why this particular data breach, vulnerability, or worm and not others? Sometimes it's obvious. In the case of Stuxnet, there's a great story.

As the story goes, the Stuxnet worm was designed and released by a government--the U.S. and Israel are the most common suspects--specifically to attack the Bushehr nuclear power plant in Iran. How could anyone not report that? It combines computer attacks, nuclear power, spy agencies and a country that's a pariah to much of the world. The only problem with the story is that it's almost entirely speculation.
Article Controls

Here's what we do know: Stuxnet is an Internet worm that infects Windows computers. It primarily spreads via USB sticks, which allows it to get into computers and networks not normally connected to the Internet. Once inside a network, it uses a variety of mechanisms to propagate to other machines within that network and gain privilege once it has infected those machines. These mechanisms include both known and patched vulnerabilities, and four "zero-day exploits": vulnerabilities that were unknown and unpatched when the worm was released. (All the infection vulnerabilities have since been patched.)

Stuxnet doesn't actually do anything on those infected Windows computers, because they're not the real target. What Stuxnet looks for is a particular model of Programmable Logic Controller (PLC) made by Siemens (the press often refers to these as SCADA systems, which is technically incorrect). These are small embedded industrial control systems that run all sorts of automated processes: on factory floors, in chemical plants, in oil refineries, at pipelines--and, yes, in nuclear power plants. These PLCs are often controlled by computers, and Stuxnet looks for Siemens SIMATIC WinCC/Step 7 controller software.

If it doesn't find one, it does nothing. If it does, it infects it using yet another unknown and unpatched vulnerability, this one in the controller software. Then it reads and changes particular bits of data in the controlled PLCs. It's impossible to predict the effects of this without knowing what the PLC is doing and how it is programmed, and that programming can be unique based on the application. But the changes are very specific, leading many to believe that Stuxnet is targeting a specific PLC, or a specific group of PLCs, performing a specific function in a specific location--and that Stuxnet's authors knew exactly what they were targeting.

It's already infected more than 50,000 Windows computers, and Siemens has reported 14 infected control systems, many in Germany. (These numbers were certainly out of date as soon as I typed them.) We don't know of any physical damage Stuxnet has caused, although there are rumors that it was responsible for the failure of India's INSAT-4B satellite in July. We believe that it did infect the Bushehr plant.

All the anti-virus programs detect and remove Stuxnet from Windows systems.

25 September 2010

Dean Takahashi: Stuxnet computer worm takes its toll on Iran, where nuclear plant may be target

Iranian officials have confirmed that the Stuxnet computer worm has infected at least 30,000 computers in the country.

The worm attacks industrial control systems. Because of that, officials have wondered whether Iran was targeted because hackers wanted to take down its controversial nuclear reactor, which is feared to be making high-grade plutonium for nuclear weapons. The Stuxnet worm, first discovered in June by Belarus-based security firm VirusBlokAda, might have been an attempt to disable the Bushehr reactor from afar.

Experts from Iran’s Atomic Energy Organization reportedly met this week to discuss how to remove the malware. The worm targets control systems that use Siemens’ SCADA software (supervisory control and data acquisition), which operates all sorts of factories from power plants to military installations. Symantec reported that Iran was hit hardest by Stuxnet, which was spread through universal serial bus (USB) flash memory drives that were left in areas where unsuspecting employees could pick them up and plug them into their computers.

Roughly 60 percent of all incidents related to Stuxnet have been reported in Iran. The question arises as to who created the Stuxnet worm and whether it was a state that doesn’t want Iran to have nuclear weapons.

Stuxnet exploited multiple unpatched vulnerabilities in Windows, relied on stolen digital certificates to disguise the malware, and hid its code by using software known as a rootkit. Microsoft hasn’t fully fixed the vulnerabilities. U.S. cybersecurity officials told the Associated Press they didn’t know who created the worm or what its purpose is. Certainly, it can disable more SCADA-based machines than just those in Iran.

19 February 2010

Why is the U.S. flag worn “backwards” on the uniform?

Army Regulation 670-1, Wear and Appearance of Army Uniforms and Insignia, is the governing authority for the wear of Army uniforms. Paragraph 28-18 governs the wear of the United States Flag on Army Uniforms.

The flag may only be worn on the utility and organizational uniforms (such as the camouflage BDU). The flag may only be worn during joint-duty and multinational deployments. When the servicemember returns to home station, the flag must be removed. (Guide Note: A message went out in February 2004 changing this restriction, and making the U.S. Flag a mandatory uniform componant for all soldiers, effective October 1, 2005.

Chapter 1, Title 4, United States Code, provides for the design of the U.S. flag and specifies the colors as red, white, and blue. Colors other than red, white, and blue violate the U.S. Code; therefore, subdued-colored flags are not authorized for wear. Joint commanders have to make the decision as to whether or not the wear of a full-color flag, for morale purposes, is more important than having all aspects of the uniform camouflaged.

When approved for wear, the full-color U.S. flag cloth replica is sewn 1/2 inch below the right shoulder seam of the temperate, hot-weather, enhanced hot-weather, and desert BDU; the BDU field jacket; and the cold-weather uniform. The flag is worn on the right shoulder, because, in the military, the “place of honor” is to a military member’s right.

The full-color U.S. flag cloth replica is worn so that the star field faces forward, or to the flag’s own right. When worn in this manner, the flag is facing to the observer’s right, and gives the effect of the flag flying in the breeze as the wearer moves forward.

The rule dates back to the Army’s early history, when both mounted cavalry and infantry units would designate a standard bearer, who carried the Colors into battle. As he charged, his forward momentum caused the flag to stream back. Since the Stars and Stripes are mounted with the canton closest to the pole, that section stayed to the right, while the stripes flew to the left.

Sumber :
http://adoptaplatoon.org/site/?p=77


01 January 2010

How to change hostname on Fedora

To change hostname on Fedora, you can do it in 3 ways. That are : edit the /etc/hosts file, edit the /etc/sysconfig/network file and running command line "hostname". As default, content of
/etc/hosts is :

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 lenovo localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6


As default, content of /etc/sysconfig/network file is :

NETWORKING=yes
HOSTNAME=localhost.localdomain


To change hostname, it's better to edit /etc/sysconfig/network file become :

NETWORKING=yes
HOSTNAME=lenovo


Suppose, the hostname is "lenovo". Don't forget to reboot the computer to make effect.

Beside that, you can change hostname with not permanently with command line "hostname". The code is :

# hostname "lenovo"

06 December 2009

Installing Fedora 11, 10 or 9 From USB Stick

To install Fedora 11, please follow the instructions given for Fedora 10 below but make sure the bootable partition is slightly bigger because the net install iso on Fedora 11 is bigger than the one in Fedora 10. I gave the bootable partition 512 megs and it worked perfectly.

The aim of this post is to explain how to install Fedora directly from a USB stick containing the Fedora*-DVD.iso image. For those impatient, just go to the Instructions section.

It’s been almost 2 years since I said goodbye to Windows and moved my work laptop to Fedora, and I couldn’t be happier with the move. If you wanna find out why I’m happier with Fedora, just carry on reading my blog over the coming months. For the moment, I’ll be focusing on the Fedora installation process. One of the best things about Fedora is that it gets released twice a year so you keep upgrading your machine to the get the latest features, latest bugs…etc. This means that you end up downloading and burning a Fedora ISO into a brand new DVD every 6 months. As you can imagine, I was quickly piling up DVDs that were useless soon after. So, after having looking around in electronic shops, I realised that USB keys had gone down in price and that you could get an 8GB USB stick for little money. This happened at the same time that I was getting a new laptop at work, so I wondered, what about I get myself one of those sticks, put the latest Fedora image on it and install it from there rather than burning yet another DVD? For sure, installing from an USB key was always going to be faster than from a DVD, so that was a plus as well.

For some reason, maybe because people haven’t tried this that much, it took me a while to find some decent instructions on how to do this. Eventually, this came from Michale Hartley’s comment on Haral Hoyer’s blog entry on “Fedora 8 on a USB stick”. However, I had some issues with these instructions, specially when trying to create the bootable partition in the USB stick, so I ended up writing my own set of instructions for Fedora 9:

Installing Fedora 9 from USB stick :
  1. Download Fedora-9-i386-DVD.iso
  2. Download Fedora-9-i386-netinst.iso
  3. Create 2 ext3 partitions in USB stick (Hint: GParted is a wicked graphical tool to create partitions): A 200 MB bootable partition and another partition with the rest of space.
  4. Copy Fedora-9-i386-netinst.iso to 1st partition:
    # livecd-iso-to-disk Fedora-9-i386-netinst.iso /dev/sdb1
  5. Copy DVD iso image to 2nd partition:
    # mount /dev/sdb2 mnt-sdb2/
    # cp Fedora-9-i386-DVD.iso mnt-sdb2/
    # umount mnt-sdb2/
  6. Reboot with USB key inserted.
  7. Select install from Hard Drive and select /dev/sdb2
When Fedora 10 was released, I followed the same steps to install as I did for Fedora 9 but I kept getting an error saying that no image could be found in /dev/sdb2 even though the Fedora 10 DVD iso image was there and had passed the SHA1SUM test successfully. After exchanging some emails within Red Hat I was pointed to the Installation from a Hard Drive section of the Fedora 10 documentation, which mentioned that install.img had to be present under the images/ directory in the partition from where Fedora 10 had to be installed.

On my 2nd attempt, I extracted the entire DVD iso and put it in the USB stick so that images/install.img would be found but doing only that didn’t work. In the 2nd phase of the installation, I was told that an image was missing. I just couldn’t understand what the hell was going on, so eventually, after a few further email exchanges, I worked out what needed doing: First, images/install.img had to be in the USB stick and next to the images/ folder, you needed to have Fedora-10-i386-DVD.iso. So, here’re the instructions to install Fedora 10 from USB stick:

Installing Fedora 10 from USB stick
  1. Download Fedora-10-i386-DVD.iso
  2. Download Fedora-10-i386-netinst.iso
  3. Create 2 ext3 partitions in USB stick (Hint: GParted is a wicked graphical tool to create partitions): A 200 MB bootable partition and another partition with the rest of space.
  4. Copy Fedora-10-i386-netinst.iso to 1st partition:
    # livecd-iso-to-disk Fedora-10-i386-netinst.iso /dev/sdb1
  5. Extract images/ folder from Fedora-9-i386-DVD.iso and copy to 2nd partition:
    # mount -t iso9660 Fedora-10-i386-DVD.iso mnt-dvd/ -o loop
    # mount /dev/sdb2 mnt-sdb2/
    # cp -rp mnt-dvd/images mnt-sdb2/
    # umount mnt-dvd/

    Note: If you do a ‘cp -a’ as recommended in the Installing from Hard Drive section, you’ll get an error like this, so just use ‘cp -rp’ instead:

    SELinux is preventing cp from creating a file with a context of iso9660_t on a filesystem. Usually this happens when you ask the cp command to maintain the context of a file when copying between file systems, “cp -a” for example. Not all file contexts should be maintained between the file systems. For example, a read-only file type like iso9660_t should not be placed on a r/w system. “cp -P” might be a better solution, as this will adopt the default file context for the destination.

  6. Copy DVD iso image to 2nd partition:
    # cp Fedora-10-i386-DVD.iso mnt-sdb2/
    # umount mnt-sdb2/
  7. Reboot with USB key inserted.
  8. Select install from Hard Drive and select /dev/sdb2
And that’s it. I’m fully aware that these instructions could be simplified/reduced but can’t be bothered to do that right now. It’s not something that I’m doing on a daily basis and it works, so I’m happy to leave them as they are for the time being. If anyone has any suggestions, please feel free to comment.

See :
http://galder.zamarreno.com/