Showing posts with label RTL8029. Show all posts
Showing posts with label RTL8029. Show all posts

Sunday, September 26, 2010

The Stuxnet Worm, Windows & The Internet

A malware known as Stuxnet has attracted major media attention in recent days. This software inserts itself into computer systems using Microsoft Windows, Microsoft Explorer, and WinCC developed by the German electrical engineering giant Siemens AG. The latter piece of software is a Supervisory Control and Data Acquisition, or SCADA, application named Simatic S-7 that controls large scale industrial processes like power plants.

Stuxnet is a type of computer worm. That is, the program self-installs executable files that can be hidden on a USB flash memory stick or hard drive to the host computer. Subsequently, the executables are capable of transferring other files through the internet, if a connection is available. Stuxnet checks for narrowly specified system configurations and only acts if WinCC is running. Therefore, its mission consists of taking control of only a small number of exclusive targets.

An East European security firm was first to report Stuxnet last July. The worm is believed to have been active for about a year and has caused considerable disruptions in Asia, notably Iran. Potentially, the program may be capable of disrupting plant operations leading up to the destruction of the facilities. Its release is considered the first discovered cyber attack meant not only to disrupt information technology, but furthermore destroy capabilities.

The Chertoff Group's internet security expert David Falkenrath provides interesting insights on Stuxnet's impact and its ramifications in this interview by Bloomberg's Deidre Bolton entitled "Virus May Target Nuke Plant" aired Sep. 24, 2010.


Supposedly the vulnerabilities in Microsoft Explorer exploited by Stuxnet have been plugged. What may be of interest to the common user is that the worm used Microsoft approved security signatures from the network interface card chipset maker Realtek and the flash memory controller developer JMicron to install its files via the internet in the disguise of seemingly legitimate Microsoft-certified driver updates.

We should be safe as long as we keep our system and browser up to date with the latest security patches and avoid legacy hardware with obsolete drivers. That is, we should upgrade to the newest generation of internet adapter cards and regularly update the drivers, downloading directly from manufacturer sites.

Addenda
  • In 2007, a large-scale bribery scandal broke in Germany, implicating Siemens AG's business in Southeast Asia. By 2008, a number of employees involved in this affair were let go. It only takes one disgruntled software engineer with intricate knowledge of the SCADA program running the targeted facility, maybe with the help of one or two other hackers knowledgeable in Microsoft Explorer and USB driver vulnerabilities, to accomplish Stuxnet in revenge. Perhaps, Iran is a clever diversion, Siemens already paid, and we never find out the actually intended target (10/04/10).
  • According to William J. Broad and David E. Sanger's article with the title "Worm Was Perfect for Sabotaging Centrifuges" published online in the New York Times today, recent results from the ongoing examination of Stuxnet code suggest that the worm was meant to target the speed control of ultra-centrifuges as those used for uranium enrichment, revving up their speeds to destructive levels. Since the implicated controllers were identified as products manufactured by companies in Finland and Iran, uranium enrichment facilities in Iran may have been the target (11/18/10).
  • According to William Broad, John Markoff and David Sanger's article with the title "Israel Tests on Worm Called Crucial in Iran Nuclear Delay" published online in The New York Times yesterday, more signs point to Israel and the U.S. as Stuxnet's originators with centrifuges in Iran's Natanz uranium enrichment plant as the target (01/16/11).
  • John Markoff reports in his article with the title "Malware Aimed at Iran Hit Five Sites, Report Says" posted online Feb. 11, 2011, that according to a Symantec study Stuxnet may have infiltrated as many as five Iranian institutions in three, possibly four, waves (01/13/11).
  • Listen to KCRW TO THE POINT's Warren Olney interview David Albright, President of the Institute for Science and International Security, on Stuxnet's effects in Iran 44 minutes into today's show with the title "A New Paradigm in the Middle East". According to Albright, Stuxnet disrupted the Iranian uranium enrichment program noticeably, but only in small ways. The greater threat may lie in the potential of adversaries using the worm, now public, as prototype for future attacks elsewhere (02/16/11).
  • According to Noah Shachtman's WIRED report with the title "Computer virus hits U.S. drone fleet" published online on CNN today, U.S. drones have been infected with a tracking virus, possibly through USB flash memory devices. This is not quite stuxnet yet, but a first step seems taken (10/10/11).
  • According to David Sanger's article with the title "Obama Order Sped Up Wave of Cyberattacks Against Iran" published online in The New York Times today, U.S. officials unofficially admitted that U.S. intelligence agencies created Stuxnet in collaboration with Israeli cyber warfare specialists to destroy ultra-centrifuges at the Natanz uranium enrichment facility in Iran. The article is scant on detail and Sanger's book "Confront and Conceal: Obama's Secret Wars and Surprising Use of American Power" to be published next week may be more illuminating (06/01/2012).
