Security researchers have discovered malware being signed with Nvidia code signing certificates days after the LAPSUS$ group leaked a trove of the company’s stolen files.

Part of the stolen files included two code signing certificates and although they’re now expired, signing malware with them will still influence Windows into loading the malware onto systems.

Windows typically rejects drivers or executables signed using expired certificates. If the certificate was issued after 29 July 2015 then it would require a timestamp - a method of using trusted certificates after expiration - but certificates issued before that date, as in the case of these two Nvidia certificates, Windows will accept them without timestamps, expired or not, said Bill Demirkapi, offensive security at Zoom.

Such certificates are used so Windows users can verify the authenticity of any given driver or application. Signing malware with a legitimate, although expired certificate means Windows will be convinced the application is genuine and has not been modified by a third party.

Among the types of malware already discovered to be signed with Nvidia’s code signing certificates are Mimikatz, Cobalt Strike beacons, and remote access trojans, according to VirusTotal searches.

"The recent Nvidia security breach involving certificate abuse is eerily like the one Opera suffered in 2013 and one that Adobe reported in 2012," said Pratik Selva, senior security engineer at Venafi. "If organisations do not properly secure the process and the infrastructure for managing code signing certificates, the likelihood of abuse, as well as the impact of any compromise, are both extremely high.

"Although the certificates have expired, Windows will still allow a driver signed by a company to be installed so that it still constitutes a risk," said Alexis Vanden Eijnde, senior security consultant at Prism Infosec. "Microsoft should soon add the certificates to their revocation list and this will prevent the malicious drivers signed by stolen certificates from being loaded into Windows."

Windows admins are advised to create custom policies in Windows Defender Application Control to filter out the approvals for specific signed certificates.

The Lapsus hacking group said last week Nvidia had until Friday 4 March 2022 to completely open source its GPU drivers across all operating systems or the complete collection of stolen files would be leaked online.

The group has provided few updates since the deadline has passed apart from announcing its second major leak in as many weeks. LAPSUS$ said on Friday that it obtained an array of source code belonging to Samsung which could lead to access to the “lowest level” of devices such as its Galaxy series of smartphones.

Hosting company GoDaddy has said that around 1.2 million users have been affected by a data breach on its managed WordPress hosting service.

The hack is said to have exposed email addresses, customer numbers, administrative login credentials, and in some cases SSL private keys.

The hosting company discovered that an intruder had gained access to its managed WordPress hosting environment on Nov 17, it said in a filing with the SEC. The intruder used a stolen password to access the provisioning system for the service.

Up to 1.2 million active and former users of the company's managed service had their email addresses and customer numbers exposed, the company said, raising the possibility of further phishing attacks to come. The original administrative passwords for the managed WordPress accounts were also available to the hacker, putting the accounts themselves at risk if the credentials were still in use.

Also exposed were sFTP and database usernames and passwords, and an undisclosed number of users also had their SSL private keys exposed.

GoDaddy discovered that the intruder had been inside the system since September 6, meaning that the hacker has had access to the data for over two months. It worked with a forensics company upon discovering the incident, and has taken steps to safeguard its systems, including changing original administrative passwords that were still in use, resetting sFTP and database passwords, and installing new digital certificates for affected customers.

"We are sincerely sorry for this incident and the concern it causes for our customers," the company said in its filing. "We, GoDaddy leadership and employees, take our responsibility to protect our customers’ data very seriously and never want to let them down. We will learn from this incident and are already taking steps to strengthen our provisioning system with additional layers of protection."

In 2017, the company revoked thousands of SSL certificates after issuing them without proper checks and authorization. In January 2019, an independent researcher found a vulnerability in its process for handling DNS change requests that enabled hackers to hijack domains and create phishing campaigns. It also notified customers of a hack that exposed SSH login details in the same year.

Microsoft's Exchange administration portal was offline over the weekend after the company failed to renew an expired SSL/TLS certificate.

Bleeping Computer reported that Exchange administrators were unable to access the site on Sunday morning. They encountered an error page explaining that their connection was not private. At the time, Qualys Labs reported the certificate associated with the site expired at 8 am Eastern Time on Sunday, but Microsoft has since fixed the problem.

