[Q] Detecting virtualisation

I think that it it not practically possible to detect reliably, using a piece of code, that the code is running inside a virtual machine.


But apparently there are ways to make a good guess – for example, by looking at the devices that are typical for certain VM environment (like S3 Trio64 video card in MS VPC), or virtual machine extensions installed in the guest OS.


This time I have two questions:


  1. Any other ways to detect that the code is running in a VM?
  2. Why malware tries to do that? It does, according to Sandi Hardmeier, a great spyware fighter and a MVP.
There’s a reason I’m asking. I believe that VM technology will help a lot bypassing an endpoint security system

What the hack!

Recently I came across a Web site that sells software for predicting American Idol results: DialIdol.com


The idea is really neat: to automate diaing to the voting phone numbers, measure rate of “busy” signal, and make prediction based on that. It works with many TV shows – including Canadian Idol. And it’s in true spirit of hacking – commodity technology is used to implement a brilliant heuristic with no harm done.


Well, there is a potential for harm in it. If the software goes out of control (as in: becomes hugely popular), it may pose a denial of service attack on the TV shows. Just like the Morris worm brought down the Internet.


Can the Idol show results be hacked? Obviously you can spoof your caller ID and make a million calls supporting your favourite talent. But you have to pay for the calls, which limits the impact – and avoiding the payment is a crime. Besides, even if you succeed, few will notice, as talents in question tend to be… insignificant.

This is real security

Zbigniew Brzezinski, a prominent political scientist, recently wrote an interesting article in Washington Post – Terrorized by ‘War on Terror’ (How a Three-Word Mantra Has Undermined America). It’s an analysis of the recent change in American mentality and a worthwhile reading. But there’s something that Dr. Brzezinski gets just wrong:


Just last week, here in Washington, on my way to visit a journalistic office, I had to pass through one of the absurd “security checks” that have proliferated in almost all the privately owned office buildings in this capital — and in New York City. A uniformed guard required me to fill out a form, show an I.D. and in this case explain in writing the purpose of my visit. Would a visiting terrorist indicate in writing that the purpose is “to blow up the building”? Would the guard be able to arrest such a self-confessing, would-be suicide bomber? To make matters more absurd, large department stores, with their crowds of shoppers, do not have any comparable procedures. Nor do concert halls or movie theaters. Yet such “security” procedures have become routine, wasting hundreds of millions of dollars and further contributing to a siege mentality. 


An apparent failure to apply Occam’s razor. The war on terror isn’t the reason for screening visitors to the office buildings. It’s a layer of physical security that exists to protect private property. It makes computer and office equipment theft, a universal problem in such environments, harder. Therefore the checks aren’t all absurd.


And producing an ID isn’t necessary.  Such requirements can be (and sometimes should be) successfully challenged. Here’s How To Fly Without ID. That works. Similarly, if you’re invited to a meeting, you don’t have to prove your right (or permission) to attend. That’s not like crossing border of a foreign country.


 Don’t confuse real security for stupid security. There is a fine line between the two.

VoIP threats are seriously overrated

For over a hundred years, the public switched telephone network (PSTN) has gained reputation of stable and secure service. Even though it’s neither: it is indeed very hard to bring down a whole telco network, but local outages are not unseen; and wiretapping is somewhat trivial attack – but financial institutions bravely offer phone banking without any additional logon protection. Cordless and mobile phones took PSTN security paradigm to radio spectrum.


Enter Voice over IP. All of a sudden, VoIP Is Scary. We have VoIP vulnerability scanners and SIP firewalls. Consultants and press endlessly warn us about VoIP threats and risks. Some bits are just lovely:



We will also start to see more and more VoIP specific attacks, particularly aimed at the enterprise. There is more and more scrutiny of VoIP systems and attackers will find more issues that are unique to VoIP and the systems that enable it. 



This is one of VoIP security trends for this year, according to Mark Collier, a VoIP security blogger and speaker. I can’t help noticing that VoIP can be really replaced with any relatively new but popular technology (XML Web services, AJAX, peer-to-peer networks), and it still going to be a trend for this year. Hackers, you know.  Reminds me of the Cisco’s security CTO moronic escapade about Vista.