Related Posts
Sources

Tuesday, April 7, 2009

Windows 7, Qemu & the Internet

I decided to participate in Microsoft's testing program for Windows 7 earlier this year. I downloaded the 32- and the 64-bit installation package iso-images from Microsoft's website. I envisioned to test the next generation Windows operating system as guest in a qemu emulator (version 0.9.1) using Ubuntu's Hardy Heron 8.04 as the host operating system. Hardy Heron is installed on a MSI K8T Master 2FAR motherboard with two AMD Opteron 242 CPUs and 4Gb of RAM. Binary versions of qemu compiled as applications for for Apple's OS X are available from Q. The installation of Windows 7 should not be different. Below I describe what needed to be done to render a successful installation.

KQEMU INSTALL
To install kqemu on the host, I essentially followed instructions provided on the ubuntu community documentation site here and on alien.slackbook.org here. Microsoft recommends to provide at least 16 Gb for Windows 7. I decided to create a raw image of 20 Gb and reserve 1024 Mb for RAM, that is the maximum qemu allows, in the /home directory for the guest, running the following command in the terminal:
  • qemu-img create -f raw windows7.img 20G

WINDOWS 7 INSTALL
I used the following command to install Windows 7 on the raw image:
  • qemu-system-x86_64 -localtime -net nic,model=ne2k_pci,vlan=0  -net user -m1024 -cdrom './windows7.iso' -boot d windows7.img
I repeatedly attempted to use the 64-bit version of Windows 7 without success. Each time, the installation process halted with a blue screen below.


By contrast, I was successful with the 32-bit version. The install went smoothly. I could login and test the applications. However, I could not connect to the internet. The internet icon in the bottom panel was crossed out. The problem solver suggested that the proper driver was not found. I was asked to provide one. The reader is advised to review the experience I recount below to the end.

INTERNET
I examined numerous threads on drivers for windows and qemu over several weeks. By default, Qemu provides an ethernet interface that uses the Realtek RTL8029 driver. This is a legacy driver that Realtek no longer supports. I found an installable driver v5.08 here.

Installing, the RTL8029 driver resulted in limited connectivity with no internet access. Advice on a windows help forum suggested that this problem may be solved with disabling the firewall. It did not work.

On my continued quest for solutions, I found the following suggestions:
  • Under Properties for the Driver found in the Network and Sharing Center, click Local Area Connection, uncheck the Internet Protocol Version 6 (TCP/IPv6) option.
  • Click Start in the bottom panel,
  • type regedit in the Search programs and files box, and click on regedit in the list.
  • If you are prompted for an administrator password or for confirmation, type your password, or click Continue.
     
  • Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip4\Parameters\Interfaces\{GUID}. In this registry path, click the {GUID} subkey that corresponds to the enabled ethernet interface. 
  • On the Edit menu, point to New, and then click DWORD (32-bit) Value.
  • In the New Value #1 box, type DhcpConnEnableBcastFlagToggle, and then press ENTER.
  • Right-click DhcpConnEnableBcastFlagToggle, and then click Modify.
  • In the Value data box, type 1, and then click OK.