Twitter user Tzatl tweeted at the company on Sunday, asking: "Did you guys really forget to renew a certificate?" Microsoft responded that it had isolated the problem and was applying a fix, referring users to entry EX257883 under its service health dashboard.

The issue provoked some teasing from users on Twitter. "Someone done goofed," replied one user, along with a picture of the untrusted certificate report from Digicert Cloud Services.

This isn't the first time a large technology company has downed a service by forgetting to renew a certificate.

Last month, Epic Games accidentally allowed a certificate used across many of its internal-facing services to expire. That took account logins offline for many of its most popular games, including Fortnite.

In February, Google Voice went offline temporarily after a certificate went out of date. In November, GitHub's home page went down after a certificate responsible for accessing information from a content distribution network expired. Last August, Spotify let a TLS certificate lapse, leaving users without music.

Secure Socket Layer (SSL) has evolved into its successor, Transport Layer Security (TLS). Both are cryptographic protocols that provide secure connections between two endpoints. An SSL/TLS certificate enables a website to prove its identity with a trusted third-party certificate authority (CA).

Certificate management is likely to become more problematic following a change to certificate longevity last September. Apple, Google, and Mozilla all imposed a maximum 398-day lifetime on certificates from September 1, 2020 in a bid to limit the time a site can use a compromised certificate. This continues a trend of shortening certificate lifespans, which stood at 60 months in 2012, 39 months in 2015, and 27 months in 2018.

In its 2021 State of Machine Identity Management Report, Keyfactor found that 88% of companies had experienced at least one unplanned certificate outage in the prior two years.

SSL is under attack, not just from those who would do bad things unto thee but also from We The Media. The latest headline-grabbing threat was revealed in an OpenSSL security advisory last week which started with a high severity warning entitled "OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291)."

This could impact users of the open source crypto library, well OpenSSL version 1.0.2 anyway, and to cut a very long and boring story short enable a Denial of Service attack to occur against the server. It enabled a malicious client to crash - and then reboot - the server with a NULL pointer deference when renegotiating with an invalid signature algorithm. I did warn you it was boring. Not, however, as boring as the IT security industry commenting spat that rolled out as a result.

Here's how these things tend to work: a security scare/advisory/patch is revealed and immediately the IT security vendors and industry players start providing comments to their marketing people who then spin these out to us press folk in the hope that we will use their client quote in a news or analysis piece with a mention of the company at worse and a link to their site or product at best.

There's nothing wrong in that, per se, and these comment releases can often be the starting point of some very interesting and informative follow up conversations for journalists covering the story. Where things can go a bit pear-shaped, though, is when a company has nothing of value to say, but the PR people spin the release out anyway. The OpenSSL advisory was no exception to the industry comment flood rule, and amongst the inevitable marketing dross there were a few real peaches. Just not, perhaps, for the intended reason.

On particular expert added to the hype around just how big the vulnerability was - via an embargoed press release to stir up the excitement further. A little while later, that opinion seemed to change to suggest it was preferrable to certain other forms of attack.

I had to read the statement several times for it to sink in. Could a security outfit really be saying that one attack is preferred to another? This made me wonder whether we should be thinking in terms of preferred vulnerabilities at all. After all, if your organisation was taken out of play by a DDoS attack I'm pretty sure you wouldn't be thinking "phew, that was a close one, it could have been a data breach."

In the real world of tight budgets and tough choices, there has to be some form of risk analysis to determine where the money should be spent in terms of the data protected and the cost to the organisation if a breach were to occur. However, I'm not sure that this risk auditing should extend to a point of threat granularity whereby you determine that one attack mode is less worthy of prevention than another. Especially as the newly released Quarterly DDoS Trends and Analysis Report from Corero reveals that, in the case of DDoS, 79 per cent of the attacks it analysed for the research were less than 5Gbps in peak bandwidth utilisation. This suggests they were intended to distract corporate security teams while leaving enough bandwidth for a subsequent network breach attempt. This kind of blended threat, with a merging of attack types, makes it very hard to determine in advance if one vulnerability is less dangerous than another.

Ultimately, security should be viewed holistically as part of the process of doing business. A proper 360-degree perspective on securing the network and the data moving around within it is what businesses need to strive to achieve.