Someone needs a reality check: VoIP still offers a telephone service. And you shouldn’t expect more than PSTN security levels
– unless you intend to create closed, strictly controlled network. One
may argue – telephone switches are now using commodity hardware and
operating systems, so risk of attack is higher. I’d say – by replacing security through obscurity with commodity system security, we have good chances of increasing overall security. Anyone who thinks that proprietary systems are safer can be disillusioned by reading Phrack and 2600. So don’t worry too much – VoIP isn’t scary after all.

SPF and Sender ID won’t help fighting email abuse

Email abuse – spam and phishing – is a big problem. There are different methods of fighting those. SPF and Sender ID propose standard of authenticating emails using DNS records: owners of certain email domain will publish information about legitimate email servers for that domain, and recipients (that support SPF/Sender ID) will check that information and mark/reject emails that come from wrong source. For example, if IP address of email server that sends emails for example.com is 10.0.0.25, then there will be the following record in the example.com DNS zone:

example.com.    IN    TXT “v=spf1 ip4:10.0.0.25 -all”

The recipient will check if an email that claims being sent by someone@example.com has originated from 10.0.0.25, and will reject if it hasn’t. That is overly simplified overview, but gives an idea.

Sender ID will fail. There are several reasons for that:


  • It is not clear what is real difference between SPF and Sender ID. Both claim they implement RFC 4406, an experimental Internet standard for email authentication, and its sister RFCs. However, the SPF supporters are trying to distance themselves from Sender ID (read: Microsoft) – without much success (see for yourself), and resulting in added confusion;
  • We cannot detect if certian recipient supports Sender ID or not. Because of that, there is no credible measure of Sender ID adoption or efficiency, which results in a worse case of catch 22: people are waiting on other people to adopt the standard, yet they don’t know how’s that going;
  • Spammers don’t need to spoof source email address. That may add credibility but ultimately spam relies on the “From:” field and recklessness of the users.