I added one more step:
  • Locate and click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\Interfaces\{GUID}
  • On the Edit menu, click on New, and then on DWORD (32-bit) Value
  • In the New Value #1 box, type DhcpConnForceBroadcastFlag, and then press ENTER.
  • The Value data box remains set to: 0.
  • Close Registry Editor.
Note a DhcpConnForceBroadcastFlag value of 0 disables this registry entry. You can use this registry entry to prevent Windows from using the DHCP BROADCAST flag. After you set this registry entry, Windows never uses the DHCP BROADCAST flag.

Taking these steps did not render the ethernet connection with the RTL8029 driver functional either. Eventually, I disabled DHCP and entered the static IP addresses proposed on ubuntu's community documentation site manually:
  • qemu-emulated Windows 7 I.P. address: 10.0.2.15
  • Gateway address: 10.0.2.2
  • SubMask address: 255.255.255.0
  • DNS Server address: 10.0.2.3
Disabling the DHCP server did not help either. At that point, I concluded that connecting to the internet was not going to work with the legacy driver. Instead, I found here that recent versions of qemu may support the rtl8139 driver, though warning was given that this option would not provide any connectivity. Despite, restarting qemu with 
  • qemu-system-x86_64 -localtime -net nic,model=rtl8139 -net user -m1024 -cdrom './windows7.iso' -boot d windows7.img
produced a working connection to the internet, miraculously automatically. The system loaded the RTL8139C+ Fast Ethernet NIC driver from its own driver directory. The interface uses DHCP and found the correct IP addresses. I did not have to edit anything manually. The pre-installed driver can be replaced with the most recent driver from Realtek for Vista 64 and Vista bundled in the newest auto installation program (Submission ID: 1310628).

Further experimentation showed that the RTL8029 driver can be used as well. Once specified on the Qemu command line with the "-net nic,model=ne2k_pci" option, Windows 7 will load the RTL8029 driver, if it has been previously installed in the system's driver directory and configure an ethernet connection. The same will happen, when you start qemu with the default option "-net nic".

A crucial prerequisite for Windows 7 autoconfiguration to work successfully is that the RTL8029 driver must have been installed beforehand, because the driver is not included in Windows 7. By contrast, if RTL8139 is specified with the qemu command, the system loads the RTL8139C+ Fast Ethernet NIC driver pre-installed in Windows 7.


IE 8
Finally, I was ready to install the latest updates from Microsoft and test applications. I remain unimpressed with the Internet Explorer (IE) 8. This browser denies access to sites like this blog which are perfectly accessible with older versions of IE, Google Chrome, Firefox, Opera, Safari, and Seamonkey. IE 8 help does not suggest any precise actions to remedy the problem. Hence,
I opted for Google Chrome instead.

SHARED FOLDER
To access a shared folder on the host system, kqemu must be started with the following command in the terminal:
  • qemu-system-x86_64 -localtime -net nic -net user -m1024 -boot c windows7.img -smb /home/user/qemu_share
In order to access the qemu_share folder from Windows 7, the folder's permissions must be set for sharing on the host. In Windows 7, the folder can then be mounted following the sequence below:
  • Click Start in the bottom panel, choose Computer,
  • right-click Network and choose Map Network Drive...,
  • enter \\10.0.2.2\qemu_share on the folder choice line,
  • choose Reconnect at logon,
  • and click Finish.
SOUND
Qemu provides several options for sound hardware, the only option Windows 7 recognized on my setup was:
  • -soundhw es1370
Ensoniq's ES 1370 technology dates back at least ten years. I found an acceptable driver on the Ensoniq support site. The driver installer location can be accessed, using the following path:
E-MU Legacy Hardware support
Audio PCI
PC
Windows 3.1 Driver Version 3.30.06.

Alternatively, you may wish to download the driver installer directly here.

The driver's setup wizard refused to fully install the software. Intriguingly, the following Windows 7 update detected and upgraded the ES 1370 driver, I needed to set the variable QEMU_AUDIO_DRV in my environment. Which drivers are supported depends on your host operating system. The options can be reviewed with qemu -audio-help. I chose alsa. Therefore, the launch of the emulator must be preceded with the comands :
  • export QEMU_AUDIO_DRV=alsa
  • export QEMU_ALSA_DAC=dmix
  • export QEMU_ALSA_ADC=null