I do understand that risk needs to be assessed and budgets directed according to where the greatest risk to the business sits, but this has to be done within the context of a rounded view of the enterprise threatscape and bad actors inhabiting it.

Is your business prepared for new EU cyber security regulations? This whitepaper offers advice, insight and guidance on what to do next. Read it today here.

Hackers are easily able to extract the fake security certificate used by Superfish to make their malware even more dangerous, Facebook has warned.

Superfish, the adware program that came pre-installed on Lenovo machines, used a self-signed security certificate, known as a Certificate Authority (CA), to impersonate any SSL-enabled website.

That means it could trick a user's computer into connecting with a website by offering up its own, insecure CA, rather than the website's own, which a computer must receive to confirm the website is what it claims to be.

Known as a man-in-the-middle attack, this undermines the security of web browsers and operating systems, because it can see all of a computer user's actions, including banking, email and Facebook activity.

Lenovo was quick to state it didn't profile or monitor user behaviour, or record user information, and has now stopped shipping devices with the adware pre-installed.

However, Facebook security researcher Matt Richard warned other threat actors could re-use the Superfish CA on their own applications.

He wrote: "By reusing the same certificate, a bad actor could potentially obtain that CA file and perform "man-in-the-middle" (MITM) attacks on untrusted networks like public Wi-Fi, set up authentic-looking phishing pages, or sign software that makes people vulnerable to other malicious code as they browse the internet.

"In this case, the certificate used by the Superfish software is relatively easy to extract. Although we are not aware of anyone abusing this certificate in the wild, it's a real risk and would be hard to detect."

He said the social network has found more than 12 other software applications using the same fake certificate program as Superfish.

While Facebook is yet to determine the purpose of these applications, some of which appear to be Superfish-esque adware, he said a number of them are suspicious.

"What all of these applications have in common is that they make people less secure through their use of an easily obtained root CA, they provide little information about the risks of the technology, and in some cases they are difficult to remove," Richard added.

These applications are also unlikely to keep up with updates to the secure browser HTTPS protocol, meaning there's a risk they could expose private data to network attackers.

Superfish's fake CA comes from a company called Komodia, and Facebook found a Trojan horse, known as Trojan.Nurjax, using the Komodia's libraries of software development kits.

Apple has patched a major security flaw in OS X Mavericks that could allow hackers to intercept users' communications.

The OS X Mavericks v10.9.2 patch fixes a vulnerability that alters the way Mac devices handle encrypted communications, and means critical checks on the validity of a site's SSL certificate are overlooked when users try to establish a secure connection.

As a result, users have been warned to take caution when accessing sensitive web content using unsecured wireless networks until they have a chance to download the fix.

The emergence of the OS X Mavericks v10.9.2 patch comes several days after the consumer electronics giant flagged the existence of the same fault affecting iOS 6 and iOS7 devices.

At the time, details about a similar flaw in OS X Mavericks began to circulate, but a fix for the issue was only published on Apple's support pages yesterday.

The update also reportedly includes improvements to Mail, Messages and Safari apps, and also allows Mac users to participate in FaceTime calls.

In both cases, Apple's security alerts have stopped short of revealing whether the vulnerabilities have been exploited in the wild, or how long the company has been aware of their existence.

Mark Bower, vice president of infosecurity firm Voltage Security, said Mac users should download the patch as quickly as possible.

"This is a major bug that puts users' sensitive data, like login credentials, passwords, email and browsing data at risk," said Bower.

"Users should patch at their earliest opportunity. Until then, users should be very wary of accessing web content that is sensitive, especially on a network that attackers may also be on at the same time which is more often than you might think."

It's difficult to know who or what to trust these days.

Head over to the VeriSign website and you will be met by the bold claim that the Secure Sockets Layer (SSL) and code signing certificate services business which specialises in online identity and authentication will "build trust every step of the way" so as to ensure that you can "Trust your link. Trust your site. Trust your transaction."

But just how waterproof are those claims from the company which was acquired by Symantec back in August 2010, especially following the news that VeriSign had been hacked "successfully and repeatedly" that year.

Researchers are already seeing a rise in attacks which target the worldwide infrastructure that supports SSL.

