Closed hrbrmstr closed 3 years ago
@bill-long appears it may give a different error code on 2013
I shot some more IPs (privately) in the event the redacted one above is a rly bad honeypot. I can provide as many as y'all need privately.
Here's the full response:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/8.0
request-id: acc04052-3c20-4618-a3e6-576a4878d890
Set-Cookie: ClientId=JBXW0OWZZDBRDW; expires=Mon, 07-Mar-2022 01:58:13 GMT; path=/; HttpOnly
X-CalculatedBETarget: localhost
X-CalculatedBETarget: localhost
X-FEServer: [redacted]
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sun, 07 Mar 2021 01:58:13 GMT
Content-Length: 1208
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>500 - Internal server error.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>500 - Internal server error.</h2>
<h3>There is a problem with the resource you are looking for, and it cannot be displayed.</h3>
</fieldset></div>
</div>
</body>
</html>
So same code, different body.
Thanks, I'm working on looping in the team that did the nmap work.
It's fixed with this PR that now looks at the X-CalculatedBETarget response header: https://github.com/microsoft/CSS-Exchange/pull/114
Are Exchange 2007 systems vulnerable? I did a test against a small subset of Exchange 2007 systems and the script does not identify them as vulnerable. (shared IPs privately again)
I've got same result as @hrbrmstr checking Exchange 2016 CU14:
nmap -p 443 --script http-vuln-cve2021-26855 x.x.x.x
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 1.03 seconds
What does that mean?
That Exchange server was already updated as I know, so I cannot do some additional tests anymore.
By the way, on a fully updated Exchange server nmap shows absolutely the same result. Maybe it should say something like "NOT VULNARABLE".
That means it is not vulnerable (in reference to last post).
On Sun, 7 Mar 2021 at 11:53, arddg notifications@github.com wrote:
I've got same result as @hrbrmstr https://github.com/hrbrmstr checking Exchange 2016 CU14:
nmap -p 443 --script http-vuln-cve2021-26855 x.x.x.x
PORT STATE SERVICE 443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 1.03 seconds
What does that mean?
That Exchange server was already updated as I know, so I cannot do some additional tests anymore.
By the way, on a fully updated Exchange server nmap shows absolutely the same result. Maybe it should say something like "NOT VULNARABLE".
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/CSS-Exchange/issues/107#issuecomment-792265060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGBLH5E2TOAMTWEGB6UEH3TCNSNLANCNFSM4YXKBOGA .
@GossiTheDog, Just to clarify, I was talking about same results on Exchange 2016 CU14 and Exchange 2016 CU19 with all updates installed. Are you saying that Exchange 2016 CU14 is not vulnerable too?
Are Exchange 2007 systems vulnerable? I did a test against a small subset of Exchange 2007 systems and the script does not identify them as vulnerable. (shared IPs privately again)
Per proxylogon.com, Exchange 2007 and 2010 are not affected as the Client Access Service has a different architecture.
@bill-long @justinhendricksmsft I think @arddg above has a point, it looks like if you point the script against Exchange 2016 CU14 (may other versions, haven't checked) it says not vulnerable - but there's no SU for 2016 CU14.
I'm pondering if it's worth building code to check short build number as an additional check.
@GossiTheDog @arddg Do you happen to have an example redacted http response? I just installed Exchange 2016 CU14 and it worked so it must be something with the setup.
What will is show if it is vulnerable? There needs to be a better explanation in the notes. :-)
I haven't done a complete analysis, but the following is a header from an Exchange 2013 server (I won't put the IP here as it's very likely a real server, but I've shared it with @GossiTheDog:
That's an "Exchange Server 2013 Cumulative Update 21 (CU21)" server and the NSE returns:
Is it really possible some old, outdated versions of Exchange are not vulnerable?