On the first of the month — also the first of the year — Dana Blankenhorn published the sensationally titled The biggest threat to open source in 2009. His thesis is simple: that, because open source software usually lacks any mechanisms for easily updating to the latest security patched version, the growing popularity of open source software will render it more vulnerable to problems than its closed source counterparts.

As a lead-in to his main point, he said:

There is no longer any doubt that hackers and malware writers are going after open source projects as they once went after Windows. Vulnerabilities are being found, discovered, created, exchanged.

There seems to be a common malady amongst opinionated tech writers — that of never quite getting it when it comes to the fundamental principles of security. A particular favorite for being ignored is that of security through obscurity. Many many moons ago, I wrote what I think is a decent treatment of the subject as it applies to open source software, Security through visibility. While it makes a pretty strong case for ignoring the bleatings of “popularity is insecurity” doomsayers, it’s really only the first step toward full understanding of all the problems with the assumption that the only thing “secure” about open source software is obscurity.

Obviously, based on his start to the article, I was already expecting very little in the way of useful information. His next statement left me even more mystified at what appeared to be a towering edifice of ignorance, however. Specifically, he said:

The best protection against vulnerabilities is to keep software updated, but most open source lacks update services. That’s one part of the Windows license that is worth paying for, and there does not seem to be an open source equivalent.

As a long-time user of open source operating systems, previously favoring Debian GNU/Linux, and subsequently moving on to FreeBSD, I was stunned to see this in writing, published for all the world to see. Was he serious? Could he really believe that?

One of the most visible wins for open source Unix-like OSes, once one has learned a fair bit about them, is the casual availability of superior software management systems. I’ve written a brief primer for effective use of APT for TechRepublic, Efficient software management with the Advanced Package Tool in Debian. I’ve also addressed the excellence of a security tool integrated with FreeBSD’s ports system, How FreeBSD makes vulnerability auditing easy: portaudit. Both of these articles illustrate some of the significant benefits of better software management systems than offered by MS Windows.

Perhaps even more relevant to Dana’s point is the fact that, on open source Unix-like OSes (but not on MS Windows), the software management system typically manages security updates for far more than just the core OS and a couple of applications created by the same vendor. Such Unix-like OSes’ software management systems tend to provide security update management for literally thousands of software packages originating outside the core OS project itself — in some cases, tens of thousands.

Then, his next statement clarified his meaning:

An exception is Firefox . . . But how many take advantage of this? And how tied is Firefox to updating for security purposes? Remember we’re talking about pushing updates, not asking users to pull them.

Suddenly, it all became clear. In Dana Blankenhorn’s mind, “open source software” refers only to the handful of popular open source applications that are regularly used on MS Windows systems. I find it interesting that the only example of an open source application he offers is an exception to his rule, however.

Where are all the legions of open source applications that don’t provide easy software updates? Whose fault is it that MS Windows doesn’t have a software management system that can help ease the process of applying security patches for these applications the way open source OSes do? Where are the examples of closed source applications that provide such update management as he describes, where the MS Windows compatible open source alternative does not — thus justifying his singling out of open source software as somehow more notably vulnerable?

Perhaps the worst part of the inaccuracies of the article is the fact that its clear assumptions (that all software worth discussing is MS Windows centric, for instance) for those of us who know better are opaque to those who do not. A manager with little or no experience of OSes outside of MS Windows may read this article and come away with the assumption that open source OSes completely lack software management systems. As a result, he or she may scupper any potential plans to deploy open source Unix-like systems in the network. So much for “the best tool for the job”; such decisions are often difficult to make well even when you aren’t hampered by wrong-headed ideas like those Dana’s article might inspire.

He does make a good point about corporate culture, though:

But until this ramps up (hopefully in a competitive market), enterprise managers have an easy way to say “no” to open source.

Regardless of how dangerous this is, the fact that managers feel it’s dangerous makes it so.

Too bad some of those managers might “feel” it’s dangerous specifically because of his own article.

I’d clarify that to say that managers feeling it’s dangerous doesn’t actually make it so — but it does make it so for all intents and purposes in the corporate environment, when it comes to technology implementation decisions. When the higher-up says “I think the closed source software offering is better, because I have these concerns about the open source software alternative,” his or her subordinate (and perhaps more technically inclined) IT worker will eventually reach a point where he or she must either make decisions limited by the manager’s fears or polish his resume. Take it from someone who knows from personal experience.

On one hand, I’m inclined to be dismayed by this common bureaucratic failure of corporate culture, and feel the urge to rail against it. After all, security is everybody’s problem; it’s not just a problem for “that guy over there”. Your problem, to a significant extent, becomes my problem when you connect to the Internet.

