Not even a band-aid yet...

Some new developments in the Siemens SCADA trojan story…

It turns out that the trojan uses a well known default password to log in to the backend MySQL database used by Siemens’ software but Siemens has told users of the software (factories, power plants and the like) NOT to change the database password, as doing so would cause the software to stop working.  A fix is forthcoming, but plant operators are likely to have an anxious few days (?) until a solution is available.

A second version of the trojan program has been detected on the Interwebs.  The new variant seems to also be targeting SCADA systems and is also signed with a code certificate (this time from Taiwan based JMicron Technology Corp, which has offices in the same location as the firm whose cert was appropriated for the first version of the worm).

The whole default password thing is just plain embarrassing… this is a problem from another era, which should be an unpleasant memory by now.  It seems like it would be easy to eliminate this problem programmatically by creating a unique database password (derived from the license key and a secret, maybe?) by default when the software is installed.  Or at least require the installing user to enter a password during installation.  SCADA systems control the technological backbone of our civilization (power, water, sewage, manufacturing) and deserve better security than this.

As far as the underlying vulnerability used to spread the Stuxnet code, we are still at risk – a patch has not been released by Microsoft yet, and while the major anti virus vendors have released signatures which detect the SCADA worm, it is only a matter of time before we start seeing other, new malware using this vector to spread.   It seems like using a Group Policy Object to prevent executables launching from drives other than C might be the best way to protect your networks for the time being.

Stay tuned…

In addition to raising the spectre of an attack against critical infrastructure, this series of attacks also provides makers of all sorts of malware targeting corporate and personal systems with a new 0-day vector for infection.  The flaw can be exploited by getting users to browse a USB drive, a Windows file share or a WebDAV file share.   The flaw seems to be able to bypass the No Autorun protections in Windows as well as Windows 7′s UAC protections.  If I were a malware author, I would be all over this as a way to get my creation installed on as many machines as possible before Microsoft issues a fix.

Microsoft is aware of the problem and has issued a tech bulletin with a workarounds that is are pretty unworkable for most corporate environments.  According to a blog post by Chester Wisniewski of Sophos, one way to effectively combat this attack in a corporate environment is to set up a GPO (group policy object) which prevents executables from running from drives other than the C: drive.  This may be the best way to respond to this threat until Microsoft issues a patch, hopefully before the next Patch Tuesday.

The malware arms race goes on…

Oh hai! We're in ur companies steeling ur sekretz

The Russian spy ring seems to be the gift that just keeps on giving in terms of blog fuel.

First… if this story is to be believed, one of the spies set himself up as a consultant, talking to companies about their plans for a post oil economy (a subject of interest to fossil fuel producers such as Russia) and pitching a software package to help companies model the effects of future events on their businesses.  Since this software would be installed on customer networks, it could be used as a vector to plant spyware on clients’ computers.

Another report reveals that a Russian man who may be linked to the spy ring and who was recently deported had worked at Microsoft as a software tester both as an intern and as a full time employee.  He worked in Redmond for less than a year, and Microsoft claims that no software was compromised.  Hmmm.  I hope the boys and girls are putting in some serious overtime looking at what this guy had access to.

If true, these stories point to a new face of state sponsored espionage – one focused on the private sector, which is much less prepared to protect the secrets which are important to their business as well as to the critical infrastructure.  Another good reason for security folks to join their local InfraGard chapter and learn more about protecting their businesses (and their country) against corporate espionage.

Sometimes, the best place to hide things is in plain sight...

One of the revelations from the recent capture of a number of deep cover Russian spies here in the US was that they used steganography (the concealment of data within innocuous looking files) in order to hide and transmit secret documents and messages to their handlers.  Steganography is one of those techniques which get talked about a lot a security conferences, but has not seemed to play a major role in news of security breaches.  This seems a bit odd to me – stego seems like a great way to exfiltrate information in plain sight.  By embedding ill gotten data in vacation pictures posted to Flickr or Facebook, spies (corporate or otherwise) can create very low risk electronic dead drops with a few mouse clicks.  Unlike encryption, stego does not leave suspicious encrypted files to exfiltrate, just innocent looking pictures or songs.  The software needed to create stego protected files is available on the Net.  So why (other than some articles about Al Qaeda reportedly using stego to embed secret information in internet images) do we not hear more about this technique?  I have a couple of hypotheses here:

Attackers are using stego, but they are not getting caught. Detection of files with steganographically hidden content is very difficult, requiring very specialized knowledge and tools which most enterprises and forensic examiners don’t have access to.

Attackers don’t need to use stego because they don’t need to. There are so many organizations out there who do not have a handle on what information is leaving their networks, that they don’t feel the need to go to the trouble of hiding the information they are swiping.  Or they are using really low tech methods to get the data out of the organization, like printing, or fax, or this.

Is stego a real threat to the enterprise?  I am not sure.  But the availability of stego underlines the need to build a security culture in your organization and use both technology and non tech means to detect potential problems.  Stego seems to be a tool which insiders would be predisposed to use – detecting insider threats takes both technology and plain old vigilance.  There is some excellent information on detecting insider threats available from the CERT team – this should be on your reading list.