The finding came thanks to the US law that requires companies to report breaches. A Reuters review of a couple of thousand documents contained in a filing by the US Securities and Exchange Commission (SEC) late last year showed VeriSign was hacked repeatedly during 2010 but the senior management team were not informed of the attacks until September 2011.

In that SEC filing, VeriSign admitted it "faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers." Although VeriSign remained quiet at the time of the filing, and still remains silent to this day as to exactly what information was accessed and what parts of its network was successfully breached, perhaps the most worrying section of the filing is the admission that "given the nature of such attacks, we cannot assure that our remedial actions will be sufficient to thwart future attacks or prevent the future loss of information."

VeriSign has gone on to make an official statement which insists that after a "thorough analysis of the attacks... we do not believe that the operational integrity of the Domain Name System (DNS) was compromised" and "we have a number of security mechanisms deployed in our network to ensure the integrity of the zone files we publish." This was good to know as nobody wants the DNS to be compromised, but it still didn't reveal what was compromised, only leading to much speculation regarding the integrity of its SSL certificates.

This should come as no surprise to anyone with an interest in matters of transactional security, as the whole 'is SSL dead?' debate has been raging for quite some time. Indeed, I myself covered this very subject over at our sister publication PC Pro back in May last year when I asked whether online shopping security was fundamentally broken.

Back then I was asking if the certificate-based trust model used for just about every financial transaction was secure enough in the light of certificate-related breaches such as Stuxnet which included device drivers signed using compromised certificates to give an impression of validity.

Then there was the hacker who compromised a Comodo reseller and generated a whole bunch of fake SSL certificates as a result. It was more than a week after the breach was discovered that all the major browsers had updated their certificate information to ensure users were not at risk from sites bearing the fake ones. And who recalls the DigiNotar fuss last year with fake certificates issued in order to impersonate Gmail amongst other services?

Going back even further, in 2008 I reported here at IT Pro about two years of compromised Linux security based around a vulnerability in the Debian OpenSSL cryptographic libraries and in 2009 I was already asking the 'is SSL secure?' question following a demonstration at Black Hat Las Vegas of man-in-the-middle attacks exploiting flaws in SSL to intercept traffic using a null-termination certificate.

This is something Rob Rachwald, director of security strategy at Imperva, picked up on when he noted "a growing number of web applications are delivered over the HTTPS protocol (HTTP over SSL) with attackers increasingly focusing their attacks against the various components of SSL." Rachwald claimed his researchers are already seeing a rise in attacks which target the worldwide infrastructure that supports SSL.

Meanwhile, Catalin Cosoi, global research director at security vendor BitDefender, thinks enterprise trust may already be shattered by the VeriSign breach.

The potential for some nasty security surprises is going to linger for a while.

"A valid digital signature is a crucial requirement of 64-bit operating systems whenever a critical piece of software tries to install itself. VeriSign is one of the most important enterprise trust authorities in the world, which delivers people safely to more than half the world's websites," Cosoi said.

"A certificate issued by VeriSign will automatically be accepted by both browsers and operating systems. This kind of incident practically voids all the security provided by 64-bit operating systems."

Cosoi concluded his statement on the breach disclosure with a worst case scenario, painting a picture of "several phishing attacks with valid certificates that browsers will render as legit" and which would "potentially yield a huge level of data that could be exploited for financial gain."

But there is one small detail that just about everyone seems to be missing here: there is absolutely no evidence to suggest that the SSL certification network was compromised at all. In fact, it would appear more likely to have escaped intact.

First of all the SSL certificate and code signing side of the VeriSign business was acquired by Symantec in 2010, at a time when Paul Meijer was director of infrastructure operations. Meijer continues that same role now for Symantec Authentication Services (which includes SSL and PKI amongst others) and is insistent that the authentication networks were not compromised by the breach.

Meijer said in a blog post that "at the time the breach occurred, VeriSign was running a separate production network to host the Authentication Services 'Cloud' of SSL, PKI, VIP, and FDS."

"When the Authentication Services business moved over to Symantec, we continued to employ the practice of this separate production network. This segregation prevents breaches on the corporate network from infecting the production network.

"Symantec's production network is completely separate from VeriSign's corporate network. Additionally, our development environment also resides on a separate network from the corporate systems network, and is hosted only in a Symantec-owned facility. Finally, the VeriSign root keys, which form the basis of SSL trust, are kept in an offline state and are never accessible on a network."

