by Roy Tov
Friday, June 1st, 2012
Israel’s Vice PM Ya’alon Practically Admits Responsibility for Flame Worm
On Tuesday, May 29, 2012, Israel’s Vice Prime Minister Moshe Ya’alon made official comments during an interview to Israel’s Army Radio on the involvement of Israel in the development and deployment of Flame, a computer worm that on the same day was blamed for a series of attacks in Iran, the West Bank, Sudan, Syria, Lebanon, Saudi Arabia and Egypt. “It is reasonable to assume that anyone considering the Iranian threat as significant, will take several steps, including these [the worms],” he said, and added: “Israel is blessed as being a country rich with high-tech, these tools that we take pride in, open up all kinds of opportunities for us.” Very few Hebrew listeners would fail to understand this as: “I admit, but will not be more specific” statement.
Flame and Stuxnet
Considering the size of the egos involved, one could claim that Ya’alon was just boasting, and dismiss the entire issue. Yet, last month, Iran’s oil ministry, national oil company and main export terminal were all hit by a computer worm; authorities managed to prevent major damage by disconnecting them from the web. After the event, Iran said that there is a long-running technological war with the United States and Israel. Tehran has repeatedly announced it has defused malware in its industrial sector, including the highly specialized Stuxnet worm in 2010, which had targeted the country’s nuclear facilities uranium enrichment facility in Nantaz. Iran admitted that the worm had damaged centrifuges. Earlier this year, the head of Iran’s civil defense agency Gholam Reza Jalali said that the energy sector of the country has been a main target of cyber-attacks over the past two years. Yet, the attack that took place this week was different from the Stuxnet related events since it was discovered from afar.
On Monday, Internet security company Kaspersky Lab announced it had found the worm Flame in over 600 computers in the Middle East, including computers owned by businesses, academic institutions, and government systems. Flame was defined by the company as a sophisticated attack toolkit, capable of transferring files, screenshots, audio recordings and keystrokes from infected computers. The company added that Flame contained a specific element that was used in the Stuxnet worm and which had not been seen in any other malware. Moreover, Flame was described as much more complex than Duqu, the electronic vehicle used to deliver Stuxnet. Kaspersky also said that certain parts of the new worm were identical to those used by the worm that hit the Iranian oil industry last month. The company summarized the event claiming that Flame could have been developed only by a state-actor. In other words, Kaspersky claims we are watching evolving versions of a worm computer designed by a large organization, “no doubt a state” according to the company, or a few of them working together. “An organized, well-funded group of people working to a clear set of directives,” further defined them the company. In 2010, Israel and the USA were widely blamed for Stuxnet.
A representative of Kaspersky Lab spoke to Israel Army Radio on the same day and said: “the worm does not operate independently, but is controlled by a remote computer, and thus only when it receives an order does it start working. For this reason, it is difficult to detect, because it is not always active.” This activated all my alarms; I have seen that before.
The Worms and You
Veteran readers of this website may perhaps remember that, in 2009, I published a series of articles on the safe use of memory cards. Afterwards, I unified them in a single article, and this year the latter was published as a chapter in The Cross of Bethlehem II. These texts were the result of ongoing attacks on my memory cards that had forced me to develop defensive techniques allowing safe access to the web. I have no doubt that the vast majority of internet users are susceptible to the type of data-collection techniques implemented by Flame. I have also no doubt that the West is developing these tools for years with the non-consensual cooperation of its unsuspecting citizens. At the very least, the victims of this scandalous behavior should be notified; this is what makes the Nazi regime a more moral kind of state than the Western Democracies are (see Israel’s Eugenics Program: Dr. Mengele Blues). As a service to my readers, following is an update of the rules for data storage protection.
A computer connected to the internet is on enemy territory. No storing device should be connected to it, unless it is in the form of a buffer one, to be described later. Download all the files desired for subsequent work into the computer. Then, disconnect the computer from the web. This should not be done electronically but by physically pulling out the cable. Then, connect the storing device to the computer, and transfer the files to it. This doesn’t provide absolute protection since signals can still be picked up from nearby with certain equipment, but for regular work, this is robust enough. Unluckily, this is not possible with wireless devices. All work on files should be done from an extractable device; if editing the text—or working on the data—from software installed on the computer, make sure of cleaning any temporary files created on the computer during the process.
Since 2002, I work primarily with memory cards and their readers; memory sticks are less convenient than split devices since if their reader goes wrong, saving the memory part of the device is complicated. The technology of these cards is based on solid-physics and in all my tests they have proven to be also physically solid. I never experienced an unprovoked problem with them and am quite confident the cards can survive everything I’ll survive. Yet, since October 2009, my memory card readers are systematically short-circuited every few weeks. I took one of them to be checked out at an electronic laboratory; they found traces of short-circuit. This is an unsolved problem; I am still experiencing this in 2012. It forced me to develop a mobile and robust data storage system, which is not entirely accessible to government spooks.
The idea is to keep a set of cards. One is designed as “Buffer Zone,” files downloaded from the web and still unorganized, or files about to be uploaded are to be kept in it. The organization of the files on it should not resemble in any way the one in the “inner cards.” The latter are where all data should be stored and worked on; these cards are never to be connected to the web. Yet, they could be accessed through a resident worm designed slightly different than Flame is. Thus, the following rules are crucial.
Unluckily, the computer industry (including Mac computers) has adopted Microsoft FAT as the files organization system. This allows rapid access of snoopers to the structure tree of your files. There is no way to avoid malicious software at least copying the structure. Thus, change the structure often, so that no scripts targeting specific files would be effective on your card. In the past, I have been the victim of a quite vicious attack on the FAT system of my buffer card. Several computers in the various shops I was working on began reporting problems with their available memory. None of my subsequent tests justified the report. Then, if I saved any of my open files it would be saved wrongly, ruining also the FAT data of physically adjacent files. This causes a snowball effect; the more files you touch, the more extensive the damage becomes. Once this is spotted, disconnect the memory, and go to a safe computer. Copy all the files from the memory card to the computer; during this process, don’t open them. Note that damaged files won’t copy. Then, format the damaged card. Afterwards, copy the files back from the computer to the card. Restore the damaged files from a backup card, and then wipe out the computer you worked on; cleaning programs are easily found these days; sensitive files stored on the computer should be thoroughly shredded before re-connecting it to the web. This type of file should not be “cut and paste;” otherwise you’ll need to wipe the entire hard disk to ensure deletion. To be entirely safe, replace the whole operating system on the computer after wiping it.
There is another instance in which Microsoft sold us out: autorun.inf. This is the name of an archive capable of automatically launching a program or a script. Amazingly, Windows defaults leave active this dangerous file on mobile devices. In this way, you can easily transfer virus and worm attacks from computer to computer. The best defense is creating an inaccessible mule, a sterile autorun.inf on your card. There are free programs on the web performing this service.
Kaspersky Lab warned that Flame is activated upon recognition of the victim; in the case of a public computer, this is achieved in one of two ways. The first one is obvious: by logging into one’s accounts. The second is often overlooked. All the readers I tested until now do not include personal identification numbers (IDs), but all the memory cards include one. This number can be used to track down a specific person using a public computer. I recommend changing the pre-installed ID number; as a service to my readers, I am attaching a link to a suitable—and free—program. In order to keep this article friendly I won’t explain here how to use the program. Users experiencing difficulties in its use are invited to contact me. The masterstroke is that we all should use the same number, rendering useless the true Number of the Beast. I propose using 0000-0000; hinting thus at the new value of this institutional human rights violation.
Related to this are various scripts that can be implanted in the card, and are activated by the autorun.inf and similar files. To be sure the card is clean, make visible all hidden and system files. Scripts featuring the .vbs extension would then be visible. Delete all scripts. Another noteworthy point is avoiding storage of files with active code in them, like .html files. Change their extension or save the content in a text format. Following an attack on my personal copy of this website’s code, I moved to .txt files and have not experienced a similar attack since 2009. Note that files allowing macros, like the Microsoft Office ones, are extremely vulnerable.
Another serious security problem results from the tendency of most of us to use a constant file structure. That allows writing scripts that allow downloading files without the victim being aware of that. The solution is simple. Store the files in a tree structure, and change the root directory name often; this works well against off-line scripts especially if the structure includes thousands of useless files used specifically for this purpose. The name of the root directory should be changed every time the work is begun and not at its end, in such a way, if working offline, snoopers cannot change the script to allow for the new structure on time. Moreover, a decoy mock-structure should be kept on the same card; this should allow for some extra-time if by any chance using an infected computer. The abovementioned “inner card” with the main files should be connected to a computer as little as possible.
All this is fine, but it doesn’t solve the presence of key-loggers in public computers. I have proven the existence of these to my satisfaction, even before Flame was disclosed. If working on a public computer on highly sensitive files, there are several ways to make sure the key-logger is deactivated. I’ll mention only the most obvious solution. After the work is saved, and while the computer is kept offline at all times, perform a low-level format of all the hard-disks and their partitions from the card. Only experienced users should do that; the staff at the kiosk would afterwards need to re-install the operating system, but no other damage is caused. Rotating between the available public computers is vital because it blocks certain systematic attacks.
A key feature of keeping such a mobile file system is being able to roll-back to its past positions, so that if a delayed attack is performed, the system can be easily recovered. This can be achieved with many backup tools available in the market; yet, that would be a serious error. You cannot be sure you purchased unmodified software, and it will be cumbersome to assure your copy was not modified by a worm after it was installed. The answer is creating a roll-back system manually. There are several forms of making this; one of the features assuring its safety is not disclosing the exact method one adopts. Daily, weekly, or monthly? Total, or partial? I won’t be more specific; in any case, also here it is important to create decoys and mock roll-back systems. /p>
How much unproductive work caused only by the unlawful activities of civil-servants! Why don’t the American and Israeli administrations engage in doing good? They won’t need to fear attacks then…
Parts of this text were adapted from The Cross of Bethlehem II: Back in Bethlehem.