[NT] Multiple .NET NULL Byte Injection Vulnerabilities (MS07-040)



The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Multiple .NET NULL Byte Injection Vulnerabilities (MS07-040)
------------------------------------------------------------------------


SUMMARY

Multiple NULL byte injection vulnerabilities have been discovered in
Microsoft's .NET framework, these vulnerabilities allow information
disclosure on Web servers running ASP.NET as well as in several cases
where users whose accounts are configured to have fewer user rights on the
system could be less impacted than users who operate with administrative
user rights.

DETAILS

Vulnerable Systems:
* .NET FrameWork version 1.1 SP1
* .NET FrameWork version 2.0.50727

Security-Assessment.com recently completed research into the .NET
Framework in relation to the affect a NULL byte (%00) has on various
aspects of the .NET Common Language Runtime.This advisory details the
findings of that research conducted by Paul Craig
Paul.Craig@xxxxxxxxxxxxxxxxxxxxxxxx

It was found that certain .NET methods in various sections of the .NET
namespace are vulnerable to NULL byte injection attacks. NULL byte
injection occurs when the .NET CLR incorrectly handles user supplied NULL
bytes.

The .NET CLR considers NULL bytes as 'data', .NET strings are not NULL
byte terminated. However, native POSIX compliant function calls terminate
all strings at the first found NULL byte. Interoperability issues are
encountered when data containing a NULL byte is used by .NET to directly
call a native C function call.

Native function calls terminate strings at the injected NULL byte allowing
a remote user to arbitrarily terminate a string
parameter used by the vulnerable method.

Security-Assessment.com has discovered five vulnerable methods in the .NET
framework which are exploited through NULL byte injection. Three of the
discovered vulnerabilities allow strings to be arbitrary terminated
through String Termination vulnerabilities. The remaining two resulted in
an Arbitrary File Disclosure condition where a remote user is capable of
accessing arbitrary files from within the web root.

NET has a history surrounding NULL byte input flaws and associated logic.
On September 8th, 2003 WebCohort Research <research@xxxxxxxxxxxxx>
released an advisory titled "Microsoft ASP.NET Request Validation NULL
Byte Filter Bypass Vulnerability". Where by the .NET request validation
routine could be bypassed when using a NULL byte injection.

NULL byte injection is not a new class of attack, and is a well known
exploitive method but this is the first time a NULL byte
injection vulnerability has been found in methods within the .NET
framework. Security researchers should be aware of NULL byte injection
attacks within the framework itself and .NET developed applications.

Exploitation:
The following examples can be found at <http://ha.cked.net/examples.zip>
http://ha.cked.net/examples.zip

Exploit 1: Server.MapPath
A NULL byte injected within the filename parameter of the Server.MapPath
method will terminate any returned string, removing any string data
concatenated to the user supplied value.

This can be seen in example 1 below.

name = test.aspx%00

Sub Page_Load()
dim name as string
dim realname as string
name = request("name") & ".uploaded"
realname = Mappath(".") & "\" & name
response.write("Mappath value of name variable: " & MapPath(name)
& "<br>")
response.write("The real value is: " & realname & "<br>")
End Sub

Output:
Mappath of name variable = C:\Inetpub\exploit1\test.aspx
The Real value is : C:\Inetpub\exploit1\test.aspx.uploaded

1. Two variables are assigned, name and realname.

2. Name is a user supplied filename, and for security reasons .uploaded is
appended to this value.

3. Real name is the virtual path for the current directory, with the name
variable appended (This is the correct location of the file)

4. Inserting a NULL byte suffix into the 'name' variable
(name=test.aspx%00) is able to terminate the string returned from MapPath
and any data concatenated to the user supplied value is removed.

Exploit 2: Server.Execute and Server.Transfer
Server.Execute and Server.Transfer were found to both be vulnerable to
NULL byte injection. Here the NULL byte produces an arbitrary file
disclosure vulnerability.

If a remote user is able to control the input used in a Server.Execute or
Server.Transfer method, the method can be used to disclose the contents of
any file within the document root. As seen in example 2, below.

Sub Page_Load()
Server.Transfer(request("page"))
End Sub

Security-Assessment.com has witnessed Server.Transfer and Server.Execute
being used in page redirection functionality where .NET sessions are
transferred to a user supplied page variable.

According to MSDN:
"The page transferred to should be another .aspx page. For instance, a
transfer to an .asp or .asmx page is not valid. The Transfer method
preserves the QueryString and Form collections."

If a user attempts to transfer to web.config, or any other none .ASPX page
an exception is created. However, when the page variable is suffixed with
a NULL byte the complete file contents of the page is returned to the
remote user.

A Server.Transfer or Server.Execute to page=web.config%00 will display the
contents of the web.config file.

This vulnerability can also be used to view any file within the document
root.

Exploit 3: String.Compare
String.Compare was also found to be affected by NULL bytes. Although does
not produce an exploitable condition. String.Compare demonstrates .NET's
inability to correctly handle NULL bytes.

This is demonstrated in the example below.