I'm not usually one to stand up for Symantec, but on this occasion it would seem that 'what if' fever has infected the media and security vendors alike, when there is nothing to actually suggest SSL certificates have been compromised.

I am not, for one moment, underplaying the seriousness of the breach. The potential for some nasty security surprises is going to linger for a while. Yet what the media, and anyone with an interest in keeping their data secure, should be doing is not speculating about certificate-based transactional security but rather putting pressure on VeriSign to come clean and tell us what was, as opposed to what was not, hacked.

Researchers have found a way to exploit a long-known flaw in TLS (Transport Layer Security) that could undermine the security credentials of the SSL cryptographic protocol and affect millions of sites.

The attack methodology, due to be presented by Juliano Rizzo and Thai Duong at the Ekoparty conference this week, targets TLS version 1.0 and SSL 3.0.

As millions use those protocols to protect certain web transactions, millions of sites could be affected. Major companies, including PayPal and Google, use TLS version 1.0.

Fixing the vulnerability that BEAST exploits may require a major change to the protocol itself.

Rizzo and Duong have created a tool called BEAST (Browser Exploit Against SSL/TLS) to attack the AES encryption algorithm used in TLS and SSL.

BEAST is able to grab and decrypt HTTPS cookies once installed on an end user's browser. This can be achieved either through an iframe injection or by loading the BEAST JavaScript into the target's browser, according to Kaspersky Lab's Threatpost.

This means the attackers can hijack users' sessions and get all the information they want.

"While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests," Duong said.

"While fixing the authenticity vulnerabilities may require a new trust model, fixing the vulnerability that BEAST exploits may require a major change to the protocol itself. Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications."

Google has reportedly prepared an update for its Chrome browser already to help counter the BEAST.

Carrying out the attack is not so simple, however. The hacker has to become the man-in-the-middle' to start with.

"It doesn't mean that anyone can intercept your network traffic and obtain the real data behind it," said Panda Security's Luis Corrons.

"To be able to do that, first they need to gain access to your browser to inject some JavaScript that will do the work. And of course, if you already have gained access to the computer you can do that or install any kind of Trojan horse."

Corrons suggested attackers could also set up a Wi-Fi hotspot to snare users.

"You can create the typical Wi-Fi hotspot, so when anyone connects to it they'll get redirected to the usual welcome page that says thanks for using this service, keep this page open so you can use it for free, click here to start browsing and that's it," he told IT Pro.

Other security professionals have shown their concern about BEAST and its implications for millions of websites.

Philip Hoyer, director of strategy solutions at ActivIdentity, called into question the use of SSL.

"To spell it out: transaction confidentiality based on the SSL TLS V1.0 protocol (the most used still today) is dead," Hoyer said.

"The only true defense from fraudulent transactions is to sign the transaction or part of the transaction data so that the attacker cannot inject bogus material. This means effectively using a token with a pin pad (software on phone or dedicated hardware token) to enter transaction details or signing the transaction using a public key infrastructure certification."

The development comes after fears over hacker exploitation of SSL following hacks on certficate authorities (CAs).

Over 500 fake certificates were issued following a hack on CA DigiNotar, meaning anyone with those fake certificates could dupe end users into believing their internet transactions were being protected by SSL.

DigiNotar was declared bankrupt earlier this week.

ANALYSIS A certain pesky web denizen known as ComodoHacker has been causing a commotion recently.

Last week, he/she claimed a hack on Certificate Authority (CA) DigiNotar, resulting in over 500 fake website certificates being issued for big-time services including Gmail and an MI6 website.

Then Belgian CA GlobalSign stopped issuing authentication certificates after ComodoHacker claimed to have gained access to its servers. They also claimed to have broken into three other certificate authorities outside of GlobalSign and DigiNotar.

The hacker has also threatened to use the fraudulent certificates to carry out man in the middle attacks on organisations in Europe, Israel and the US.

I don't know if this is fixable at all, short of worldwide social changes.

Earlier in the year, another CA known as Comodo was hacked. Can you guess where ComodoHacker got their name?

