Hi People,
We have report from our security team saying below:
The Web server contains a flaw that may allow a remote attacker to delete arbitrary files by using the HTTP method ‘DELETE’, resulting in a loss of integrity.
Do we have any way to do at webMethods IS level?
Regards,
Sanket Pandey
There are some extended settings have a look at the admin guide.
watt.server.http.allowOptions
watt.server.cors.supportedMethods
watt.server.cors.***
Hi Sanket Pandey,
If you believe you have found a vulnerability in Integration Server, please contact Software AG Customer Support and share the details with them.
Thanks,
Michael Scalia
Thanks a lot for your quick inputs.
I have found the below property with “DELETE” as one of the methods, let me remove it and see how the security team comes with their feedback.
watt.server.cors.supportedMethods
Regards,
Sanket
Hi All,
They are still reporting the issue when we have below said extended settings:
watt.server.cors.allowedOrigins=
watt.server.cors.enabled=false
watt.server.cors.exposedHeaders=
watt.server.cors.host=
watt.server.cors.maxAge=-1
watt.server.cors.supportedHeaders=
watt.server.cors.supportedMethods=GET,POST,PUT,OPTIONS,HEAD
watt.server.cors.supportsCredentials=false
watt.server.fileEncoding=UTF-8
watt.server.http.allowOptions=true
Regards,
Sanket
Contact SAG support they should be able to assist you further.
Just curious:
Have you also restarted the IS after the setting changes? Please try this option as well if you have not done so.
Also check this Empower KB article to tackle this similar request:
======================
Proposed Resolution from the above article:
Microsoft Windows MHTML Cross-Site Scripting
This seems to be related to PIE-20299. The attack location is the only difference. Let me check and get back.
Insecure HTTP Methods Enabled
There is a watt property in Integration server ?watt.server.http.allowOptions? which is set to true by default, change it to false and restart IS the OPTIONS method will not be supported thereafter.
Also, check watt property ?watt.server.cors.supportedMethods=GET,POST,PUT,DELETE,OPTIONS,HEAD? .
Missing Secure Attribute in Encrypted Session (SSL) Cookie Use the below watt property watt.server.http.header.useSecure Specifies whether Integration Server includes the secure attribute in the Set-Cookie header in the response to an HTTP/S client. When the watt.server.http.header.useSecure property is set to true (the default), Integration Server includes the secure attribute in the Set-Cookie header of the HTTPS response to an HTTP/S client. Software AG recommends setting this property to true because it ensures that the cookie is always encrypted while being transmitted from client to server.
Weak SSL Cipher Suites are Supported
It can be controlled by watt.net.ssl.server.strongcipheronly and watt.net.ssl.server.cipherSuiteList
======================================
HTH
RMG
Thanks a lot for your inputs!
Yes, I did restarted the IS after removing the DELETE option from - watt.server.cors.supportedMethods
Please find the extended properties which might be relevant here:
watt.server.cors.allowedOrigins=
watt.server.cors.enabled=false
watt.server.cors.exposedHeaders=
watt.server.cors.host=
watt.server.cors.maxAge=-1
watt.server.cors.supportedHeaders=
watt.server.cors.supportedMethods=GET,POST,PUT,OPTIONS,HEAD
watt.server.cors.supportsCredentials=false
watt.net.ssl.server.strongcipheronly=true
watt.net.ssl.server.cipherSuiteList=default
watt.net.jsse.client.enabledCipherSuiteList=default
Regards,
Sanket
Sanket,
OK understood.
Did you look at the empower article referenced above and try that resolution route as well?
HTH,
RMG
Hey RMG,
from the article, I can’t make out anything out of point 1, but I have missed one change which is I have made now:
watt.server.http.allowOptions=false
And asked the security team to run the scan further and this time instead of OLD:
The Web server contains a flaw that may allow a remote attacker to delete arbitrary files by using the HTTP method ‘DELETE’, resulting in a loss of integrity.
New warning is:
TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32)
TLS/SSL Server Supports 3DES Cipher Suite
Let me see for thse tw now 
Regards,
Sanket
Those attacks based on weak ciphers you best block on JVM level in the java.security file.
Let your security team provide you a list what to block. Using latest JVM (and fixes) is definitely also a good idea.
Oracle / Zulu block a lot weak content already by default.
Hi,
check your extended settings for watt.net.ssl.<client|server>.strongCipherOnly and set these to true.
Set watt.net.client.useJSSE to true and configure your HTTPS-Port to use JSSE (= Yes).
Regards,
Holger
Thanks Holger,
All the above said is already in place in our servers (IS)
Regards,
Sanket
Hi Sanket,
in this case you should additionally check for the allowed protocols settings for JSSE and remove older SSL and TLS versions only leaving TLSv1.2 active, which is hopefully available for all partners you are integrating with.
Regards,
Holger
Hi Holger,
That’s already there:
watt.net.jsse.client.enabledProtocols=TLSv1.2
watt.net.jsse.server.enabledCipherSuiteList=default
watt.net.jsse.server.enabledProtocols=TLSv1.2
watt.net.ssl.client.cipherSuiteList=default
watt.net.ssl.client.handshake.maxVersion=tls
watt.net.ssl.client.handshake.minVersion=tls
Regards,
Sanket