September 18th, 2007 by Adam Bozanich
While developing an implementation of IKE for our platform, I noticed an astonishing behavior in the servers I was testing against: Not a single IKE implementation, which included products from the biggest names in network infrastructure, were validating the Diffie-Hellman public keys that I sent. A consequence of this is that any deployment of these servers will allow the disclosure of secret information when a peer is in collusion with a passive attacker.
The Diffie Hellman (DH) key exchange is a commonly used protocol which enables two entities to establish a shared secret key. The key is considered secret because it is computationally difficult for an observer of the communications between the two entities to calculate its value. The DH secret is typically used to generate encryption keys for symmetric cipher algorithms which encrypt traffic between the two parties.
A basic DH exchange goes as follows:
Party A and party B publicly agree to use parameters p and g during the exchange. P is a large prime number and g is a primitive root modulo p.
Party A generates a random value S_a, computes K_a = g^(S_a) mod p and sends K_a to B. Party B generates a random value S_b, computes K_b = g^(S_b) mod p and sends K_b to A.
Party A computes K_s = (K_b)^(S_a) mod p. Party B computes K_s = (K_a)^(S_b) mod p.
K_a and K_b are the public keys of party A and party B, and the computed shared secret is K_s. For most cases, it is difficult for an attacker to derive K_s if they only know the values (p,q,K_a,K_b).
There are, however, a number of values that a public key can have which nullify the secrecy of K_s. If one party sends a public key with a value of either zero or one, the other party will compute a value of zero or one for K_s, respectively. In other words, a passive attacker will know the value of the secret key if a public key of zero or one is observed. As will be discussed later, this property has serious negative impact on the security of the DH key exchange protocol.
This vulnerability in the Diffie Hellman key exchange can be mitigated by validating the received public key. The method of validation is explained in the NIST’s “Recommendation for Key Management”. Using the same symbols as we have above, and considering the case where party B has received party A’s public key, the NIST recommendations (section 5.6.2.4) are as follows:
Verify that 2 <= K_a <= p - 2
Verify that (K_a)^g = 1 (mod p)
Similar recommendations for validation can be found in RFC 2631, ANSI X9.42and RFC 2412
If an implementation of the DH key exchange does not validate the public key received, it is leaving itself open to a number of attacks. In the paper “Key Agreement Protocols and their Security Analysis”, Simon Blake-Wilson, Don Johnson and Alfred Menezes formalize the requirements of a secure key agreement protocol. One of the desirable attributes of a key agreement protocol is as follows:
Unknown key-share: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j.
We can see that this attribute does not hold for DH implementations which do not validate public keys. An entity can be coerced into sharing the secret key with any entity that observes the transmission of the public keys. There are a number of real-world scenarios where an unknown key-share completely undermines the legitimacy of networking infrastructure which is designed to provide high security.
IKE is a variant of ISAKMP and is used to establish security associations (SA) between two entities. The SA is a set of parameters which are used to secure IP communications (IPSec). IKE uses the DH key exchange to establish a shared secret which is then used to derive keying material for the encryption of both IKE and IPSec traffic.
IKE can use a number of methods for peer authentication during Phase1, and an exposed secret key has different ramifications for each of them. The digital signature authentication method, which is preferred over pre-shared keys, is particularly vulnerable to this attack.
When using digital signature authentication, the keying material is generated from the DH secret key and a number of other parameters, all of which are sent over the wire un-encrypted. This means that if a passive attacker knows the secret key, they will be able to recover the clear-text of all traffic which is encrypted with this keying material. This includes all encrypted IKE traffic, all IPSec ESP traffic, and the ability to spoof all IPSec AH traffic.
If an IKE implementation is controlled by a party who has the ability to observe traffic coming from and going to the server, or is in collusion with another party who can observe the traffic, all of the server’s peers are in danger of unknowingly exposing the clear-text of encrypted traffic with the observers if they do not validate the DH public key. This situation would be fairly difficult to detect, as the illegitimate IKE server would not have to transmit any traffic outside of the IKE specification.
Other problems stem from the fact that an attacker does not need to perform expensive modular exponentiation to determine the secret key. This lowers the computational power necessary to execute MitM and flooding attacks.
Considering the fact that public key verification is recommended by NIST, ANSI and the DH public key exchange RFC, and given the security implications if no verification is performed, one would expect that most if not all DH key exchange implementations validate the public keys that they receive. This, however, is not the case.
I tested both popular Open Source IKE servers, as well as a number of commercial products. Nobody is validating keys. We also tested this attack against some products with the SSH protocol, and there are vulnerabilities in these implementations as well.
These results prompted the title of this paper. How could some of the biggest names in the networking and security industry miss the boat on such a critical component of their platforms? Why is it that an open source project, such as OpenSSH, would be stripped of the validation checks when imported into a commercial product?
I don’t know the answer to these, but I’m quite alarmed by what we have found. I have created a small patch for ike-scan which will allow you to test products for this vulnerability. Hopefully as people become aware of the consequences of not validating public key values, vendors will begin to make their products more secure.
Labels: Backdoor, crypto
This is an excellent article with good technical explanations. Unfortunately, no answers to the question of whodunnit.
Summary: what happened was that someone installed a very sophisticated rootkit for Vodafone's Ericsson AXE including:
* using the existing wiretapping code, but not the normal user interface;
* bypassing the logging system (of course);
* bypassing the audits;
* hiding the illegal processes from the process list (task manager in Windows or ps ax in Unix) by
modifying the relevant system code;
* adding a backdoor user;
* modified the shell to allow access to the illegal processes.
All done without rebooting the AXE switch!
On 9 March 2005, a 38-year-old Greek electrical engineer named Costas Tsalikidis was found hanged in his Athens loft apartment, an apparent suicide. It would prove to be merely the first public news of a scandal that would roil Greece for months.
The next day, the prime minister of Greece was told that his cellphone was being bugged, as were those of the mayor of Athens and at least 100 other high-ranking dignitaries, including an employee of the U.S. embassy.
A study of the Athens affair, surely the most bizarre and embarrassing scandal ever to engulf a major cellphone service provider, sheds considerable light on the measures networks can and should take to reduce their vulnerability to hackers and moles.
It's also a rare opportunity to get a glimpse of one of the most elusive of cybercrimes. Major network penetrations of any kind are exceedingly uncommon. They are hard to pull off, and equally hard to investigate.
Labels: Backdoor
Cisco IOS Server Backdoor May Have Been Planted By Lisa Vaas , eweek.com
May 15, 2007
A security vendor is questioning whether the IOS FTP Server vulnerabilities Cisco reported on May 9 may constitute an intentionally planted backdoor, as opposed to a series of programming errors that inadvertently led to a backdoor.
Chris Eng, director of security services at
Veracode, is suggesting that possibility given that a remote attacker would need one of the flaws—improper authorization checking in IOS FTP—in order to exploit the second flaw—an IOS reload when transferring files via FTP.
ADVERTISEMENT
In essence, an attacker can bypass authentication and avoid giving credentials because of the first flaw. The attacker then has to overwrite the critical startup configuration file, then has to cause the router itself to reboot in order to execute the rewritten configuration file.
"Is it a coincidence that both flaws happen to be there at same time?" Eng asked in an interview with eWEEK. "Multiple things have to fall into place to really exercise the full extent of the attack. That seems a little bit odd. It kind of has the trademarks of what you'd expect from [an intentionally planted] backdoor."
Together, the flaws open the door for an attacker to retrieve or write any file from the device file system—including the device's saved configuration. "That configuration file may include passwords or other sensitive information," Cisco said in its advisory.
The origin of the flaws boils down to a question of intent, Eng said. Cisco essentially said in its advisory that the flaws can be used as a backdoor. That could mean that an attacker could exploit the vulnerabilities to gain access to a router.
The backdoor allows a remote attacker to log onto the FTP service on the router without credentials, get onto the router itself and read or write any file on the router's file system. The startup configuration is what the router reads when it reboots, to seed its initial configuration. If an attacker can control that by overwriting, he or she essentially has control of the entire router.
The attacker could take the router offline, for example, or, more ominously, could route traffic to another destination where the traffic can be intercepted.
In that definition, we're not looking at how the flaw got there in the first place, Eng said. "We're just taking it as a fact that yes, it's there and yes, people could do bad things with it."
The flaws could well be simple programming mistakes. "In most cases, when a vulnerability in a piece of software is discovered and made public, it's because of an implementation error on the part of the [developer not having] adhered to secure programming guidelines," Eng said. "It's just a mistake. Programmers do it all the time."
On the other hand, if the flaws are a backdoor, was it planted into the code base intentionally, by someone who gained access to the code base? Such could be the case with a disgruntled developer who had access to the code base, Eng said, or somebody who didn't already have access to the code base launched an attack on Cisco, gained access to the code base and surreptiously made changes. Then, once the code ships, such access to routers gets pushed out to all Cisco customers, he said.
If the flaws weren't intentionally planted, then they at least highlight the need for more frequent and better security reviews, Eng said, given the number of versions of IOS that harbor the flaws "This is an FTP interface and an authentication mechanism," he said. "Maybe they need better focusing of security reviews to look at these critical components, and look at these things that are liable to be exploited. With five versions of 12 [affected, etc.], they might need to do this more frequently to catch these things."
Use of the IOS FTP Server is an optional service that is disabled by default. Users can disable use of the server by executing this command in configuration mode:
no ftp-server enable
Cisco has supplied other mitigations here in Cisco's Applied Intelligence document, a companion to the advisory.
Cisco hadn't responded to a request to comment on the issue by the time this story was posted.
Labels: Backdoor
http://secunia.com/advisories/24962/
Description:
A vulnerability and a security issue have been reported in Nortel VPN Routers, which can be exploited by malicious people to bypass certain security restrictions or manipulate certain data.
1) Two default user accounts ("FIPSecryptedtest1219" and "FIPSunecryptedtest1219") are configured on the VPN Router, which are not readily visible to the system manager. These can be exploited to gain unauthorized access to the private network.
2) Missing authentication checks within two template files of the web management tool can be exploited to e.g. modify certain router configurations.
An issue regarding same DES keys used to encrypt user's passwords has also been reported, which can facilitate brute-force attacks on user's passwords if the attacker were to gain access to the LDAP store.
The vulnerability and security issue reportedly affect the following products:
* Contivity 1000 VPN Switch
* Contivity 2000 VPN Switch
* Contivity 4000 VPN Switch
* VPN Router 5000
*VPN Router Portfolio
Solution:
Update to versions 6_05.140, 5_05.304, or 5_05.149.
Provided and/or discovered by:
The vendor credits
Detack GmbH.Labels: Advisory, Appliance, Backdoor, Insecurity, Vulnerability
Mar 29 2007
Nikolay Grebennikov
'Keyloggers, phishing and social engineering are currently the main methods being used in cyber fraud.'In February 2005, Joe Lopez, a businessman from Florida, filed a suit against Bank of America after unknown hackers stole $90,000 from his Bank of America account. The money had been transferred to Latvia.
An investigation showed that Mr. Lopez’s computer was infected with a malicious program, Backdoor.Coreflood, which records every keystroke and sends this information to malicious users via the Internet. This is how the hackers got hold of Joe Lopez’s user name and password, since Mr. Lopez often used the Internet to manage his Bank of America account.
However the court did not rule in favor of the plaintiff, saying that Mr. Lopez had neglected to take basic precautions when managing his bank account on the Internet: a signature for the malicious code that was found on his system had been added to nearly all antivirus product databases back in 2003.
Joe Lopez’s losses were caused by a combination of overall carelessness and an ordinary keylogging program.
Full article
hereLabels: Backdoor, News Article, Social Engineering, Trojan
Name : Backdoor:W32/PcClient.YW
Alias: DR/PcClient.Gen, Trojan.Dropper.CI
Size: varies
Type: Backdoor
Category: Malware
Platform: W32
Date of Discovery: March 08, 2007
Summary Backdoor:W32/PcClient.YW attempts to hide processes, files, and registry data. It allows the attacker to perform arbitrary actions on the infected machine. Backdoor:W32/PcClient.YW has a rootkit functionality and steals sensitive information from an infected computer.
Disinfection If the rootkit is not detected or it is hidden and FSAV cannot detect its file, it is still possible to detect the malicious activity by scanning the system with a generic rootkit scanner, such as F-Secure BlackLight. More information about F-Secure BlackLight Rootkit Elimination Technology can be found here:
http://www.f-secure.com/blacklight/
Detailed Description
Once the Backdoor:W32/PcClient.YW had been executed, it will drop its components in the following path and filename:
%programfiles%\internet explorer\connection wizard\zhyrikwo.dll - backdoor
%programfiles%\internet explorer\connection wizard\zhyrikwo.drv - keylogger
Note: the file size of zhyrikwo.dll might vary due to garbage code appended at the end of the file.
It will also drop the following driver that will communicate with the .dll files in order to hide the malware processes, registry entries and files:
%programfiles%\internet explorer\connection wizard\zhyrikwo.sys - rootkit
It modifies the following known registry entry as its autostart technique:
Data before:
[HKLM\SYSTEM\CurrentControlSet\Services\sens\Parameters]
ServiceDll = %sysdir%\sens.dll
Data after:
[HKLM\SYSTEM\CurrentControlSet\Services\sens\Parameters]
ServiceDll = %programfiles%\internet explorer\connection wizard\zhyrikwo.dll
The file zhyrikwo.dll will intercept any access to the original file, sens.dll. as a stealth mechanism, and after executing its malicious routines, will transfer the correct parameters to sens.dll.
It also adds the following autostart registry entry for the driver:
[HKLM\System\ControlSet001\Services\zhyrikwo]
ImagePath= %programfiles%\internet explorer\connection wizard\zhyrikwo.sys
Note: This rootkit can be detected by F-Secure's BlackLight.
Part of its payload is that it logs all the keystrokes made by the user and sends this file to a remote hacker.
Another part of the payload is that it has a backdoor component. The backdoor routine is injected into svchost.exe, which is capable of doing the following:
updating itself , remote execution
This malware connects to the following site:
http://dynsev5299.2mydns.com/i[BLOCKED]x.asp
Detection F-Secure Anti-Virus detects this malware with the following updates:
[FSAV_Database_Version] Version = 2007-03-07_10.
Labels: Anti-Virus, Backdoor, Microsoft, Worm
When is a backdoor really a backdoor?By John Leyden
Published Thursday 15th February 2007 16:46 GMT
Workplace smoking bans may be good for workers' health, but could open the back door to hackers.
In a recent social engineering test undertaken by UK-based security consultancy NTA Monitor, a tester was able to easily gain access to a corporate building through a back door that was left open for smokers. Once inside, the penetration tester was able to easily bluff his way into a meeting room, claiming the IT department had sent him. Even without a pass, he gained access unchallenged and was then able to connect his laptop to the firm's VoIP network via a telephone connection point.
NTA Monitor technical director Roy Hills comments: "It used to be that companies 'left the back door open' in terms of internet security. Now they are literally leaving their buildings open to accommodate smokers.
"Once inside a corporate building, an attacker can use social methods on employees to gain access to restricted areas and information unless a rigid staff pass system is in place," he added.
Smoking will be banned in all indoor public spaces in the UK in July 2007. In many other European countries, such as Spain, workplace smoking restrictions have already been applied. ®
Labels: Backdoor, Insecurity, News Article