Outside of the significant cyber war implications, with some saying the DigiNotar hack will have wider connotations than Stuxnet, ComodoHacker has again thrown the whole CA system's credibility into doubt.

Time for a change

There's little doubt something needs to change. It no longer seems sensible to carry on placing all our trust in over 650 CAs, with whom the end user never has any direct contact. They are an invisible force and, in some cases, a weak one. Given their whole business is based on trust, the CAs themselves will be feeling more than tetchy about the current situation.

There are many pertinent questions that need to be asked about the security of the CA system.

"How many of them do you know, let alone trust? Should you trust a state-owned CA more than a commercial concern, or should you trust in market forces and vested interests to override political expediency? Where is the global authority with the mandate and the impartiality to authenticate all those CAs? Who would authenticate the authenticators?" said David Harley, senior research fellow at ESET.

"The problems aren't so much with the technicalities of SSL, as with the difficulties of implementing a system that assumes trust in the provider without a realistic mechanism for determining where you can safely invest that trust."

Harley wasn't sure if the system could be fixed at all. We may be stuck with a flawed framework forever.

"I don't know if this is fixable at all, short of worldwide social changes on the scale of an accelerated continental drift (but in reverse). We've arbitrarily decided to invest trust in CAs, and the opportunities for withdrawing that trust (at any rate without the cooperation of the CAs) are severely restricted (i.e. to take it or leave it)," he told IT Pro.

As any IT guy knows, if you can't fix something, replace it. There are alternatives to the CA system. One of the best, at least according to some big names in the security sphere, is researcher Moxie Marlinspike's Convergence model.

It has been designed to take out the middle men - the CAs - by giving the user greater power. With the Convergence model, users are handed the SSL certificates directly, before asking a number of "trust notaries" to download it too. It then relies on consensus from these notaries to authenticate the web transaction.

I don't believe it would be appropriate to abandon the use of certificate authorities without a clear idea of what could replace it.

To add an additional layer of security, the user goes through a proxy notary so they will remain anonymous to the trust notaries. Sounds like a fine idea, no?

Yet even that model has its limitations. "There are a couple of issues I can see," Harley said.

"Firstly, it throws responsibility for deciding who to trust back down towards the user, whereas the public always wants technical solutions that will save it having to think for itself. Secondly, it has to fight an entrenched commercial model."

Nevertheless, it is a viable option. Time will tell how much support it can gain.

Don't be hasty

If we are to tear down the CA system, it needs to be approached with caution. With any project, especially those involving IT, an incremental approach is almost always best.

Some still argue the CAs have a valuable role, they simply need to be more responsible.

"I don't believe it would be appropriate to abandon the use of certificate authorities without a clear idea of what could replace it. After all, if a criminal gang successfully impersonated the police, few would suggest that we should abolish the police force," said David Emm, senior security researcher at Kaspersky Lab.

"The key, of course, is trust. And I think a critical feature of this incident is the fact that DigiNotar massively under-played the significance of the breach. If trust in any CA is to be maintained, disclosure of any breach is essential."

Emm is right in saying CAs need to get their act together. A number have been caught out. If any more fall at the hands of hackers, then the case for an overhaul of the current model will gain yet more momentum.

For now, the most astute way forward will be in finding the perfect replacement before any radical change is implemented. Right now, the Moxie Marlinspike model offers a real alternative. It should be explored and tested now. If the decline of the CA's reign over web authentication comes, we need to be prepared.

UK intelligence body MI6 was one of over 500 organisations targeted by hackers who compromised certificate authority (CA) DigiNotar.

When DigiNotar confirmed it was hacked last week, it was believed only a handful of fake SSL certificates were issued. A list from the Dutch Government has shown 531 rogue certificates were actually issued, including one for MI6 website sis.gov.uk.

Other targeted sites included the CIA, Facebook, Google, Skype, Twitter and WordPress.

The Dutch Government confirmed it is looking into reports Iran was responsible for the hacks. The Dutch interior ministry said Government websites may not be safe due to the DigiNotar hack, according to the Daily Telegraph.

The consequences of the attack on DigiNotar will far outweigh those of Stuxnet.

"The damage sustained to the Dutch Government IT infrastructure is quite significant. A lot of services are no longer available," said Roel Schouwenberg, Kaspersky Lab expert, in a blog post.