On the other hand, knowing something about security that others don’t provides something of a competitive advantage. Where competitors may stumble and fall, the organization with a knowledgeable IT department will remain stable and secure, and prosper where others have failed.

I guess there’s a silver lining to every cloud of disinformation.

——————————————————————————————————————-

MD5, known for years to be vulnerable, was instrumental in allowing creation of a rogue SSL certificate last month.  Although this is troublesome, it isn’t what really bothers me, even though some erroneously reported the untimely demise of SSL.  The real problem seems to be MD5’s continued use by CAs to sign certificates for years after problems were identified.

The MD5 story

In 2004, Dan Kaminsky described weaknesses in the MD5 cryptographic hash function.  He predicted future attacks against it could cause problems with digital signatures.  Kaminsky wrote,

The attacks discovered are indeed obscure. But completely theoretical? No. Even given what little data has been released – code implementing the attack isn’t even public yet – sufficient information has been released to piece together a rudimentary proof of concept tool that demonstrates, at minimum, that the selection of MD5 exposes new and potentially deeply undesirable functionality above and beyond what the one-way hash primitive specifies… 

That being said, this paper is not a “smoking gun” indictment of MD5. I’ve taken great pains to include the caveats of each vulnerability, as it is far too easy to overestimate the risks described in this paper. It is for that reason I am not saying ”today”, or ”any day now”. The title states ”someday” for a reason.  There are dots going back ten years as to the risk of MD5. Here are a few more, in the hopes that they will start to be connected.

Was there enough information available at the time to make everyone immediately jump to another hashing solution like SHA-1?  Probably not.  However, there should have been enough concern among certificate authorities (CAs) to protect one of the most valuable security tools on the Web–SSL.

Although the bigger CAs did begin using SHA-1 for their high-end certificates, those with fewer security guarantees (I guess to really need your lawyer read the fine print…) continued to be signed with MD5.

The 2008 “SSL” hack

The “someday” Kaminsky wrote about drew much, much closer last month with development and successful use of a proof-of-concept rogue certificate by security researchers Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger.  Figure 1 is a brief description of how a malicious certificate can be substituted for the real thing during purchase and acquisition.  The process is enabled largely because a majority of DNS servers are still vulnerable to redirection attacks.  For a more detailed description of how this works, see the original findings paper.