This post was inspired by Kai Axford’s (Accretive Solutions) great presentation at today’s New York Metro InfraGard meeting.

Is Microsoft a cyber-Benedict Arnold?

OK, call me a cold war relic, but I find the recent revelation that Microsoft has provided the source code for Windows, SQL Server, and Office to the Russian FSB (the spies formerly known as the KGB) as well as to the Chinese government quite disturbing. As recent events prove, Russia is still actively engaged in espionage against the US public and private sectors.  We know that the Chinese People’s Liberation Army is actively building an offensive cyber capability and that they use technology to suppress free expression in their country.  Microsoft’s disclosures have been going on since 2002, as part of a program under which Microsoft has supplied source code for its products to a number of countries as well as NATO.

It does not take too much imagination to conjure up visions of Russian or Chinese  government security researchers finding zero-day exploits to allow their paymasters to craft undetectable malware which is then placed on US government and private sector computers.  Such an attack would be a cost effective, low risk way to gather more information in a day than the recently unmasked spy ring was able to collect over a decade.   It takes even less imagination to envision the Chinese government using their access to Windows source code to build more efficient tools to monitor and muzzle those who dare to speak out against the Communist Party.

This incident raises a number of  interesting questions.

Is Microsoft (a company born in America, whose success was built on the US market, and which benefits from tax breaks funded by US taxpayers) right to provide access to source code of products which are the underpinnings of all sorts of critical infrastructure to nations which are actively engaged in espionage against the US and whom we may meet on the cyber battlefield of the future?  It seems to me that this is sort of like hiring a company to build a fort and then allowing them sell the plans to your adversaries.

Should Microsoft’s products have some sort of special status which recognizes them as part of the US critical infrastructure?  After all, Microsoft has been allowed to gain what is basically a monopoly in the US market for operating systems and other key software.  Does this engender a responsibility on their part to act in accordance with US national interests?   I think it does.

Microsoft hasn’t done anything illegal here.  It would be nice if they felt a need to protect the critical infrastructure of their country, but as a private entity with no laws or regulations to prevent their actions, they made the logical business decision to share the source code in order to gain better access to the Russian and Chinese markets.   However, their choice is a bum deal for the rest of us, who will have to deal with the repercussions of this decision while Microsoft reaps the profits.  We need to tell our legislators that it is time to take a fresh look at what we ask of companies like Microsoft and Cisco, whom we have allowed to develop monopolies on key parts of the nation’s critical infrastructure.  In the conflicts yet to come, cyberspace will play a key role – and Microsoft has sold the plans for the fort to potential adversaries.

something new for the po-po to listen to?

Here’s an interesting story that bears some watching… security researcher Sean O’Neill claims to have reverse engineered the proprietary encryption which Skype uses to protect voice, video and IM communications on its network.    This work, while impressive, does not mean that Skype’s encryption has been broken, since knowing the details of an encryption algorithm does not allow you to decrypt data unless you can also derive the keys used to encrypt the data.  However, there are some reports that the O’Neill’s code has been used to launch spam attacks on Skype users.  I am sure that intelligence and law enforcement agencies all over the world are quite interested in how this all turns out, as they have complained in the past that Skype provides criminals, terrorists and other n’er do wells with un-wiretap-able communications.  O’Neill plans to provide more information on his work at the Chaos Computer Congress in December. 

In the mean time, I plan to continue using Skype without too much worry.  Of course, I’ll think twice about using it for coordinating the global tentacles of my evil plan for world domination, but I see no reason to avoid Skype for personal and business communications right now.  Stay tuned.

Daniel Dantas did...

Looks like open source disk encryption software TrueCrypt has shown its mettle in a cybercrime case out of Brazil.   The Brazilian police seized 500 TrueCrypt protected drives from the apartment of Daniel Dantas, a Rio banker accused of financial crimes.  In Brazil, there is no law compelling defendants to reveal passwords to encrypted evidence, so the Brazilian crime lab attempted to break the encryption for five months with no success.  They then turned to the US FBI, who ran dictionary attacks against the encryption for another year.  No joy.  As a result of the banker’s good password practices, the 500 drives with potential evidence were reduced to really ugly paperweights.

While this was a loss for the good guys, it does provide security professionals with some valuable information.  First, choosing a strong (long non dictionary word with special characters, numbers and the like) password is still an integral part of good basic meat and potatos security practice.  Second, if the FBI is unable to crack a TrueCrypt protected drive without the user having chosen a boneheaded password, it seems like the program  is a good and cost effective choice for protecting personal data as well as in small business environments.  The only thing missing for bigger business is some sort of key management and recovery scheme… sounds like an opportunity for an entrepeneurial crypto programmer.

In the old days, this type of scam was called “salami slicing” – stealing just a little bit (one slice of salami) from a lot of people adds up to a big salami.   Mmmmmm…. salami…. 

