IPSEC / ISAKMP Vulnerability wrapup
This diary is intended to provide a higher level overview about this issue in addition to the earlier "blow by blow" diary.
How serious is all of this?
The world an the Internet will continue to turn. This issue is however very important to you if you are using an IPSEC VPN. At this point, all points to this being a DOS only vulnerability. Your IPSEC concentrator may reboot or lock up. While this is not as severe as remote code execution, it can still break a business if critical network links are impacted.
Who is Impacted?
If you are using IPSEC, check with your vendor to make sure. Cisco, Juniper, Secgo and OpenSWAN released patches. In particular OpenSWAN may be used in many Linux and BSD based appliances. See the earlier diary for a list of firmwares. ISAKMP and IPSEC have to be enabled.
What is "ISAKMP"?
ISAKMP is used as part of the IPSEC protocol. It is used to establish "Security Associations". Each IPSEC connection is defined by a Security Association. ISAKMP is used to figure out what kind of encryption to use. In order to do this, it exchanges key generation and authentication data. Think of ISAKMP as the connection you establish ahead of the actual IPSEC connection. Only once ISAKMP worked out the details, you typically establish the IPSEC connection.
ISAKMP uses UDP packets with a source and target port of 500.
Why is it broken?
ISAKMP, in its nature, is rather complex and flexible. A group at the University of Oulu (Finland) developed a test suite to generate abnormal ISAKMP traffic. As they used this test suite against various IPSEC implementations, they found them to be vulnerable. The PROTOS test suite has been used with similar results against other protocols like SMNP before.
Is all Port 500 UDP Traffic Bad?
No. You will see plenty of port 500/udp traffic hitting your firewall just as a matter of "doing packets". Some systems, in particular later versions of Windows, will attempt to create an IPSEC connection before establishing any "regular" connection. So your web server may see a lot of port 500 udp traffic from innocent systems like that. ISAKMP is used to negotiate an IPSEC connection, so it can be used to see if you can establish an IPSEC connection with a remote host. It will fall back to a regular non-IPSEC connection if permitted (which is the default).
Where can I find out more?
Get all the gory details about PROTOS from the University of Oulu:
http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp/
NISCC, who coordinated the vulnerability release, posted an advisory here:
http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en
The prior diary, with more links, can be found here:
http://isc.sans.org/diary.php?storyid=848
Thanks to all the other handlers who help to decipher the various advisories.
How serious is all of this?
The world an the Internet will continue to turn. This issue is however very important to you if you are using an IPSEC VPN. At this point, all points to this being a DOS only vulnerability. Your IPSEC concentrator may reboot or lock up. While this is not as severe as remote code execution, it can still break a business if critical network links are impacted.
Who is Impacted?
If you are using IPSEC, check with your vendor to make sure. Cisco, Juniper, Secgo and OpenSWAN released patches. In particular OpenSWAN may be used in many Linux and BSD based appliances. See the earlier diary for a list of firmwares. ISAKMP and IPSEC have to be enabled.
What is "ISAKMP"?
ISAKMP is used as part of the IPSEC protocol. It is used to establish "Security Associations". Each IPSEC connection is defined by a Security Association. ISAKMP is used to figure out what kind of encryption to use. In order to do this, it exchanges key generation and authentication data. Think of ISAKMP as the connection you establish ahead of the actual IPSEC connection. Only once ISAKMP worked out the details, you typically establish the IPSEC connection.
ISAKMP uses UDP packets with a source and target port of 500.
Why is it broken?
ISAKMP, in its nature, is rather complex and flexible. A group at the University of Oulu (Finland) developed a test suite to generate abnormal ISAKMP traffic. As they used this test suite against various IPSEC implementations, they found them to be vulnerable. The PROTOS test suite has been used with similar results against other protocols like SMNP before.
Is all Port 500 UDP Traffic Bad?
No. You will see plenty of port 500/udp traffic hitting your firewall just as a matter of "doing packets". Some systems, in particular later versions of Windows, will attempt to create an IPSEC connection before establishing any "regular" connection. So your web server may see a lot of port 500 udp traffic from innocent systems like that. ISAKMP is used to negotiate an IPSEC connection, so it can be used to see if you can establish an IPSEC connection with a remote host. It will fall back to a regular non-IPSEC connection if permitted (which is the default).
Where can I find out more?
Get all the gory details about PROTOS from the University of Oulu:
http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp/
NISCC, who coordinated the vulnerability release, posted an advisory here:
http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en
The prior diary, with more links, can be found here:
http://isc.sans.org/diary.php?storyid=848
Thanks to all the other handlers who help to decipher the various advisories.
Keywords:
0 comment(s)
Remotely Exploitable CodeGrrl PHP Products File Inclusion Vulnerability
Secunia - CodeGrrl Products "siteurl" File Inclusion Vulnerability
"Successful exploitation requires that "register_globals" is enabled."
"Solution:
Edit the source code to ensure that input is properly sanitised.
Set "register_globals" to "Off".".
FrSIRT CodeGrrl Multiple Products "siteurl" Remote File Inclusion Vulnerability
"Affected Products
PHPCurrently version 2.0 and prior
PHPQuotes version 1.0 and prior
PHPCalendar version 1.0 and prior
PHPClique version 1.0 and prior
PHPFanBase version 2.1 and prior".
"Successful exploitation requires that "register_globals" is enabled."
"Solution:
Edit the source code to ensure that input is properly sanitised.
Set "register_globals" to "Off".".
FrSIRT CodeGrrl Multiple Products "siteurl" Remote File Inclusion Vulnerability
"Affected Products
PHPCurrently version 2.0 and prior
PHPQuotes version 1.0 and prior
PHPCalendar version 1.0 and prior
PHPClique version 1.0 and prior
PHPFanBase version 2.1 and prior".
Keywords:
0 comment(s)
WinRAR and RAR 3.51 Released
WinRAR and RAR 3.51 has been released with fixes for the WinRAR Format String and Buffer Overflow Vulnerabilities discovered by Secunia Research. RARLAB is the home of the WinRAR and RAR archivers. Information on what's new in the latest version is here.
"Version 3.51
1. Bugs fixed:
a) fixed two vulnerabilities, which could be exploited with specially crafted ACE and UUE/XXE archives;
b) previous version did not delete some of temporary files;
c) WinRAR could crash when processing very long (more than 1024 characters) archive name parameter in the command line."
"Version 3.51
1. Bugs fixed:
a) fixed two vulnerabilities, which could be exploited with specially crafted ACE and UUE/XXE archives;
b) previous version did not delete some of temporary files;
c) WinRAR could crash when processing very long (more than 1024 characters) archive name parameter in the command line."
Keywords:
0 comment(s)
Cisco and Juniper - ISAKMP Protocol - Multiple Vulnerability Issues
CERT-FI and the NISCC Vulnerability Team published an advisory for an ISAKMP issue which "was identified by the Oulu University Secure Programming Group (OUSPG) from the University of Oulu in Finland.".
Juniper rates this as High risk.
Cisco says "When receiving certain malformed packets, vulnerable Cisco devices may reset, causing a temporary Denial of Service (DoS)."
Openswan's announcement - Openswan response to NISCC Vulnerability Advisory 273756/NISCC/ISAKMP
"Openswan is an implementation of IPsec for Linux. It supports kernels 2.0, 2.2, 2.4 and 2.6, and runs on many different platforms, including x86, x86_64, ia64, MIPS and ARM."
UPDATE
StoneGate's advisory says their "Firewall and VPN engine versions 2.6.0 and earlier use a vulnerable version of IKEv1 implementation." "Severity: High". "Recommended Actions: All StoneGate Firewall and VPN users should upgrade their StoneGate Firewall and VPN engines to version 2.6.1 or later.".
UPDATE
Secgo has an announcement that says "The following Crypto IP gateway and client versions are vulnerable:
Crypto IP gateway/client 2.3 (all 2.3 versions)
Crypto IP gateway/client 3.0.0 - 3.0.82
Crypto IP client 3.1 (all 3.1 versions)
Crypto IP gateway/client 3.2.0 - 3.2.26".
Original CERT -FI/NISCC announcements posted here; CERT-FI and NISCC
From the advisory:
"The vulnerabilities described in this advisory affect the Internet Security
Association and Key Management Protocol (ISAKMP), which is used to provide
associations for other security protocols."
"Impact
------
The severity of these vulnerabilities varies by vendor, please see the "Vendor
Information" section below for further information or contact your vendor for
product specific information. These flaws may expose Denial-of-Service conditions,
format string vulnerabilities, and buffer overflows. In some cases, it may be
possible for an attacker to execute code.
ISAKMP/IKE client applications may be harder to attack than server applications
because in some cases, it may be required that clients initialise the negotiation."
Some information in the Vendor advisory;
"Juniper Networks, Inc
Bulletin Number: PSN-2005-11-007
Title: IKE version 1 vulnerability issues resulting from OUSPG ISAKMP Test Suite (NISCC/ISAKMP/273756)
Products Affected: All Juniper Networks M/T/J/E-series routers.
Platforms Affected: JUNOS Security / JUNOSe Security"
"Risk Level: High"
"Risk Assessment:
Juniper Networks JUNOS and JUNOSe software is susceptible to certain IPSec ISAKMP/IKE vulnerabilities as exposed by theOUSPG ISAKMP/IKE test suite. Risk assessment is high for Juniper Networks E/M/T/J-series routers."
"Vendor Information"
------------------
"A complete list of vendor responses to this vulnerability are not currently
available. Please visit the web site at http://www.niscc.gov.uk/niscc/vulnAdv-en.html
in order to view the latest vendor statements."
Research
Oulu University Secure Programming Group PROTOS Test-Suite: c09-isakmp
Juniper rates this as High risk.
Cisco says "When receiving certain malformed packets, vulnerable Cisco devices may reset, causing a temporary Denial of Service (DoS)."
Openswan's announcement - Openswan response to NISCC Vulnerability Advisory 273756/NISCC/ISAKMP
"Openswan is an implementation of IPsec for Linux. It supports kernels 2.0, 2.2, 2.4 and 2.6, and runs on many different platforms, including x86, x86_64, ia64, MIPS and ARM."
UPDATE
StoneGate's advisory says their "Firewall and VPN engine versions 2.6.0 and earlier use a vulnerable version of IKEv1 implementation." "Severity: High". "Recommended Actions: All StoneGate Firewall and VPN users should upgrade their StoneGate Firewall and VPN engines to version 2.6.1 or later.".
UPDATE
Secgo has an announcement that says "The following Crypto IP gateway and client versions are vulnerable:
Crypto IP gateway/client 2.3 (all 2.3 versions)
Crypto IP gateway/client 3.0.0 - 3.0.82
Crypto IP client 3.1 (all 3.1 versions)
Crypto IP gateway/client 3.2.0 - 3.2.26".
Original CERT -FI/NISCC announcements posted here; CERT-FI and NISCC
From the advisory:
"The vulnerabilities described in this advisory affect the Internet Security
Association and Key Management Protocol (ISAKMP), which is used to provide
associations for other security protocols."
"Impact
------
The severity of these vulnerabilities varies by vendor, please see the "Vendor
Information" section below for further information or contact your vendor for
product specific information. These flaws may expose Denial-of-Service conditions,
format string vulnerabilities, and buffer overflows. In some cases, it may be
possible for an attacker to execute code.
ISAKMP/IKE client applications may be harder to attack than server applications
because in some cases, it may be required that clients initialise the negotiation."
Some information in the Vendor advisory;
"Juniper Networks, Inc
Bulletin Number: PSN-2005-11-007
Title: IKE version 1 vulnerability issues resulting from OUSPG ISAKMP Test Suite (NISCC/ISAKMP/273756)
Products Affected: All Juniper Networks M/T/J/E-series routers.
Platforms Affected: JUNOS Security / JUNOSe Security"
"Risk Level: High"
"Risk Assessment:
Juniper Networks JUNOS and JUNOSe software is susceptible to certain IPSec ISAKMP/IKE vulnerabilities as exposed by theOUSPG ISAKMP/IKE test suite. Risk assessment is high for Juniper Networks E/M/T/J-series routers."
"Vendor Information"
------------------
"A complete list of vendor responses to this vulnerability are not currently
available. Please visit the web site at http://www.niscc.gov.uk/niscc/vulnAdv-en.html
in order to view the latest vendor statements."
Research
Oulu University Secure Programming Group PROTOS Test-Suite: c09-isakmp
Keywords:
0 comment(s)
Another Juniper problem - Juniper Bulletin PSN-2005-11-003 from 11/04/05
Bulletin PSN-2005-11-003 says, among other things, "The Routing Protocol process might restart.....".
"Affected JUNOS release 7.3 built prior to September 9, 2005 and all other JUNOS software releases built prior to October 14, 2005.
"Platforms Affected JUNOS 7.x JUNOS 6.x"
The Bulletin solution is patch or use their recommended configuration solution.
Neither of today's Diary items related to Juniper are referenced yet at the J-Security Center or publicly at the Support Security Center.
"Affected JUNOS release 7.3 built prior to September 9, 2005 and all other JUNOS software releases built prior to October 14, 2005.
"Platforms Affected JUNOS 7.x JUNOS 6.x"
The Bulletin solution is patch or use their recommended configuration solution.
Neither of today's Diary items related to Juniper are referenced yet at the J-Security Center or publicly at the Support Security Center.
Keywords:
0 comment(s)
Strange phishing/spam e-mails
Here is the latest update on the following Scenerio. Thanks to fellow handler Bojan for your great analysis and work on this one!
At the moment I am pretty sure that spammers
were using this "trick" to make users solve CAPTCHA graphics for them. In
this case, I believe they were trying to open new accounts on free webmail
www.pochta.ru (that's a legitimate Russian webmail). When you try to open a
new account on that site (http://www.pochta.ru/regform
presented with a CAPTCHA picture and it's link will be exactly
http://www12.pochta.ru/rnd_img
example).
Now, pochta.ru uses sid parameter to identify which CAPTCHA image will be
presented. The image itself will be changed (colors and number positions),
but the string that the user has to enter will remain the same. To test this
just enter the URL above in your browser and refresh couple of times - you
will see how it changes.
Therefore, spammers can build a big table of corresponding SID strings
(probably just hashes) and correct answers which enables them to
automatically open new accounts. This maybe even works on other sites if
they use same programs to generate CAPTCHA images.
END UPDATE
We received couple of reports of very strange phishing/spam e-mails.
They all share obfuscated text which is shown properly when rendered as a HTML. In the body of the e-mail the text is always similar to:
"Dear <domain> Member,
We must check that your <domain> ID was registered by real people. So, to help <domain> prevent automated, registrations, please click on this link and complete code verification process."
The link is, of course, hidden in the HTML and the displayed one is different from where the user will go when they click the link.
All of these e-mails use Google redirector techniques in order to defeat SURBL (Spam URI Realtime Blocklists). Some of the e-mails we saw also use multiple redirectors in order to defeat Google's anti-redirector script.
They are also frequently malformed and don't work at all, for example, one of the reports we received pointed to this URL (with spaces added by us to prevent clicking on it):
ht tp://www.go ogle.to/url?q=http://STaNdar TzA.Com/cgi -bin/p och/redir.cgi?s=<domain>
All e-mails always had recipients domain as the argument to the redir.cgi script. Also, most of the URLs are malformed and won't work (notice characters).
Some of the first e-mails that were submitted pointed to a different domain - standza.net. This URL was accessible for couple of hours and it didn't seem to do anything - it was probably used to collect IP addresses, or the author is/was still setting things up.
The domain which is used now, standartza.com is not resolvable, but is registered.
Thanks to Laurent D, Dan W, Guy R!
UPDATE
We received some very nice submissions about this.
First, in order to obfuscate their text, spammers use special Unicode formatting characters. The trick is to use "Right-To-Left Override" (RLO), so any text between two delimiters will be displayed backwards.
From the document at http://www.unicode.org/charts/PDF/U2000.pdf, and received phishing e-mails, we can see that those delimiters are ‮ and ‬. The reason for this is simple. Bayesian spam filters which don't render this properly will end up with weird tokens in their databases and the spammer can change tokens frequently (by grouping them).
The second trick (with tab characters in the URL) will work with Google redirectors.
Spammers also used various DNS tricks (round robin DNS entries, if one of their sites goes down they can redirect users to a different site).
The most interesting thing is why? It seems that spammers are trying to open new accounts on free webmail systems. Most of these systems today use CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart - http://www.captcha.net) to prevent bots from automatically opening accounts. Spammers use their spam targets to provide them with the data they need.
Thanks to Micha P, Danne, Andew H!
At the moment I am pretty sure that spammers
were using this "trick" to make users solve CAPTCHA graphics for them. In
this case, I believe they were trying to open new accounts on free webmail
www.pochta.ru (that's a legitimate Russian webmail). When you try to open a
new account on that site (http://www.pochta.ru/regform
presented with a CAPTCHA picture and it's link will be exactly
http://www12.pochta.ru/rnd_img
example).
Now, pochta.ru uses sid parameter to identify which CAPTCHA image will be
presented. The image itself will be changed (colors and number positions),
but the string that the user has to enter will remain the same. To test this
just enter the URL above in your browser and refresh couple of times - you
will see how it changes.
Therefore, spammers can build a big table of corresponding SID strings
(probably just hashes) and correct answers which enables them to
automatically open new accounts. This maybe even works on other sites if
they use same programs to generate CAPTCHA images.
END UPDATE
We received couple of reports of very strange phishing/spam e-mails.
They all share obfuscated text which is shown properly when rendered as a HTML. In the body of the e-mail the text is always similar to:
"Dear <domain> Member,
We must check that your <domain> ID was registered by real people. So, to help <domain> prevent automated, registrations, please click on this link and complete code verification process."
The link is, of course, hidden in the HTML and the displayed one is different from where the user will go when they click the link.
All of these e-mails use Google redirector techniques in order to defeat SURBL (Spam URI Realtime Blocklists). Some of the e-mails we saw also use multiple redirectors in order to defeat Google's anti-redirector script.
They are also frequently malformed and don't work at all, for example, one of the reports we received pointed to this URL (with spaces added by us to prevent clicking on it):
ht tp://www.go ogle.to/url?q=http://STaNdar TzA.Com/cgi -bin/p och/redir.cgi?s=<domain>
All e-mails always had recipients domain as the argument to the redir.cgi script. Also, most of the URLs are malformed and won't work (notice characters).
Some of the first e-mails that were submitted pointed to a different domain - standza.net. This URL was accessible for couple of hours and it didn't seem to do anything - it was probably used to collect IP addresses, or the author is/was still setting things up.
The domain which is used now, standartza.com is not resolvable, but is registered.
Thanks to Laurent D, Dan W, Guy R!
UPDATE
We received some very nice submissions about this.
First, in order to obfuscate their text, spammers use special Unicode formatting characters. The trick is to use "Right-To-Left Override" (RLO), so any text between two delimiters will be displayed backwards.
From the document at http://www.unicode.org/charts/PDF/U2000.pdf, and received phishing e-mails, we can see that those delimiters are ‮ and ‬. The reason for this is simple. Bayesian spam filters which don't render this properly will end up with weird tokens in their databases and the spammer can change tokens frequently (by grouping them).
The second trick (with tab characters in the URL) will work with Google redirectors.
Spammers also used various DNS tricks (round robin DNS entries, if one of their sites goes down they can redirect users to a different site).
The most interesting thing is why? It seems that spammers are trying to open new accounts on free webmail systems. Most of these systems today use CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart - http://www.captcha.net) to prevent bots from automatically opening accounts. Spammers use their spam targets to provide them with the data they need.
Thanks to Micha P, Danne, Andew H!
Keywords:
0 comment(s)
SSH scanning continues, some simple advice; IPS comparison article
www.intelguardians.com
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments