J Wolfgang Goerlich's thoughts on Information Security
Audit for SSL/TLS renegotiation

By wolfgang. 16 November 2009 14:43

An SSL/TLS renegotiation attack has been carried out against Twitter. The Register has some details on the Twitter attack, while Educated Guesswork has the technical details on the renegotiation vulnerability itself.

 

SSL/TLS renegotiation has been used to get a web server to downshift its cipher and key length before. The new angle is using renegotiation to cause both the web server and the browser to renegotiate and create a man-in-the-middle scenario. Once in the inserted in the middle of web server and browser, the attacker can access the HTTP stream unencrypted.

 

Being an IT operations security guy, my focus is on auditing for and protecting against the weakness. The mitigation is simple: disable renegotiation. As for auditing, you can use openssl on any Linux OS to test.

 

sudo openssl s_client -connect www.yourhosthere.com:443

 

You will see the certificate chain, server certificate, SSL handshake, and SSL session details. The session is established when you get prompted verify return code: 0 (ok).

 

Now suppose OpenSSL reports verify error:num=20:unable to get local issuer certificate.)I have seen this error on GoDaddy websites. To resolve, browse to the website with Firefox. Open the certificate viewer and click the details tab. There, below the details, click the Export button. Save the certificate file in the x.509 PEM format with a .pem extension (Example: godaddy.pem). Then rerun OpenSSL and specify the certificate authority file.

 

sudo openssl s_client -connect www.yourhosthere.com:443 –CAfile godaddy.pem

 

Make an HTTP request and then request renegotiation.

 

HEAD / HTTP/1.0

R

 

The error ssl handshake failure indicates the web server is denying renegotiations.  If OpenSSL renegotiates successfully, you will see a new certificate path and then read read:errno=0. Contact your web server administrator if the server renegotiates.

 

 

(Update 2009-12/18: You can use the Matriux distro to perform the above steps.)

Tags:

Apache | Cryptography | IIS | Security

Excel Extension Hardening and Web Applications

By wolfgang. 11 August 2009 20:19

In the classic ASP days, there were a few ways to deliver content to the client in Excel. The more difficult way was to install Office XP/2003 on the web server. Then the ASP code would use COM to bind to Excel, CreateObject("Excel.Application"), and create the workbook and sheets programmatically. This was a bit of work and required a second, separate block of code that duplicated in Excel the code that created the web page report.

Now since the primary web page report was generally a table, an easier way to export to Excel was to send the same Html table. The ASP code would simply switch the content MIME type, Response.ContentType = "application/vnd.ms-excel". Some developers went the extra step to specify the file name and extension, Response.AddHeader "content-disposition", "attachment;filename=Output.xls". You could also do the same for a .csv file using "text/csv" and "attachment;filename=Output.csv. " This was cleaner and meant that essentially the same code created both the Excel and the web output.

The trick worked as follows: Internet Explorer opened the web page, the web server returned Excel’s MIME type, Internet Explorer passed the file onto Excel, Excel opened it and converted the Html to the columns and rows the person expected. That the file extension (*.xls) did not match the file content (Html) was not really a concern. Excel did its trick and the content was displayed.

The problems began when attackers used the same trick to send malformed files thru Internet Explorer to Excel. Several security hotfixes addressed the various malformed spreadsheets (MS07-015, MS07-023, MS07-025, MS07-044, MS08-016, MS08-043, MS08-057, MS08-074). These all addressed the various ways Excel could be compromised by files with content other than well-formed Excel, but of course did nothing to prevent malformed Excel content in the first place.

To address this point, Excel 2007 introduced the concept of Extension Hardening.  Extension Hardening does checks ahead of time to ensure that the file content matches the extension and, if applicable, the MIME type. The upside of Extension Hardening is that it blocks one vector for malformed Excel content attacks. The downside is that it also breaks the classic ASP method of Excel reporting.

Further, there is no granularity in the setting. Extension Hardening cannot be turned off for some websites or content sources, and on for others. It can only be disabled, enabled with a prompt, or enabled with blocking. Extension Hardening can be controlled during installation by the Office Deployment files, or afterwards by group policy or editing the registry.

Registry:

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security]
"ExtensionHardening"=dword:00000000

Possible value settings: Allow different (dword:00000000); Allow different, but warn (dword:00000001); Always match file type (dword:00000002). If the 
ExtensionHardening value is not present, Excel defaults to Allow different, but warn.

Group Policy Administrative Template (Excel12.adm):

Node: Microsoft Office Excel 2007 \ Excel Options \ Security
Setting: Force file extension to match file type
Possible values when enabled: Allow different (dword:00000000); Allow different, but warn (dword:00000001); Always match file type (dword:00000002).

Microsoft Office Deployment:

Node: Microsoft Office Excel 2007 \ Excel Options \ Security
Setting: Force file extension to match file type
Possible values when enabled: Allow different (dword:00000000); Allow different, but warn (dword:00000001); Always match file type (dword:00000002).

Implications of the Setting:

1. When set to allow different, Excel 2007 behaves like Excel 2003 and opens files from the web with Html content and application/vnd.ms-excel MIME type.

2. The following dialog box will display for web content when Extension Hardening is set to allow different, but warn:

The file you are trying to open, 'filename.xls', is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?

3. The following dialog box will display for web content when Extension Hardening is set to always match file type:

Excel cannot open the file 'filename.xls' because the file format for the file extension is not valid. Verify that the file has not been corrupted and that the file extension matches the format of the file.

(In the warning dialog, you can press Ctrl-Shift-I to display the error code 101590 in the lower-right corner.)

For more information:

Microsoft Article 199841, How To Display ASP Results Using Excel in IE with MIME Types
http://support.microsoft.com/kb/199841

Microsoft Article 317719, How To Export Data in a DataGrid on an ASP . NET WebForm to Microsoft Excel
http://support.microsoft.com/kb/317719

Microsoft Article 948615, When you open a file in Excel 2007, you receive a warning that the file format differs from the format that the file name extension 
specifies
http://support.microsoft.com/kb/948615

 

 

Tags:

IIS | Security | Troubleshooting

Apache Versus Internet Information Services Security

By wolfgang. 29 March 2009 19:21

Fresh from a recent debate on Apache versus IIS security, I bring you this summary. I am not in a position to directly compare IIS versus Apache. When I build an IIS server, I am fairly confident in its security. If I were to build an Apache server, I would have little confidence due to my inexperience. So much depends upon the admin's skillset.

Quantitatively, Apache has more known vulnerabilities and attacks than IIS. IIS5 on Windows 2003 has 4 vulnerabilities. IIS6 on Windows 2008 has 1 published vulnerability. By contrast, Apache 2.0.x has 23 vulnerabilities.

The counter-argument to these statistics is this: most of the 23 vulnerabilities were in Apache modules. The attack surface drops significantly if you disable these modules. (And, of course, if you know how to disable the modules.)

Another counter-argument is that the web server depends upon the operating system. A determined attacker goes around your defenses rather than thru them. Thus I would suspect the security would turn more on the OS and the Web applications.

Secunia: IIS 6.x
http://secunia.com/advisories/product/1438/

Secunia: IIS 7.x
http://secunia.com/advisories/product/17543/

Secunia: Apache 2.0.x
http://secunia.com/advisories/product/73/

Tags:

Security | Apache | IIS

    Log in