We scanned our website for vulnerabilities and received the message shown below.
We used Clover Security to scan the Azure Web App site.
We have already implemented the solution in web.config shared on the Internet and by Microsoft on these websites:
https://azure.microsoft.com/en-us/blog/removing-standard-server-headers-on-windows-azure-web-sites/
https://learn.microsoft.com/en-us/answers/questions/28434/azure-app-service-how-to-block-msdeployaxd-on-port.html
As discussed in the last url, I have also re-created a new resource group, app service plan and app services and redeployed on in a different US location but the error still shows on re-scan.
Any suggestion on how to fix this would be greatly appreciated?
Thank you in advance.
------------------------------ Error Message Provided ( our ip has been x'd out) --------------------------------
Category Web Application
CVE -
CVSS base score 5.0
Description Web Server Information Disclosure
Host xx.xx.xxx.xx
Threat -
Impact -
Solution -
PCI compliant No
PCI details -
Reason The vulnerability is not included in the NVD.
PCI details medium
Port 8172 / tcp
Host name No registered hostname
Host OS Windows Vista / Windows 2008 / Windows 7 / Windows 2012 / Windows Vista / Windows 2008 / Windows 7 / Windows 2012
Result
url: https://xx.xx.xxx.xx:8172/
comment: Web Server Information Disclosure detected at PORT : 8172
matched: HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/10.0
Date: Thu, 23 Jun 2022 08:20:52 GMT
Connection: close
Content-Length: 103
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
CVSS Base Score 5.0 - - AV:N/AC:L/Au:N/C:P/I:N/A:N
CVSS Temporal Score 4.3 - E:POC/RL:W/RC:C
Severity 2
Category Web Application
CVE ID
Vendor Reference
Bugtraq ID
Date Updated Jun 1, 2022
Threat The target application discloses the Web Server software version via the "Server:" token sent in HTTP response header.
QID Detection Logic:
This QID sends a GET request to the target application and determines the Web Server version disclosed in the "Server:" token.
Impact Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.
Solution Customers are advised to modify the HTTP response header of the target application to not disclose detailed information about the underlying web server. Server implementers are encouraged to make this field a configurable option.
You need to raise this as a false positive, as the failing scan is for port 8172. This is part of Azure's services infrastructure and isn't removable or editable. You might also get false positives for ports 455 and 454 on the same IP address. When you create the false positive claim, you need to let your PCI scan provider that these ports are not accessible nor for use by the general public. You will also need to "confirm" that there is no CHD (Cardholder data) being transmitted through those ports/services.
We recently noticed that the connect notifications stopped working. We do have DocuSign Connect Settings enabled to post back to our server when an Envelope is singed/completed.
The last successful one was received on May 22nd 2018 and I don't see any failures.
Can someone look into it and advise?
Thanks in advance.
For this you might want to open a case with DocuSign Support and provide them the Demo Account ID. There's most likely an error your server is returning and if Require Acknowledgement is off it won't be logged on the DocuSign side.
What software stack does your server (your "listener") use?
Only TLS 1.1 or better is currently allowed by DocuSign Connect.
See the support article. Does your server support TLS 1.1 or 1.2?
I am trying to connect Azure to our OnPremise-SAP-Installation. Our target: calling an RFC via SAP-Connector within a LogicApp.
What we did so far:
Created a Relay-ServiceBus.
Created a default SAP-Connector available in Azure Marketplace and inserted all required information including the ServiceBus-ConnectionString.
For testing purpose: Created a new Windows Server VM onPrem:
Enabled IIS
Disabled Windows-Firewall
Installed SAP-Libraries required by the HybridConnector.
Than we downloaded and installed the HybridListener on the Windows Server and entered the required ConnectionString.
Basically it was pretty much straight-forward according to this article:
http://azure.microsoft.com/de-de/documentation/articles/app-service-logic-integrate-with-an-on-premise-sap-server/
(Maybe except installing the SAP Libraries which is a bit weak documented..)
After all that installation process we went back into our Azure Portal. Suprisingly the SAP-Connector still told us: "On-Premise Setup Incomplete"
Our biggest problem: there are no other information available. Why is the Setup incomplete? Did we entered some wrong configuration or is there a network issue?
After some time we found out that we also need to open the following outgoing ports:
9350 to 9354
443
Unfortunately this was documented at a different place: https://msdn.microsoft.com/en-us/library/azure/ee706729.aspx
But the connection is still not working, same error as above: "On-Premise Setup Incomplete" And yes, we did reboot the IIS as well as the whole system.
My Question now: is there any possibilty to find the reason for this situation? A couple of weeks ago we had the same issue with an SharePoint-Connector which is still not running.
Is there any kind of HybridConnector-Logfile on the Server or something similar that helps us the figure out the real problem? Or maybe did someone had the same problem in the past and has some advice?
Thanks in advance!
EDIT: Hybrid Connection is now online!
I just had to change writing permissions for the HybridListenerAppPool:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Aspnet_regiis.exe -ga "IIS AppPool\HybridListenerAppPool"
Solution found: http://forums.asp.net/t/1566987.aspx and IIS7 folder permissions for web application.
But it is still not possible to use the SAP Connector within a LogicApp:
After analyzing the Log of the AppService Gateway I found a hint telling me to look at the SwaggerFile of the SAP Connector:
I really do not understand why the HybridConnection is fine but there is still no Listener connected.
After some firewall forensics, we actually figured out that there is some outgoing traffic on ports 5671 and 5672. If someone else faces the same problem, you need to open all the following outgoing TCP ports:
443
5671 - 5672
9350 - 9354
Unfortunatley it looks like this is not documeted at all.
I'am developing an industrial application based on an open source DHCP client.
I am setting a custom DHCP client class id (DHCP Option 77)
ipconfig /setclassid "Local Area Connection" "SOME_CUSTOM_CLASS_ID"
and in Wireshark I am capturing the DHCP handshake. The custom class id is present in the DHCP request, but wireshark has the Option 77 info highlighed with the error "malformed option".
Referring to RFC 3004 standard i found that each instance of user class data should have a 1 octet prefix of the length that can fixe the problem and dismiss DHCP all wireshark error.
The problem know is that some version of wireshark detect this error like version 1.10.6 other version can't detect like version 1.6.5.
Any ideas on this? Is it a bug in Wireshark ?
First:
Dissection of DHCP Option 77 was first included in Wireshark 1.10 so Wireshark 1.6 and Wireshark 1.8 don't know about this option and thus don't show any error specifically about that option.
Second:
I'm a bit unclear as to your question:
Are you asking why Wireshark 1.6 doesn't show an error which is correctly shown in
Wireshark-1.10 ?
If so, please see 'First' above.
if not please clarify.
Microsoft introduced an incompatible format which is described at 2.2.6.1 User Class Option Sent by DHCPv4 Client to DHCPv4 Server. The format is now:
Option Code (77)
Option Length
User_Class_Data (variable length)
Wireshark only supports the RFC 3004 format in Wireshark 2.0 (and I guess also the upcoming 2.2). For more details on various implementations, see this ask.wireshark.org.
I have a classic ASP website running on a Windows Server 2012 box. One page makes a HTTP request to another application over https using code like this:
Sub ShopXML4http(url, inStr, outStr, method, xmlerror)
Dim objhttp
Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
objHttp.open method, url, false
If Method="POST" Then
objHttp.Send instr
Else
objHttp.Send
End if
outstr=objHttp.responseText
Set objhttp=nothing
End Sub
This code works fine almost all of the time (thousands of requests per day), but sporadically it will fail with a message like this:
Number: -2147012739
Description: An error occurred in the secure channel support
Source: msxml6.dll
The application was recently moved from an old Windows 2003 Server to the 2012 Server, and this issue never seemed to be a problem on the old server. In addition, while this error is happening on the website, I could run the exact same code in a VBScript and it works fine. Resetting the application pool seems to cause the site to be able to do the secure HTTP requests again (although it often fixes itself before I can get to the server).
I have had the exact same problem after migrating from 2003 to 2008 R2 and found the solution. Change:
Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
to:
Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")
and your problem will go away.
I tried to find the pros and cons about both objects, but haven't yet found a reason to not use XMLHTTP.
I've had the same issue and tried lots of solutions offered under a variety of posts but ultimately had no success, until now. I'll detail the solution that worked for me with reference to the problem as in my case it was PayPal. I've not opened a new post as this might not be just a paypal issue in future.
The solution is a combination of a number of stackoverflow posted solutions to similar problems but this seemed the best one to add to.
The problem
Trying to test PayPal IPN on Windows Server 2008 using classic ASP using the PayPal Sandbox returns the error "An error occurred in the secure channel support".
Why it is a problem
PayPal is requiring all communications with their systems to be as secure as possible. You will need a connection that is TLS 1.2. Windows Server 2008 is not TLS 1.2 by default.
PayPal threw some confusion into the mix by saying you need a Verisign G5 certificate, which you do for the server root but not the domain you are running your code on. I also didn't install any PayPal certificates as I don't use the API. I don't believe you need your comms from an HTTPS site either - although my domain is secured using a standard GoDaddy EV cert although I did a test on a non HTTPS site after and that worked too.
My solution
First check which kind of security your server is using via SSL Labs.
It should be TLS1.2 or higher and no other TLS's or SSL's. It must also have a SHA256 encryption.
You may need to patch the server: https://support.microsoft.com/en-us/kb/3106991.
Use IISCrypto to set the correct TLS and ciphers. I used the registry changes offered up elsewhere on stackoverflow but this did not work and actually totally screwed up my server for everything using HTTPS posts, not just my development site! IISCrypto also handles the ciphers.
Make sure your application pool is v4.5, which in itself is unclear because IIS might only offer v4.0 as an option. However this is probably actually v4.5. You can verify this via https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx.
Within your code you need to use Server.CreateObject ("MSXML2.XMLHTTP.6.0"), not Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") as mentioned above.
Now I've no idea why the non-server XMLHTTP works as that seems contrary to the documentation behind it. Right now, after 10 days of stress, panic and frustration I don't care! I hope this is useful for others.
Finding the solution was a nightmare so I'll add some phrases below to help others if searching:
PayPal IPN failing with server error
PayPal SSL Windows 2008 errors
An error occurred in the secure channel support
classic ASP PayPal Sandbox SSL errors
I'd like to publicly thank Rackspace and GoDaddy for their help with this. I'd like to publicly state that I found paypal have the worst technical support ever and just do not care, constantly pointing to their own docs, if they ever respond. They say they've been sending emails out about this since September 2014 but I never received one. These new requirements are active on the PayPal Sandbox but go live in September 2016. I only came across it as developing a new solution so needed the sandbox - if you're running live you won't know about the problem until it hits and then you're dead in the water. Test your entire payment system on the PayPal sandbox asap is my advice!!
None of the answers above applies to my situation. Then I hopped on the link here:
https://support.microsoft.com/en-za/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
This update provides support for Transport Layer Security (TLS) 1.1 and TLS 1.2 in Windows Server 2012, Windows 7 Service Pack 1 (SP1), and Windows Server 2008 R2 SP1.
Applications and services that are written by using WinHTTP for Secure Sockets Layer (SSL) connections that use the WINHTTP_OPTION_SECURE_PROTOCOLS flag can't use TLS 1.1 or TLS 1.2 protocols. This is because the definition of this flag doesn't include these applications and services.
This update adds support for DefaultSecureProtocols registry entry that allows the system administrator to specify which SSL protocols should be used when the WINHTTP_OPTION_SECURE_PROTOCOLS flag is used.
This can allow certain applications that were built to use the WinHTTP default flag to be able to leverage the newer TLS 1.2 or TLS 1.1 protocols natively without any need for updates to the application.
This is the case for some Microsoft Office applications when they open documents from a SharePoint library or a Web Folder, IP-HTTPS tunnels for DirectAccess connectivity, and other applications by using technologies such as WebClient by using WebDav, WinRM, and others.
This update will not change the behavior of applications that are manually setting the secure protocols instead of pass the default flag.
Client service on Windows 2008 R2 server outbound to server over TLS reciprocated the error in question. I thought it could be cipher suite compatibility. Wireshark trace indicated version in Client Hello request was TLS 1.0 but server requires TLS 1.2. The cipher suites sent to outbound server from client service were fine. The problem is the client service or application on Windows server default employs the system default, which is not TLS 1.2.
The solution is to add a registry subkey named DefaultSecureProtocols with a value corresponding to which TLS version(s) should be supported. Add said registry subkey, with type DWORD, to the following locations:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
For Internet Explorer fix, you can add a similar registry subkey titled SecureProtocols, also with type DWORD, to the following locations:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Below you can find the table of values for both subkeys:
DefaultSecureProtocols Value Protocol enabled
0x00000008 Enable SSL 2.0 by default
0x00000020 Enable SSL 3.0 by default
0x00000080 Enable TLS 1.0 by default
0x00000200 Enable TLS 1.1 by default
0x00000800 Enable TLS 1.2 by default
For example:
The administrator wants to override the default values for WINHTTP_OPTION_SECURE_PROTOCOLS to specify TLS 1.1 and TLS 1.2.
Take the value for TLS 1.1 (0x00000200) and the value for TLS 1.2 (0x00000800) then add them together in calculator (in programmer mode), the resulting registry value would be 0x00000A00.
I applied 0x00000A00 as the value for both subkeys and it successfully resolved the issue.
There is also an Easy Fix (link is here: https://aka.ms/easyfix51044) available from Microsoft, if you don't wish to manually enter registry subkeys and values.
It's all valid however the 'critical' missing bit for TLS1.2 support on Windows 7 with IIS7.5 and classic asp is setting this in the registry:-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800
I hope that saves you a day of faffing, rebooting and head scratching! :)
This code snippet is useful for testing. https://www.howsmyssl.com/
<%
Set winhttp = Server.CreateObject("WinHTTP.WinHTTPRequest.5.1")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText
%>
In a Windows Server 2016 Classic ASP script, fetching an HTTPS URL from Windows Server 2012 R2, I recently had to remove SSL 2.0 from SecureProtocols in order to stop this secure channel error -2147012739.
' Use the latest client
Set httpClient = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
' allow only TLS 1.2 or TLS 1.1
Const WHR_SecureProtocols = 9
httpClient.Option(WHR_SecureProtocols) = &h0800 + &h0200
' Other values: TLS 1.0 &h0080, SSL 3.0 &h0020, SSL 2.0 &h0008
' NB Including SSL 2.0 stops https to Windows Server 2012 R2 working
' Other options you may want to set, from https://learn.microsoft.com/en-us/windows/desktop/winhttp/winhttprequestoption
' Ignore certificate errors
Const WHR_SslErrorIgnoreFlags = 4
httpClient.Option(WHR_SslErrorIgnoreFlags) = &h3300
' Don't bother checking cert, or risking failure if we can't check
Const WHR_EnableCertificateRevocationCheck = 18
httpClient.Option(WHR_EnableCertificateRevocationCheck) = False
Troubleshooting error codes:
-2147012739 is a HRESULT.
In hexadecimal that's 0x80072F7D.
Look at the LOWORD: 0x2F7D.
Convert that back to decimal: 12157.
Lookup 12157 error codes.
Find that it matches: ERROR_WINHTTP_SECURE_CHANNEL_ERROR
A bit of Google-fu finds http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770(v=vs.85).aspx which states:
ERROR_WINHTTP_SECURE_CHANNEL_ERROR
12157
Indicates that an error occurred having to do with a secure channel (equivalent to error codes that begin with "SEC_E_" and "SEC_I_" listed in the "winerror.h" header file).
However, you already discovered this as the message you got was "Description: An error occurred in the secure channel support". So this leads us right back where we started.
The other observation I make is that your code is a non-asynchronous WinHTTP request (I know it has to be to function inside ASP), but, the concern is, due to the high frequency, your machine could be processing more than one WinHTTP request concurrently. I've seen some Windows deliberately throttle the total number of active concurrent WinHTTP request by blocking the late requests. For example, on a Windows 7 machine a process cannot make more than 2 concurrent requests to the same remote server. i.e. The 3rd, 4th... requests will be blocked until the first two complete.
One solution is to load balance incoming request over more than one application pool or over more servers.
We had a variation on this issues and it really cost us some time to figure it out.
Here is the situation: An older Linux server hosting an application written in PHP and provides data through webservice calls. The server is using HTTPS. Calls from various clients are made with code using the winHTTP 5.2 library. (Winhttp.dll)
Symptom: Our clients are now getting sporadic error messages when making repeated winHTTP calls using a ‘POST’ command. The messages are either ‘The buffers supplied to a function was to small.‘ or ‘An error occurred in the secure channel support ‘. After much searching we discovered that the client’s server was logging ‘Schannel Event ID 36887 alert code 20’ in the Event Viewer that corresponded with the visible error message.
Solution: We discovered that our old Linux server could not support TLS 1.2. (CentOS 5.11) We also learned that several of our clients had recently (summer 2016) applied an update to their Microsoft servers. (Server 2008, server 2012) The fix was to force their servers to use TLS 1.1 for the webservice calls. The part that is rather strange to me is that the settings in Internet Explorer for changing the TLS had no effect on the problem. However by changing a setting in Group Policies we were able to solve the problem. Our technical advisor on this matter pointed out that the change is really obscure, but that a third-party vendor has provided a quick solution. That tool is called IIS Crypto from Nartac. https://www.nartac.com/Products/IISCrypto/Download
The tool lets you specifically select Protocols.
We are now getting a new server to host our applications (CentOS 6) and then should be able to use the TLS 1.2 protocol!
I encountered this error a few months ago myself. Most often, this issue is caused by an invalid SSL cert. Considering that at the time of the post you had just migrated to a new server, you probably just need to reinstall the SSL certificate.
I realize this question is old, but hopefully someone else can benefit from my answer.