Figure 1  (http://www.win.tue.nl/hashclash/rogue-ca/#sec71)

What this means

On the surface, this “event” proves that it’s possible for an attacker to insert himself into the certificate acquisition process, resulting in wrongful authentication of visited sites.  However, SSL might not be in as much danger as originally reported.

Yes, there are many CAs still using MD5 for at least some certificate signing.  In fact, the rogue certificate used in this exploit emulated a VeriSign RapidSSL cert.  TC TrustCenter AG, RSA, and Thawte Inc. also still use the vulnerable hash function.  But there are four significant mitigating factors.

1. Most enterprise-class certificates, such as VeriSign’s Extended Validation SSL Certificates use the still secure SHA-1 hash function.
2. Certificates already issued with MD5 signatures are not at risk.  The exploit only affects new certificate acquisitions.
3. CAs are quickly moving to replace MD5 with SHA-1.  For example, VeriSign was planning to phase out MD5 by the end of January 2009.  The date was pushed up due to the December proof of concept.  On December 31, 2008, RapidSSL certificates shipped with SHA-1 digital signatures.
4. The researchers did not release the under-the-hood specifics of how the exploit was executed.

Again, these are mitigating factors.  It isn’t impossible for cybercriminals to come up with an attack on their own now that conceptual understanding of approach is public knowledge.  But SSL is not broken.  The only thing broken is a portion of the public key infrastructure (PKI) which underlies it, and the risk is manageable.

How to mitigate risk

First, fix DNS.  Organizations which haven’t ensured their DNS services are secure should do so immediately.  Second, take the plunge and filter business or home access to Web sites.  (See Free Web content filtering puts safer browsing within reach for everyone and Websense.)  This is far from perfect, but it helps users avoid known malicious sites as they appear on the radar.  Finally, check new certificates before you purchase to see if the CA might be vulnerable and to ensure their validity.  Also check SSL-secured sites you visit for the first time to ensure the cert is valid–at least for the near future.

Checking before you buy is easy.  Use a reputable CA and check the signature hash function used.  Checking other sites requires the right tool, like Site Check at Networking4All.  To test, I entered the alternate URL for Gmail, as shown in Figure 2.

Figure 2

Since the certificate is actually for mail.google.com, this is a good way to see if Site Check accurately tags the cert as invalid.  It did, as shown in Figure 3.  Although this is a valuable test for common certificate issues, the MD5 exploit described in this post would likely pass.  However, note that the results show the chain of trust as well as the hashing functions used.  If the certificate is signed with MD5, and the certificate was obtained after the exploit was made public, you are armed with information necessary to possibly avoid the site or take additional steps to verify authenticity.  If a business partner uses MD5 signed certificates, ’strongly encourage’ them to replace them with certificates signed with SHA-1.

Figure 3

The final word

So is SSL broken?  Not really.  The problems with MD5 are certainly cause for concern, but the risk is not high enough to mourn the demise of secure sockets, especially if simple steps are taken to avoid high-risk behavior.  Further, the problem is not with SSL itself.

Yes, MD5 is broken.  Of that there is no doubt.  So with years of advanced warning, were the CAs negligent for continuing to use MD5?  Was the risk high enough to make the shift before release of a successful proof-of-concept hack?  What do you think?

 Loading …

 Loading …

——————————————————————————————————————-

Chris Wolf, an attorney and head of the Proskauer Rose (Washington, D.C.) law firm’s privacy and security group, stated in a recent interview that breach notifications should be delayed until all the facts are in about what was lost and who was affected.  While this might be a good legal position, I’m not sure this view is shared by victims of a breach, privacy advocates, or me if the delay reaches across weeks or months.

The topic of the discussion with Wolf was the potential for a U.S. Federal breach notification law and the impact on business of similar state regulations.  The interview, which appeared in the December/January 2009 issue of CSO, attributes the following to Wolf:

Many of the state regulators who are focusing on [timely notification] are focused on the chronological amount of time between breach and notice.  I’m not sure they have a sufficient amount of knowledge of what is involved when a company needs to get its arms wrapped around a breach.  Before a company can notify, they need to find out who has been affected and what has been exposed.  It is better to have an accurate notice than to cry wolf.

Source: Federal Notification Law Unlikely, CSO, December/January 2009, p. 36.

Let’s analyze this statement.  First, Wolf infers that state regulators might be too intent on mandating time constraints, time constraints with no basis in the realities faced by business.  This might be true.  However, this is a matter of risk.  The risk the regulators assess is that faced by potential victims of a breach.  As the period between breach and notification increases, so does potential damage.  It isn’t about how long it takes a business to get its act together–and it shouldn’t be.  It’s about responding in a way that limits the ability of criminals to leverage stolen data, resulting in financial or other injury to victims. 

Wolf also asserts that organizations need time to understand the breach–who was affected and what was taken–before they release a notification.  I don’t disagree with this.  However, making these decisions quickly, within regulatory constraints focused on risk mitigation, is the role of a well-designed and practiced incident response process. 

Any organization which collects and keeps PII or ePHI is responsible for protecting it and reacting quickly to mitigate risk due to its loss.  Each organization must know where PII and ePHI is stored, use reasonable and appropriate controls to prevent unauthorized access, use intrusion or extrusion monitoring to detect a breach, and document a quick breach response.  I define “quick” as hours, not weeks or months. 

Organizations unable or unwilling to provide the controls necessary to react immediately to protect customer, employee, or patient information should reconsider keeping it in the first place. 

Wolf closes the interview with a warning:

Businesses need to be ready in advance of a breach to know what needs to be done… This is necessary to avoid the regulator scrutiny that has occurred in past cases.  If I were to give one piece of advice to businesses, it’s get ready in advance for a breach because it is more than likely it’s going to happen to you.

With this statement, I strongly agree.

For more information about preparing for and responding to a breach, see Breach of Information at the National Conference of State Legislatures Web site.

Tell us what you think

 Loading …

————————————————————————————————

WPA packet injection now possible

German Security researcher Erik Tews and co-researcher Martin Beck have found a way to break the Temporal Key Integrity Protocol (TKIP) key used by the Wi-Fi Protected Access (WPA) encryption standard.  This is done by tricking a WPA to send out a large amount of data, and then mathematically cracking it without using a dictionary attack.  While data remains encrypted, it is possible to perform data injection into the WPA traffic between a router and a laptop.  At this moment, WPA2, which uses Advanced Encryption Scheme, remains unaffected.

You can download their paper Practical attacks against WEP and WPA (pdf), or read more details here.

Researchers eavesdrop on wired keyboards

By using an antenna and some relatively inexpensive equipment, Researchers Sylvain Pasini and Martin Vuagnoux successfully eavesdropped on wired keyboards from a distance of 20 meters.  They did this by picking up the electronic magnetic radiation emitted from depressed keys on the keyboards, which were intercepted and interpreted.  11 different wired keyboards were subjected to four different attack methods, with all keyboards succumbing to at least one of them.  Rate of picking up the keys that were pressed was slow, though the researchers seemed confident of improving it - and the range - with better equipment.

You can read more and watch the video on the researcher’s web site here.

Triangulating rogue Wi-Fi users

If you thought that using your neighbour’s insecure Wi-Fi automatically precludes you from detection, then you might be interested to know that this is no longer the case.  ThinkSECURE has released MoocherHunter, a mobile tracking software tool for “real-time on-the-fly geo-locational of wireless moochers and hackers.”

Based on trials in residential and commercial environments with multiple tenants, a trained operator with a laptop and directional antenna was able to geo-locate a wireless moocher with a geographical positional accuracy of as little as 2 meters within half an hour.  And yes, it was developed in Singapore, and is free for end-user use.

Read more about MoocherHunter here, or download the OSWA LiveCD here.

Mifare Classic RFID compromised

If you still haven’t heard by now, Mifare Classic, the RFID technology behind the Oyster Card in London, as well as by other transit operators in Boston and the Netherlands, have been compromised.  Mifare Classic has proven secure in the past due to the use of an on-board ASIC which is used to implement a challenge/response protocol to protect against cloning.  This has now been successfully cracked.

Other than opening the transit systems based on this technology to fare cheats, the other concern is that Mifare Classic is also widely used as building access passes, with another billion cards distributed worldwide.  Essentially, an employee can have their cards cloned by bumping into that person with a portable card reader.  This can happen without the victim knowing, and has no known countermeasures at the technical level.

NXP Semiconductors has quickly announced a new version of the Mifare chip called the Mifare Plus, which features 128-bit AES encryption and is which is currently immune to cloning.  Unfortunately, older readers are not compatible to the Mifare Plus, and it remains to be seen how long institutions will take to upgrade to the new standard.

You can read more about this here and here.

A layered approach to security is a good idea. There’s little to quibble about there. The specific needs of an effective layered security strategy may be open to debate, however. The truth is that those needs vary from case to case, and may vary wildly in some cases.

A common mistake of those who do not employ an effective layered security strategy, though, is to focus on perimeter security. It’s increasingly popular amongst the avant-garde of security professionals to claim there is no perimeter, but the truth is more prosaic: there’s a perimeter, but there’s a lot more to security than the perimeter. Much of the philosophy of layered security is a response to the need to address more than mere perimeter security.

Firewalls are not enough, these days (if they ever were), to effectively protect the data moving around inside your network. Even ignoring for a moment the fact that an Internet-connected network would never need to be connected to the Internet if data did not cross the perimeter, and still probably need securing even outside the perimeter at times, the view that one’s network is some kind of atomic, indivisible resource that needs all security measures focused on protecting it as a whole is mistaken. The various parts and operations of your network all need their own individual protection measures too — even protection from each other.

A failure in penetration protection at the perimeter of a network is never an impossibility. Local wardrivers and other wifi security crackers, exotic threats such as van Eck phreakers (at least in theory), and unscrupulous or incautious employees with physical access can all introduce threats to the network, bypassing common perimeter defenses entirely. It is for this reason that one should employ a layered network security strategy — to design one’s security policy not only to attempt to keep the threats out, but also to provide the means to respond effectively to breaches, and to keep sensitive data and resources as well-protected as possible even if security has in some manner been compromised.

One of the most common failures in this regard is that of undertaking significant effort and expense to secure traffic outside the perimeter with encryption and authentication measures while assuming that data communications inside the perimeter are necessarily safe. Protective measures for your IT resources should be implemented even for operations that take place entirely within a nominally trusted network. In other words, even a supposedly trusted network should be regarded as untrusted — just, perhaps, less severely untrusted than other networks, such as the Internet itself. Such measures should include, but not be limited to, the following:

• Systems internal to your network should be protected as though they were connected to public wireless network with Internet access and no perimeter security measures at all, such as many coffee shop networks. Each should have its own firewall running, unnecessary services turned off, and necessary services configured to minimize vulnerability — even if you think nobody will be able to even attempt to crack security from outside the local network.
• Secure user authentication should always be used when accessing resources across the network. If some malicious security cracker manages to gain a foothold on a system within your network — perhaps some desktop system that uses a Web browser, email, and IM client to talk to the outside world — he or she might then be able to use it to stage attacks against more other systems. If secure authentication is necessary to access your mail server, it won’t be easy to turn it into a virus delivery platform; if for your file server, it won’t be as easily ransacked; if for your firewall, it won’t be as easily reconfigured to allow further access to the network from the Internet. Part of secure authentication, of course, is ensuring that only very well secured systems are allowed as the source of remote access.
• Security assurance and disaster recovery resources on your network, such as integrity auditing and backup servers, should be as impervious to attacks launched from local systems as threats originating outside the network perimeter. Logging servers should listen, but not broadcast; backup servers should never allow anything copied from another system to be executed on them; integrity auditing servers should not be subject to any control by the systems whose integrity they’re meant to audit.
• Communications across the internal network should always be encrypted. If you have a consumer grade router/firewall appliance with a Web interface, it should be accessed via an HTTPS encrypted connection. If you must access the shell on a Unix system, use OpenSSH rather than RSH or other unencrypted tools. Network filesystem shares should be accessed using tools such as SSHFS that encrypt the entire session using strong, peer reviewed cryptographic algorithms, rather than unencrypted, poorly encrypted, or only partly encrypted NFS or SMB/CIFS shares.

Just as a boxer may wear a mouth guard to protect his teeth from each other, and not merely rely out outward defenses against an opponent’s punches, you should secure everything within your network against the rest of your network to protect it in the event your trust in your own IT resources doesn’t save you from unexpected threats that may penetrate or circumvent your perimeter security.

——————————————————————————————————————-

This is the story of an actual break-in, the physical security weaknesses discovered in the post break-in assessment, and what was done to strengthen protection of physical, financial, and information assets, and a computer containing employee information.  As always, the names of both people and places (as well as a few facts) have been changed to protect the neglig… uh… the innocent.

The morning after Christmas Joe Kim, the owner of the Pavilion restaurant and a family friend, called to inform me someone had broken through the back door and stolen some money from the register.  Joe asked that I come over and take a look.  He wanted my help to help secure the building and to strengthen the Pavilion’s physical security.

When I arrived, Joe took me to the point of entry.  The back steel security door had been pried open.  Figure 1 shows a similar door at the back of the unit next to the Pavilion.

 
Figure 1

A crowbar, or like instrument, had been placed in the opening between the door and the door jamb.  The door was then pried/bent enough to break the panic bar latch.  An example panic bar is shown in Figure 2.

 
Figure 2

I walked through the damaged door and asked if the alarm had sounded when the intruder opened the door.  “What alarm?” Joe answered.  He then led me to the register from which the money had been removed. 

The “register” was a simple cash drawer connected to a point-of-sale terminal.  There was no apparent damage.  When I asked about this, Joe pointed to the register key in the drawer lock. 

“We always leave the key in the drawer so we don’t lose it,” he said.  “Besides, we only keep loose change in there after closing.  They got less than $20.”

Since my area of expertise is actually protecting information and information infrastructure, I asked Joe if the server was stolen or damaged.  He took me to the office.  The computer was still under the desk and there hadn’t been any attempts to log in.  “You must have had the door to the office locked,” I commented. 

Joe shook his head.  “No, we always leave it unlocked.  We must’ve just been lucky.” 

“So were the employees,” I thought, since I know the computer contains their payroll information (i.e., names, addresses, dates of birth, social security numbers, etc.).

After the tour, I sat with Joe and made of a list of things he needed to do to deter entry, limit an intruder’s time on site, and increase the difficulty in reaching and accessing critical or sensitive systems.  The list was simple.

1. Fix the lock and prevent easy access by crowbar.  Local ordinance prohibits installation of a bolt lock on any door marked as an emergency exit.  So the best way to hinder attempts to pry a door open is with a steel plate covering the opening between the door and the lock-side jamb, as shown in Figure 3.

   

   Figure 3

2.  This isn’t perfect, but it should act as a sufficient deterrent for someone wanting quick entry by applying a crowbar to the latch.  And it fits within Joe’s budget.  A quick call to a locksmith, and the plate was installed and the latch repaired within two hours.

3. Install an alarm system.  No physical structure is entirely secure against a determined intruder, especially a business like the Pavilion with more glass than concrete making up its outside walls.  So someone—preferably the police—should be alerted when an intruder gains access.  Further, a loud audible alarm will often cause an intruder to leave immediately, or at least spend far less time on the premises.  I advised Joe not to spend thousands on alarm installation.  For less than $500, he can install alarms on his doors and motion sensors in critical locations within the restaurant.  Monthly monitoring costs are less than $50. 

4. Lock the office door.  The server has a very strong password, and it would take some time to remove it from its home under the desk.  But cracking passwords or disconnecting the server are doable if an intruder is given enough time.  An alarm system and a locked office door should provide reasonable and appropriate protection against a successful hack via physical access.  (In any case, I plan to discuss encryption with Joe on my next visit.)

5. Leave the cash drawer open after business hours.  Joe removes all cash from the premises when he closes for the day.  Leaving the drawer open prevents theft of the drawer or damage when trying to open it onsite.   This is exactly what happened at the pizza shop at the other end of the plaza. They were broken into the same day as the Pavilion.  The intruders stole a locked safe.  Little did they know there was no money in it, but they still took it so it could be opened in a less risky environment.  Unlike the safe, however, inability to use the cash drawer would hinder restaurant operations.  So, since there is nothing of any real value in the drawer, leave it open.  I also suggested he post a notice on the back door that no cash is kept on the premises after closing… and put the cash drawer key on his key ring. 

Joe isn’t the only small business owner with security issues.  Limited budget and ignorance of simple security techniques result in easy pickings for thieves and vandals.  As shown in this post, it doesn’t take much to provide just enough security to protect business operations and employee data.

————————————————————————————————

CEO of Trend Micro thinks AV industry sucks

I would like to think that Eva Chen, co-founder of Trend Micro some 20 years ago is not just hard-hitting with her words, but shrewd with her ability to pitch for the headlines.

She was quoted as saying:

“For me for the last three years I’ve been feeling that the anti-virus industry sucks. If you have 5.5 million new viruses out there how can you claim this industry is doing the right job?”

Where Mac aficionados will say the answer is obvious, another solution that has become far less clunky than antivirus software in recent years would probably be whitelisting.  Then again, the death of the traditional antivirus approach is not that new a concept either, but the result of mounting frustration over the failure of the current approach.

Of course, Chen went on to conveniently punt the company’s up-coming “Smart Protection Network,” a technology that uses “pattern comparison” by leveraging the Internet cloud to solve all the problems related to nasty viruses.  And while it does seem to make sense, the question has to be why we are still reliant at this point on definition matching technology?

Whatever the case, it’s certainly refreshing to have a leading antivirus vendor admit to the failings of the industry as a whole.

You can find the original TechRepublic post here.

Most spammed man in Britain receives 44,000 unwanted mails a day

You might think that you have it bad with spam.  Well, it appears that Colin Wells, a man who works as a workshop foreman at a local bus company has the dubious honor of being the most spammed man with 44,000 unwanted mails a day.

Obviously a piece to trumpet the services of ClearMyMail, a British anti-spam service company, it nevertheless boggles the mind how someone can receive quite so many unwanted emails.  Well claims that before ClearMyMail came along, he takes at least two hours a day to delete all the spam from his inbox.

We’re take that with a big tablespoon of salt, though a poll of TechRepublic members does reveal that about 35 percent of those polled receives more than 20 spam mails a day - which is no trivial figure either.

You can find the original TechRepublic post here.

Another Webcam voyeur arrested

Yet another peeping tom got thrown into jail for hijacking a teenage girl’s webcam to spy on her.  Essentially, the so-called hacker used a Trojan horse virus to remotely access the webcam by selective targeting with infected emails.  Once he had a crèche of illicit photos, the man went on to threaten the teenage girl with blackmail unless she posed indecently for him, at which stage the hapless girl reported on him.

I think of particular concern would be the built-in Webcams that can be found on literally every new laptops sold on the market today.  From the evidence so far, it seems that borderline computer literate users can fail to notice anything amiss should the camera come on.  Perhaps pasting a opaque scotch tape across it might work better for these users.

I originally referenced the case on TechRepublic here; you can find the original news report here.

Long-running Internet porn pop-up case finally comes to an end

Four long years in the running, the case against former Connecticut schoolteacher Julie Amero finally closed a couple of weeks ago when she accepted a plea agreement.  Amero will pay a US$100 charge as well as have her teaching credentials revoked in return for State prosecutors dropping four felony charges against her.

What happened was as follows.  Excerpt from Times Online:

She [Amero] returned from the lavatory to find two students viewing a hairstyle site.  Shortly afterwards, she says, pornographic advertisements flooded the screen. She says she tried to click them off, but they kept popping up, and the barrage lasted all day. She tried to stop the students looking at the screen, but several saw sexually explicit photographs. It was school policy not to turn off computers.

I think the general TechRepublic members are sympathetic towards the situation, though some are suspicious that not all the facts were clearly reported in the press.

One line of thought is that legal costs can be so crippling that the life of an innocent person can be destroyed mounting a proper defence.  What is your take on this?

You can find the original TechRepublic post here.

————————————————————————————————

Microsoft confirms SQL Server bug

Microsoft has confirmed that it has been working to fix a critical vulnerability in SQL Server since April, as alleged by SEC Consult, the organization that uncovered the bug.  We first reported about this issue in our Security News Roundup two weeks ago, just before the issue hit the mainstream press due to the highly critical nature of this vulnerability.

A successful attacker will be able to remotely control the database and the underlying server, which will result in a leakage of confidential data and disruptions in critical MS SQL driven applications, which exist mainly in the enterprise space.  As such, database administrators are urged to immediately review available work-around solutions and implement them as soon as possible, in spite of the holiday season.

“We expect that Microsoft is currently working on patch and will release it out of band,” said Wolfgang Kandek, CTO of Qualys, underlining the severely of the problem.  However, patch deployment is likely to be slower than the recent Internet Explorer vulnerability.  Kandek explains that the reason is because Microsoft SQL Server is part of the core server infrastructure of many enterprise companies.  As such, “[SQL Server] is subject to lengthy patch and testing cycles and before any such fix can be deployed.”

Check Point acquires Nokia’s security business

Check Point has agreed to acquire Nokia’s security appliance business.  Financial details were not disclosed, though Check Point did reveal that the acquisition will add some US$100 million to the company’s revenues in 2009, and that the transaction terms will be in cash.  The two companies have been working together for over a decade, with more than 220,000 Nokia appliances installed with over 23,000 customers worldwide.

There is no mention of how staff from the new division will fit together into Check Point’s organizational structure, though Chief Executive Officer Gil Shwed was reported as saying at a press conference, “I hope that we will also find a way to integrate most of the Nokia workforce into the company.”

The reason behind this Nokia selling its security appliance business is not known; though judging by recent belt-tightening measures at Nokia, this could well be part of overall restructuring designed to improve its group returns.

Keyloggers used to harvest banking credentials

A team of researchers have published a case study that focuses on keyloggers and their use to harvest banking-related user names and passwords.  Using honeynets, the team observed over 70 different data-stealing malware and found over 33 GB of log files in “dropzones.”

Excerpt from heise Security UK:

The log files contained personal information on more than 170,000 victims, including passwords, PINs, user names, and so on. They also contained information, including PINs, on over 10,000 bank accounts, over 140,000 email passwords and the access details of nearly 80,000 members of social networking sites such as Facebook and Hi5.

Of course, the use of two factor authentication such as by some UK banks would have rendered a lot of these data useless.  Places such as Singapore have also mandated all banks to offer two-factor authentication for on-line banking.  Of course, a common habit of most people using the same passwords for various accounts will probably not help.

The data has since been handed to Australian CERT, which will pass the information on to the relevant banks and institutions so as to inform the victims and remedy the situation.  You can read the full report titled Learning more about the Underground Economy: A case-study of Keyloggers and Dropzones. (pdf)

Any comments or feedback on the security news roundup this week?

——————————————————————————————————————-

Server virtualization is growing as a critical component of system and data center design.  However, there are many who claim it adds additional vulnerabilities to already complex security environments.  So is this true?  Is virtualization increasing organizational risk?  And if it is, is the value gained worth a little risk acceptance?

Why virtualize?

When microcomputer-based servers began to supplant mainframes and mini-computers as core business information processing systems, microcomputer technology was far behind its current state.  Placing a single solution on each server was recommended by companies like Microsoft to ensure expected performance and reduce the risk of incompatibilities.  The approach worked, but it created data centers with potentially hundreds of single-purpose servers.

As the number of servers increased, so did management headaches.  Further, improvements in hardware technology, coupled with end-of-life server replacements, resulted in data centers full of servers with underused resources.  The time was right for virtualization.

Virtualization started out slowly, feeling its way through the information architecture landscape.  Over time, it became the core of many server implementation strategies.  According to William Hau and Rudolph Araujo of Foundstone:

A recent [virtualization] industry conference drew more than 10,000 attendees, putting virtualization in the same league of technologies as Java and Linux.

[…]

Server and desktop virtualization has moved from being a buzzword to becoming a reality that will define the way organizations leverage information technology.

Source: Virtualization and Risk – Key Security Considerations for your Enterprise Architecture

Virtualization has taken hold because it helps organization address many day-to-day issues associated with server technology, including:

• Hardware pooling.  Multiple virtual servers can share a single hardware platform’s resources, maximizing an organization’s investment.
• Underlying hardware is not an issue.  Virtual environments abstract hardware from guest virtual server environments.  Vendors and business users of applications and operating systems have less to worry about when trying to deploy a solution on a variety of hardware platforms.
• Secure logging.  Hypervisors, or virtual machine managers (VMM), log events from beneath guest environments.  So even if logs in the virtual machine are modified or destroyed, the VMM logs are still available for security or troubleshooting activities.
• Server implementation via standard images.  Once a virtual server is created, with appropriate baseline security settings, patches applied, and other environment-specific settings, an organization can save an image.  The image can be used for recovery or to create other servers of the same type (i.e., email, database, file and print, etc.).
• Quick Recovery from business continuity events.  If hardware fails or a virtual server is somehow corrupted, rebuilding the environment from a stored virtual image is a quick way to restore services.  And because the hardware is abstracted from the virtual machine, a critical server can be restored on a hardware platform different from the normal production system, without having to worry about incompatibilities.
• Security testing.  Building baselines for both servers and network behavior is a big part of security management.  Testing configurations with virtual servers is a good way to quickly throw up a server, test, and tear it down once testing is complete.

What are the risks of virtualization?

Like any new technology, virtualization requires a shift in the way we manage our information infrastructure.  Three potential risks IT managers must address include proliferation, shifting network baselines, and rollback vulnerabilities.

The ease with which engineers can deploy virtual servers is both an advantage and a disadvantage.  Traditional server deployment required purchase or repurposing of an actual piece of hardware.  It was easy to control this process with standard change management processes.  Virtualization changes the game.

Today, engineers can create virtual servers on any virtualized hardware platform simply by deploying the relevant image.  They can do this without the checks and balances mandated by spending more money.  This capability can actually result in more servers to manage, with a greater number falling under the radar of security analysts, auditors, etc.

When configuring security or performance monitoring solutions, a stable network baseline is assumed.  However, the ability to build-tear down-build virtual servers at will can work havoc upon baselines.  This includes already established baselines, causing unreliable monitoring results.

Finally, using virtual images to roll back virtual servers because of problems with an update, upgrade, or patch can move a server back in time.  A time before critical security patches were applied, for example. 

All three of these risks are caused by changes in how server deployment is managed.  Adjusting administrative controls (i.e., change management policies and processes) to include special virtualization considerations is the first step.  Organizations must follow policy changes with modifications to compliance oversight processes.

Now that we’ve looked at some common administrative vulnerabilities, let’s move to attacks against virtual environments.

Proof of concept exploits, like Blue Pill, SubVirt, and Xensploit, have demonstrated unique vulnerabilities related to VMMs.  However, no known attack has occurred.  Further, anti-malware vendors have significantly improved their products’ ability to detect these types of infections.  (See McAfee’s Total Protection for Virtualization solution.)  The bottom line?  Use common sense and knowledge of virtualization security issues to design reasonable and appropriate virtual server controls.  Although the technology might be new, the general approach for protecting it hasn’t changed.

The final word

So is virtualization worth the risk?  Absolutely.  The business value gained from properly managed virtualization far exceeds any real or perceived risk.  More specifically, the additional risk is minimal when the technology is properly managed, while improvements to business continuity and ROI are significant.  So go forth and virtualize.

Tell us what you think

 Loading …

 Loading …

In recent years, the holidays have seen drop-offs in the volume of spam and virus traffic on the Internet. The reasons aren’t proven, but I suspect it’s mostly because a lot of poorly secured home computers that have been infected by malware without their owners’ knowledge are turned off while they leave town. As a result, legions of MS Windows systems absorbed into botnets and otherwise turned into platforms for automated security cracking drop off the Internet.

On the other hand, enterprise networks and other high-value targets may be more at risk than usual. Not only do many of them let most of their network administration staff members take vacation time, often letting all the most senior IT employees go incommunicado for a week or two. This leaves a network more vulnerable than usual, and malicious security crackers who target such organizations probably know it.

The following last-minute precautions should probably be on your To Do list for just before leaving the office this holiday:

1. Make sure your backups — both on-site and off-site — are current, and test them to make sure you can actually restore from them. Remember: if it hasn’t been tested, it’s not a good backup.
2. Intrusion detection and alerts (sent to someone with the ability and authority to do something about it who will monitor alerts during the holidays) should be automated as much as reasonably possible.
3. Ensure that disaster recovery procedures are thoroughly documented for whoever will be around during the holiday break.
4. Go over the automated security measures you have in place to determine whether they can be improved, such as firewall rulesets, VPN authentication procedures, and protection for your integrity auditing snapshots. What time is better for a review and improvement plan than the weeks before (almost) everyone will be gone for a while, and your automated security measures will have to mostly fend for themselves?
5. Last but not least, treat your employees well. If possible, give everyone some time off (without being on-call) that fits his or her needs — and if not, give whoever doesn’t get the time off some extra compensation to make up for it. It’s not just about being a friendly boss; a frustrated employee may not do as good a job of ensuring the security and reliability of your IT resources.

On a personal note, I received a box of swag and a card from the editorial staff at TechRepublic — including a TR desk flag, a pen, a rubber ball with lights in it that flash when it bounces, and my second TechRepublic coffee mug. Those mugs are some of the best coffee mugs I’ve ever seen, by the way. Now that I have one each for me and my “Significant Other”, I just need one more to hold pens on my desk. Maybe I’ll get it next year.

This is my public thanks, and my wishes for a happy holiday, to everyone who signed the card — and to all my readers. Barring catastrophe on vacation, I’ll see you next week.