"Effectively, communications have been disrupted. Because of this, one could make an argument the attack is an act of cyberwar."

He said any suggestion the Iranian Government was involved was "all speculation" right now.

"Any kind of hints found in the registered certificates could well be decoys. I remain with my stance that a government operation is the most plausible scenario," he added.

VASCO Data Security International, DigiNotar's parent company, said on Friday it wanted to work with the Dutch Government on identifying who was responsible.

"It is our firm belief that cooperating with VASCO is the right decision for the Dutch Government. We are convinced that together we will solve this issue," said Ken Hunt, VASCO's chairman and chief executive (CEO).

Schouwenberg also called on Apple to revoke affected CAs from its list of trusted services, as other tech giants like Google, Microsoft and Mozilla have done. DigiNotar may not be the only compromised CA "out there," the security expert warned.

Schouwenberg suggested the DigiNotar attack could be even more significant than the emergence of the highly sophisticated Stuxnet malware.

"The attack on DigiNotar doesn't rival Stuxnet in terms of sophistication or coordination," he said.

"However, the consequences of the attack on DigiNotar will far outweigh those of Stuxnet. The attack on DigiNotar will put cyberwar on or near the top of the political agenda of Western governments."

Google has added SSL encryption to its search engine to provide an extra layer of privacy to users' web searches.

Secure Sockets Layer (SSL) scrambles data being transmitted between a user's computer and a server, making it more difficult for third parties to intercept. Google already uses SSL to protect its Gmail and Google Docs services.

For now, the SSL web search which is accessible by typing "https" at the start of the Google search address instead of "http" (with the "s" standing for secure) is in beta and only covers conventional searches, not speciality services such as image, maps or news searches. As such, the links to more specialised searches present along the top of the screen when using the standard service are absent.

SSL-protected web searches ensure session-wide encryption of both the transmission of search queries and the results returned by Google's servers. When using the service, the Google logo will be modified to include an SSL label and padlock.

"We think users will appreciate this new option for searching," Google software engineer Evan Roseman wrote in a blog post. "It's a helpful addition to users' online privacy and security, and we'll continue to add encryption support for more search offerings."

However, Roseman warns that one side-effect of the encryption process is that encrypted searches will invariably be slower than conventional queries, though not significantly so.

The move is a direct response to the privacy storm that has engulfed Google over the past week after it emerged that its Street View vehicles had been capturing not only images from around the world for the mapping service, but also any personal data they happened to came across on unprotected Wi-Fi networks.

In total, more than 600GB of data was collected over a period of three years including emails, passwords and browsing histories. However, Google's claims that beefing up its search engine is a response to "how publicly accessible open, non-password-protected Wi-Fi networks are today" is unlikely to divert much attention from its actions in infiltrating those networks in the first place.

A major' vulnerability in SSL (Secure Sockets Layer) authentication has been discovered, potentially leaving web surfers under serious threat.

The authentication gap allows an attacker to perform a man-in-the-middle' attack, according to security researchers at PhoneFactor.

PhoneFactor claimed that most websites using SSL encryption were affected, including online banking and retail sites. Some mail and database servers were also vulnerable.

It also invalidated the SSL lock, which is used to verify whether website communications are secure.

Researchers Marsh Ray and Steve Dispensa are believed to have shown the flaw to a working group of affected vendors, which included Microsoft, Intel, Nokia, IBM, Cisco and Juniper.

In a statement, PhoneFactor said: "[We] volunteered to delay disclosure on the vulnerability until early 2010 to allow time for vendors to make the necessary patches available."

"However, an independent researcher discovered the vulnerability and posted it to Internet Engineering Task Force (IETF) mailing list on November 4th... News of the vulnerability quickly spread through the IT security community," it added.

PhoneFactor added that this was a protocol vulnerability rather than an implementation flaw, so the impact was far reaching.

"All SSL libraries will need to be patched, and most client and server applications will, at a minimum, need to include new copies of SSL libraries in their products," the firm said.

"Most users will eventually need to update any software that uses SSL."

Andrew Clarke, senior vice president for Lumension, said in a statement that the SSL flaw was likely to bring a large number of patches in the near term from vulnerable vendors.