This is a really hard type of fraud to fight… since so few of the charges were contested, it took 4 years for and credit card issuers and feds to find a pattern.  In the mean time, all of the victims suffered very small losses.  The ringleaders got their millions and are still on the lam (eating salami and caviar sandwiches, I assume).

Apple, you're killing me!

If you ask people in my office what they hate about me, one of the items that is sure to show up on quite a few (long and varied) lists is my stubborn refusal to clear iPhones and iPads as corporate devices.   Well, my stubborness has been vindicated twice over…

First a security researcher found that connecting a stock iPhone 3GS to a system running Ubuntu Linux provides access to get read and write access to much of the content on the phone without having to enter the 4 digit phone PIN.

Now, Apple, in claiming that its flagship product is enterprise ready, tells us that iPhone3GS offers hardware-based- encryption and uses AES 256 bit encoding to try to protect all data on the device. Encryption is always enabled and cannot be disabled by users.   I guess that the Apple version of AES just happens to replave every character with the same exact character…

This morning, the situation developed further… further research by Heise Security in Germany showed that it was possible to gain complete access to all data some iPhone 3Gs and 3GSes by connecting to them from a Windows system.  The trick does not work every time on every phone, and it is still unclear what the exact conditions are which case the vulnerability to manifest itself.  When it does work, this vuln allows the attacker to create an iTunes backup of all of the information on the device.  Not good.

There is some good news… it also appears that making sure your iPhone is locked before you shut it down interferes with this particular attack.  It seems that the problem occurs in the split second when the unlocked phone wakes up, decides it needs to lock itself and locks the device.  If the phone was locked before you put it to sleep, the opportunity is lost.   Of course, how many people take the time to lock their phone before hitting the sleep button?

Yet again, we have proof that the iPhone is not ready for use as a corporate device. Apple has really dropped the ball here – they need to figure out what the problem is and issue a fix.  Now.    I think that they are going to have a really hard time convincing corporate users (especially those in heavily regulated industries) that the iPhone and iPad are safe to store sensitive information on.

So, what does the average iPhone/iPad/iPod touch user do in the mean time?  I’d suggest not storing anything you really want to keep secret on these devices unless the application performs its own encryption.  You might also want to take a few seconds to lock your device before hitting the sleep button – especially if the device is going to be out of your control for any length of time.

As for Apple, you guys really need to decide whether or not you want to be in the corporate space.  If so, get your act together, hire some really good security people and test the hell out of your products before trumpeting their “enterprise readiness!”  And this advice is coming from someone who owns an iMac, 2 iBooks, 2 iPods and an iPad – just think how the non Apple owning IT or Infosec manager is going to digest this news when looking at the iPhone for use at work.  We expect more from you guys…

The user does have to cooperate a little bit… When the code is about to execute, a dialog box will appear and the user will have to click OK.  Not to worry, nefarious malware authors, in addition to users’ propensities to click OK when asked, you can customize the dialog box to make it seem innocuous – “Click here to accept the license agreement, or “Click here to decrypt this document” are two ideas that come to mind.

If you are a super security savvy user who decided to abandon Adobe Reader in favor of the alternative Foxit Reader, you are in worse shape, smart guy.  Versions of  Foxit Reader prior to 3.2.1.0401 do not provide the dialog box warning – they just executes the embedded code.  Foxit has issued an update and I suggest that you install it toot sweet…

I have not yet seen any information as to whether the Preview PDF reader which ships with the Mac will also execute code embedded in PDF files… I will update this post when I have further information…  UPDATE (2010-04-07 – sources tell me that the attack does not work on files opened on Macs using Preview or Adobe Reader, but I have not verified this myself)

So… if you receive a PDF file which asks for a click on a dialog box when you open it, don’t click.  Legitimate PDFs seldom require the user to take any further action to open them.

The whole Foxit issue got me thinking about the use of non supported software in corporate environments.  I would guess that most organizations assume that Adobe Reader is installed and used on their computers.  I would also guess that most corporate IT and info sec types are not aware of the existence or use in their organizations of alternative PDF readers like Foxit.  For this reason, networks and information are put at additional risk, since any warnings and patches pushed out to the user community would not protect Foxit users.  There are a few possible reactions to this problem:

• Don’t allow users to install non approved software and enforce the policy with technical means.  

• Install software on your network which inventories new apps installed by users and provides you with an alert.  In this case, you’ll have to follow up on these alerts and keep track of who has what oddball programs installed as well as keep an eye open for applicable security updates.  More work for info sec, but, hey that’s why we get the big bucks.

• Cross your fingers, rub your lucky rabbit foot and hang a horseshoe above your servers.  Otherwise known as sticking your fingers in your ears and singing “la la la.”

If you can get away with number 1, more power to you (wearing my Dick Cheney hat here) from a security overlord point of view, but when wearing your business hat, it may turn out that the ability to install new apps helps more than it harms.  That is why I am a fan of door number 2… work with your users rather than driving their bad security practices underground.  Remember… Great CSOs enable AND protect the business.