There will be more issues – from operational (“Why some of my
emails aregetting lost?”) to conceptual: what is the right way to align
identity with IP address and DNS space? In some ways, DNS is better
than PKI, and definitely can help a lot. For example,(I’d love to see
public keys published in DNS, for example. But SPF and Sender ID attack
the problem of email abuse from a wrong angle. Meanwhile, my desktop
spam filter – SpamBayes – is so accurate that I don’t need and assistance from SPF. I think I know what’s the answer to spam issues.

Update on SSL VPN standards

I recently wrote that adopting PPP over SSL as common standard would be the best apporoach to standardasing SSL VPN. I must have been living on Mars: no other than Microsoft is already putting effort right into that!


They call it SSTP – the Secure Socket Tunneling Protocol. Microsoft RRAS team blogs quite a bit about it, and the beta is coming soon. The implementation is coming in Vista SP1 and Longhorn Server. I guess Microsoft will make it a standard in the Forefront Edge security products (next versions of ISA Server and the IAG) too. They should backport the protocol to Windows 2003 and XP. Microsoft won’t implement the protocol on Linux and MacOS, but that should be rather trivial; what can delay the implementation is closed beta.


I’ll look into testing SSTP ASAP.

Forbes on public Wi-Fi: You Get What You Pay For

Forbes, a respectable business magazine, writes about wireless security in the issue of 26 March 2007:


Computer security firm Authentium in Palm Beach Gardens, Fla. warns about an emerging Wi-Fi fraud aimed at air passengers. What road warriors sitting in a departure lounge think is a free authorized Internet connection turns out to be an “ad hoc” network broadcasting from the laptop of a scamster sitting nearby. Besides collecting passwords and credit card numbers, the crook might even install software that will later forward other private data. One tip-off: The wireless connection window the unwary traveler often sees labels the tainted free site a “computer-to-computer network”.


Threats from rogue wireless access points aren’t new – I wrote about disabling Windows firewall and exploiting Intranet zone using those a while ago. However, this Forbes article highlights two important problems with communicating technology issues to the businesspeople: wrong assessment and wrong advisory. I am under strong impression that by using executive summary language, consultancies, research companies and the press fail communicating real issues to the decision makers. That’s because they often those translating the original information into executive summaries and press releases, often are saying what their audience want them to say – and without much understanding of the information in question. And if quality of the original research is substandard (which I think is the case with Authentium’s Wi-Fi alert), the things only get worse.


Another evidence – IDG’s PC World’s take on the same Wi-Fi issue:


The next time you’re at an airport looking for a wireless hot spot, and you see one called “Free Wi-Fi” or a similar name, beware — you may end up being victimized by the latest hot-spot scam hitting airports across the country.

You could end up being the target of a “man in the middle” attack, in which a hacker is able to steal the information you send over the Internet, including usernames and passwords. And you could also have your files and identity stolen, end up with a spyware-infested PC and have your PC turned into a spam-spewing zombie. The attack could even leave your laptop open to hackers every time you turn it on, by allowing anyone to connect to it without your knowledge.

If you’re a Windows Vista user, you’re especially susceptible to this attack because of the difficulty in identifying it when using Vista…

The problem is that it’s not really a hot spot. Instead, it’s an ad hoc, peer-to-peer network, possibly set up as a trap by someone with a laptop nearby. You can use the Internet, because the attacker has set up his PC to let you browse the Internet via his connection. But because you’re using his connection, all your traffic goes through his PC, so he can see everything you do online, including all the usernames and passwords you enter for financial and other Web sites.

In addition, because you’ve directly connected to the attack PC on a peer-to-peer basis, if you’ve set up your PC to allow file sharing, the attacker can have complete run of your PC, stealing files and data and planting malware on it.


Such a pile of rubbish – as usually, with a twist of Vista-bashing.


Now, let’s analyse:


  • Positioning the rogue AP attack as happening mostly in airports is wrong. We get those rogue access points everywhere now, the last one I saw in the lobby of Westin hotel in Seattle. Municipal Wi-Fi projects will set expectation for wireless service being available not just in select spots, but in entire business districts;
  • Name of the service/access point, or the fact that the service is free, is irrelevant. Title of the article in Forbes – You Get What You Pay For – falsely attributes the attack to free services. In fact, paying customers of T-Mobile access points (found in Starbucks all over the States – I’m using one in SFO airport right now), and other commercial operators, are perfectly susceptible to the attack;
  • It’s not only computer-to-computer networks that may exploit unsuspecting users – access points are equally dangerous;
  • There is no “free authorized Internet connection” that is mentioned by Forbes. The word “authorized” doesn’t make sense here.

Keeping your system locked down, and using SSL or VPN for sending credentials and accessing private information will make the man-in-the-middle attack much harder if possible at all – and Vista does help here. I challenge black and white hats of the world to compromise my laptop using a rogue wireless connection. I’m afraid, fixing communications around information security issues will be at least as difficult.

Architecting enterprise for federated identity

InfoCard is the way to go. The concept is very well engineered. It is commonly accepted by various influentials of the IT industry, and some other industries (think of showbiz); it has a number of open-source implementations, as well as Microsoft one (known as Windows CardSpace); and Kim Cameron is a legend. The missing layer of the Internet – the identity – is now found.


So where are the adopters?


Today, there aren’t any of importance (measured by monetary value). The reason is the enterprises, and their ways of architecting their systems. There are two issues – actually, two sides of the same problem:


  • Enterprises are designing their identity management systems and applications assuming they will be in full control of the client identity; and
  • Application service providers are not ready to accept identity assertions issued by other parties – instead, they issue their own, sometimes providing limited delegation.

When talking about the application service providers (commonly referred to as just ASPs), I don’t mean it in the pure dot-com sense. Taking into account various B2B scenarios, there are much more ASPs than most of you think – in reality, most enterprises provide access to their applications to other parties.


And we have a problem right there. If I’m an organisation that is using a 3rd-party application for my staff and customers, I still need to be in control of their access to the application. If I give access to a 3rd-party, I want a way that allows that party to manage their access the way they do that, and I don’t want to carry the burden of co-managing and supporting access control for other organisations. InfoCard solves the problem. Enterprise applications and identity management systems should be designed for the Identity Metasystem.


They aren’t yet. Enterprise architects must adopt the new paradigm, ditch few utopian concepts (i.e., single customer view) in process, and actively confront empire building and control freakdom that plague enterprises today. The outcome is worth it. Think of simplified B2B relationships and acquisitions. Think of new ways of doing outsourcing.


Support from big names is needed. Big business looks at Oracle and SAP to make the first step and make their products (and, not less important, hosted solution offerings) compatible with InfoCard. Microsoft has to walk the talk and start offering support in the server and business software (I’ll be looking at the Intelligent Application Gateway and Hosted Messaging and Collaboration and CRM solutions). And those offering identity management solutions – Microsoft, IBM, Sun, BMC – should also provide support.


But for now we have a catch 22 situation – everybody’s waiting for everybody else. Well, Microsoft is in front again, but that’s clearly not enough. Alternatives to the Identity Metasystem look solid – just like SNA looked good compared to TCP/IP some 25 years ago (scalable, secure and supporting QoS – yet mainframe is required). Alas, you’ll be making a mistake if your solution isn’t compatible with the Identity Metasystem today.

Why a 127-character long password is not necessarily stronger than a 4-character long password

The title of this posting comes from Marcus Murray’s blog. Marcus blogged in great detail about the NTLM issue that I’ve mentioned before. He also pointed out that I was mistaken referring to the hash in question as NTLMv2 hash – v2 applies to session security protocol but not to the hash. My bad.


Just to re-iterate the effects of possibility of using NTLM hash instead of the user name/password combination:


  • There’s no need to brute force your password – throw away your rainbow tables, you only need the hash;
  • The Great Debates: Pass Phrases vs. Passwords are over – none is good, as the weakest link is  elsewhere;
  • All those people who over years asked thousands of times how to disable NTLM and become Kerberos-only environment, had a bloody good reason; and
  • Securing the enterprise against targeted attacks suddenly becomes much harder, as we must pay special attention to pretty much all logon scenarios and make sure the environment is safe.

Now we’re in position to discuss if the NTLM issue is, well, an issue. Mark Russinovich quickly pointed out that full control over an “attack base” workstation (or server) is required in order to compromise the domain accounts, and that is the main issue. Here’s two reasons why this isn’t a good response:


  1. Trivial: in most enterprise environments, workstations are extremely easy to compromise – SOE integrity checks are basic to non-existant, and forensic capability is limited;
  2. And another one: not necessarily one should compromise a tightly controlled domain member in order to get NTLM hash – they might as well ask nicely from a Web server etc. (I will experiment with different scenarios and report back).

So Microsoft shouldn’t brush off this one as a non-issue.


I had a great discussion with Shauna Kelly, a Microsoft Word MVP, about security of NTLM enviironments (our government in particular). She asked couple of great questions. For example – are there any bad guys who are doing this? The answer is – I don’t know, and we mustn’t assume there aren’t. And – if current encryption systems are okay? Bitlocker, and Office password protection are good; EFS – it depends: EFS soft keys are a part of user profile that’s available using NTLM, thus only smart cards are good.


I’m not overreacting. Will keep posted.

The weakest link

Windows provides the best platform for security solutions. So I said.


Now, let’s imagine the perfectly secure enterprise. Everyone is using smart cards to log on to the systems – user passwords aren’t used at all. AD, Kerberos and SSL where applicable. What can go wrong?


A lot. Because backward compatibility is a big issue. For example, you are a smartcard-only Windows user. You don’t use a password – but you still have a password. Really long and random – if you get a NTLMv2 hash and try to brute force it, you are likely to come across a collision before getting the true password (pure speculation on my side). But NTLM (v2 – whatever) still exists in this ecosystem. It may be used in remote administration and service account scenarios.


Marcus Murray, a security MVP, and his colleagues of Sweden’s Truesec, came up with a spectacular technique of using NTLM hashes instead of logon credentials in NTLM-based environment (which is every Windows environment, for now). Here’s a video of the attack. Marcus is blogging – in English – about the attack as I type this.


So opportunity is there. All that is required is owning (as in: 0wn1ng, or having local system-equivalent rights) a workstation in an enterprise, and getting a privileged domain user, or a domain service account, to log on to the workstation – and then I can account of those, with all the privilege, in the entire domain.


There are ways to mitigate the risk. You can make it really hard to compromise a workstation – full disc encryption is a very good first step. You can limit the scenarios of remote logons to the workstations – using technology and process.


But the right approach would be phasing out NTLM. Mark Russinovich of Sysinternals fame, a MS Technical Fellow, told me they are working on that but couldn’t provide details. Just like we can disable LM and NTLM, we should be able to do same with NTLMv2. I guess it’s possible to create a rootkit that will do just that – but we want that coming from Microsoft. Something to do in Windows “7”. Generally, it’s a good idea to include backward compatibility as a feature. But software vendors should provide an option to turn off legacy protocols.  As long as we are in control and can to testing and plan migration, that would be the right balance.