Though I turned up full volume in all controls, the speaker sound remained exceedingly attenuated. The problem does not reside with the host. My Windows 2000 XP system emulated with the same qemu version produces great sound. This shortcoming still remains unresolved.

RUNNING WINDOWS 7
At this point, the complete command line to boot Windows 7 on kqemu includes the following options:
  • qemu-system-x86_64 -localtime -net nic -net user -m1024 -boot c windows7.img -smb /home/user/qemu_share -soundhw es1370
I recommend to save this command line in an executable shell script. The blue screen still erratically pops up during boot. The system will boot up after a couple of tries.

Addenda
  • I applied the same procedure to successfully install the release candidate that became available for download on May 5, 2009. Reboot does not always work during installation. You may have to go through a number of lengthy repair routines that Windows suggests and be patient. Eventually, it will work (05/10/09).
  • I recently upgraded Ubuntu to Karmic Koala (9.10). This upgrade comprises a new version of qemu (0.11.0), changing the available options. With the new version, I can run the emulator with two central processing units, that is -smp 2. More types of emulated ethernet cards are available. As a consequence of the update, windows 7 uninstalled the rtl8139 ethernet driver after the next boot. I had to re-install the system-provided drivers with the Device Manager (Control Panel & System and Security & System). For sound, the es1370 option is still listed following the command qemu -soundhw ?. However starting qemu with this option now fails. I am investigating (11/28/09).
  • The sound problem is unrelated to qemu. After I removed the environmental variables for alsa from the start-up script, windows 7 recognized the virtual ensoniq sound card and installed the es 1370 driver. The loudspeaker icon on the bottom menu bar of windows 7 turned unstruck, indicating active sound. However, no sound is to be heard yet. The environmental sound variables many need to be set differently in Karmic, possibly because Karmic appears to use pulse audio instead of alsa by default. I am investigating further (12/22/09).
  • If pulse audio is used for sound, the above environmental sound variables must be replaced with: QEMU_AUDIO_DRV=pa (04/15/10).
  • The download link on www.softwarepatch.com for the RTL8029 driver provided above does not seem to work at times. I found an alternative at www.techspot.com here (08/03/10).
  • Because of recently exploited vulnerabilities, the use of the RTL8029 driver is highly discouraged. You may wish to read more here: The Stuxnet Worm, Windows & The Internet (09/29/10).
  • For those who are not obligated to use qemu as emulator, I am pleased to share that I have had great success with installing and running Microsoft Corporation's Windows 8 Consumer Preview (64 bit) on VirtualBox 4.1.10. VirtualBox is emulation freeware maintained by Oracle (formerly Sun Microsystems). The installation proceeded without impediments. I followed the suggestions for the best suited settings, and made sure that no warnings remained, before I started the installation. Red triangles alert to sub-optimally selected parameters in the settings pulldown menu. The most important choice may be to dedicate no more than half of the RAM installed in your computer to emulated base memory, even if the Windows operating system can be used with more. Since I installed the system on an old Apple MacBook (2.26 GHz Intel Core 2 Duo; OS X Snow Leopard, version 10.6.8) with only 2 GB DDR3, I limited the base memory to 1 GB. In addition, I limited the emulator video memory to 128 MB. I dedicated 20 GB to static disk storage, choosing the vmdk-format. With these settings the emulated operating system performs astonishingly well. Internet access is flawless. The virtual machine is accessible on our home network. For installation, I used the downloaded iso-image of Windows 8. Therefore, I had to make sure that the CD/DVD drive option pointed to the image for the initial boot. The image can be selected under the disk icon on the bottom bar of the virtual box or from the pulldown settings menu. Good luck (03/28/2012)!
Screenshot of VirtualBox running Windows 8 on virtual machine (Read more here).



Related Posts