Sub Page_Load()
dim allowed, sFirstItem, sSecondItem as string
sFirstItem = Request("first")
sSecondItem = Request("second")
response.Write ("String.Compare - First item = " & sFirstItem &
"<br>")
response.Write ("String.Compare - Second item = " & sSecondItem &
"<br>")
if String.Compare(sFirstItem, sSecondItem) =0 then
response.Write ("<b>String.Compare - Matched! Strings are
the same</b>" & "<br>")
else
response.Write ("<b>String.Compare - FAILED!! Strings are
not the same</b>" & "<br>")
End If
if sFirstItem=sSecondItem then
response.Write ("Direct eval - Matched! Strings are the
same" & "<br>")
else
response.Write ("<b>Direct eval - FAILED! Strings are not
the same</b>" & "<br>")
End If
End Sub

1. Two variables are supplied, "first" and "second"
2. String.Compare is called to compare the two strings, and then a direct
evaluation is performed.
3. String.Compare should act identically to a direct evaluation.
4. The result of first=test&second=test can be seen below.

String.Compare - First item = test
String.Compare - Second item = test
String.Compare - Matched! Strings are the same
Direct Eval - Matched! Strings are the same

This is the correct response, as both the first and second were defined as
'test'

5. Now, add a NULL byte suffix to the 'first' variable and try again. The
result of Example3.aspx?first=test%00&second=test can be seen below.

String.Compare - First item = test
String.Compare - Second item = test
String.Compare - Matched! Strings are the same
Direct Eval - Failed! Strings are not the same

String.Compare terminates the string at the first NULL byte, and the two
values are seen as identical. However direct evaluation correctly
determines that they are different, due to the extra NULL byte suffix.

Although this is not exploitable it is an interesting finding.

Exploit 4: System.Net.Mail.SmtpMail.Send
The object System.Net.Mail.SmtpMail.Send was found to be vulnerable to
string parameter termination similar to the vulnerability discovered in
Server.MapPath.

This is demonstrated in the example below.

Private Sub Page_Load(sender As Object, e As System.EventArgs)
Dim m As New MailMessage()
m.From = "securityguy@xxxxxxxxxxxxxxxxxxxxxxx"
m.To = request("to") & "@security-assessment.com"
m.Subject = request("subject") & ": FromWebsite"
m.Body = request("body") & "This message was submitted by a user."
Response.Write("Sending mail to: " & m.to)

m.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate";, "1")

m.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendusername";, "username")

m.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendpassword";, "password")
SmtpMail.SmtpServer = "mail.server.com"
SmtpMail.Send(m)
End Sub

In this example the recipient property (To) is defined as a user supplied
variable with @security-assessment.com concatenated.
Security-Assessment.com has seen this development technique being used to
ensure mail is only be sent to users of a particular domain.

However, if a user supplies a recipient (To) variable as
paul.craig@xxxxxxxxxxxxx%00 the mail will be sent to the Microsoft.com
domain and string is again terminated at the first NULL byte removing the
concatenated "@security-assessment.com" value.

Similarly the From, Subject and Body values were found to be vulnerable to
the same method of NULL byte injection

Solutions:
Security-Assessment.com has been in contact with Microsoft and a new .NET
patch has been released to address the discovered vulnerabilities. Install
patch KB928365 (Security Update for Microsoft .NET Framework 2.0) and/or
KB928366 (Security Update For Microsoft .NET Framework 1.1)


ADDITIONAL INFORMATION

The information has been provided by
<mailto:paul.craig@xxxxxxxxxxxxxxxxxxxxxxx> Paul Craig.
The original article can be found at:
<http://security-assessment.com/files/advisories/2007-07-11_Multiple_.NET_Null_Byte_Injection_Vulnerabilities.pdf> http://security-assessment.com/files/advisories/2007-07-11_Multiple_.NET_Null_Byte_Injection_Vulnerabilities.pdf



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages

  • Multiple .NET Null Byte Injection Vulnerabilities
    ... .NET namespace are vulnerable to Null byte injection attacks. ... Three of the discovered vulnerabilities allow strings to be ... arbitrary terminated through String Termination vulnerabilities. ... if a user supplies a recipient variable as ...
    (Bugtraq)
  • [Full-disclosure] Multiple .NET Null Byte Injection Vulnerabilities
    ... .NET namespace are vulnerable to Null byte injection attacks. ... Three of the discovered vulnerabilities allow strings to be ... arbitrary terminated through String Termination vulnerabilities. ... if a user supplies a recipient variable as ...
    (Full-Disclosure)
  • Re: Vulnerability Auditing Checklist
    ... CAN-yyyy-nnnn) for specific vulnerabilities that demonstrate the given ... suite-based testing, and fault injection. ... symlink following bugs are the combination of multiple ... e.g. checking a security option does nothing, ...
    (SecProg)
  • [NEWS] SAP DB Privilege Escalation/Remote Code Execution
    ... Get your security news from a reliable source. ... which is sponsored by SAP AG. ... There exists a number of vulnerabilities in the core SAPDB code that allow ... // destination string length leading to a buffer overflow. ...
    (Securiteam)
  • [UNIX] Mailman Multiple Security Issues
    ... Get your security news from a reliable source. ... Mailman is "a mailing list server. ... Mailman is subject to multiple security vulnerabilities, ... cross site scripting to log file injection. ...
    (Securiteam)