Question: Security Threat OSS Note 2067859

[petr_solberg]

Good Afternoon All,

question, OSS Note 2067859 describes a security vulnerability, and if you read the OSS Note,

PLEASE do not quote the OSS Note here, just read it,

if you read the OSS Note it says in the Symptom...

     used by SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP and SAP HANA applications

we are debating, did the author intend this to mean,

a)

     SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP

          and

     SAP HANA applications

     (therefore meaning this vulnerability, if you have the described setup, would affect every ABAP Stack [regardless of db]

     in your landscape where you have that setup)

or, did the author intend this to mean,

b)

     SAP NetWeaver Application Server (SAP NetWeaver AS)

          for ABAP and (SAP) HANA (applications)

     (therefore meaning this vulnerability, if you have the described setup, would affect your systems where you

     have an ABAP Stack on Hana db)

What does the jury think, is it a) or b) ?

Please as requested do not publish here any more details from the OSS Note than have already been given.

Best regards,

Andy.

[Former Member · Accepted solution]

My interpretation:

All ABAP application server systems regardless of library.

All HANA systems regardless of library.

...and all JAVA application servers which are not using the cryptolib -> ie. JAVA servers with seculib.

The last sentence of the note is also important, incase you had trouble or disbelief in interpreting what you have to do there...

Cheers,

Julius

[petr_solberg · Accepted solution]

Hi Julius,

thanks, there is an instruction attached to the Note and that instruction describes in detail what to do on the AS ABAP and what to do on Hana. No mention of Java.

This instruction leans towards your interpretation that this affects all ABAP Stacks where the library is used and all Hana db's where the library is installed.

Best regards,

Andy.

[Former Member · Accepted solution]

Hi Andy,

Yes, you are correct. And there is no instruction for JAVA either.

The security advisory (email) from SAP mentioned that the Cryptographic Library for JAVA stacks was not affected. I interpreted this to mean that if you are issuing logon tickets signed by the PSE using the seculib, then you should replace it with the common library as well.

Probably not a bad idea while you are about patching things anyway... but I think you are correct that there is no action on JAVA stack needed. That takes a bit of wind out of the sails because most tickets are typically issued by portals, and they are on the JAVA stack.

Perhaps someone can still confirm that though?

Cheers,

Julius

[petr_solberg · Accepted solution]

Yes, but let's not forget, if people are using SNC in their landscape for securing ABAP to ABAP trust then they're going to have some work to do.

You're right, it would be nice if somebody with authority from SAP would notice this thread and give the definitive answer on this internet forum which is searchable on google, this would save some OSS traffic, which is why I put it here in the first instance instead of a case to SAP.

If an answer doesn't come by Monday I'll put a case to SAP because we need the definitive answer to this.

Best regards and nice weekend,

Andy.

p.s. Maybe our resident Security Expert can help

[Former Member · Accepted solution]

Exactly. That is why I informed my team yesterday to be nice to the basis folks in the next days...  🙂

[Former Member · Accepted solution]

Hi Julius, Andy,

although JAVA is not directly affected as it uses the built-in crypto, you still may have to take action on JAVA systems. This is because you have to exchange keys used to verify data from an ABAP system or where the keys have been created on an ABAP system (see note 2068693 for more details).

As you can see in note 2067859, the issue is related to the DSA algorithm only. As SNC by default uses RSA not DSA, SNC will not be affected in most cases.

BTW: as part of the fix it is recommended to also replace DSA based PSE. There is now also a tool supporting you to replace the PSEs, which is delivered via note 2068693.

Regards,

Patrick

[Frank_Buchholz · Accepted solution]

Julius, you are right, the main systems in scope are ABAP and HANA:

All systems which are using the SAPSECULIB, SAPCRYPTOLIB or CommonCryptoLib to create Digital Signatures using DSA are affected.

Such are: ABAP systems and HANA XS.

SAP AS Java including the SAP Portal is not affected as it is using an own cryptographic library. SAP Web Dispatcher, ICMAN, SAP Router, or Secure Login Client (SLC) are not directely affected, because DSA is not used in these products (assuming that you are using standard installations).

However, SAP recommends to replace the SAP Cryptographic Library versions of SAPSECULIB, SAPCRYPTOLIB or CommonCryptoLibthat in any case because of future use cases that might get impacted.

Kind regards

Frank Buchholz

[Former Member · Accepted solution]

Thank you Frank and Patrick! 

[petr_solberg]

POODLE

Today the POODLE resolution  OSS Note has been published:

     2089135 - Upgrade OpenSSL to resolve the POODLE issue with the SSL 3.0 protocol

and supporting Notes:

SAP Note 2092630 – Turning off SSLv3 on SAP NETWEAVER AS ABAP and AS JAVA, and on SAP HANA XS

SAP Note 2089135 – Upgrade OpenSSL to resolve the POODLE issue with the SSL 3.0 protocol

SAP Note 2083444 – Impact of the POODLE vulnerability on SAP BusinessObjects software

Best regards,

Andy.

[martin_voros]

Thanks Andy for posting these details. So if you want to use TLS only then you are stuck with the following suites

TLS_RSA_WITH_AES128_CBC_SHA

TLS_RSA_WITH_AES256_CBC_SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

SAP should really implement new suites that provide perfect forward secrecy.

Cheers

[petr_solberg]

another Note..

2088755 - Disabling SSLv3.0 in NetWeaver AS Java 6.40 - 7.0x

[petr_solberg]

Hi and

thank you for joining this discussion so promptly and thank you for your expert feedback.

I too received the email last week, but I interpreted the words incorrectly, and didn't make the extra effort to read the attachment to 2068693, had I done so I would have better understood the scope.

Still, towards the end of last week, I was having doubts and as I would rather ask a question and be wrong than not ask, I put this question here, and am I thankful that I did so.

To wrap up, thanks again, the message is clear, and we will act on it, and this thread will hopefully be useful to others, basically:

     DSA is out - we should all know that from our MS Active Directories which nolonger (Win2012)

     support DSA

     ABAP and Hana systems need an upgraded CryptoLib

     Java stacks which have ABAP certificates will need the certificates reimported

     Nice to have would be to upgrade the cryptolib on the Java stacks while you are at it, but

     this is not a pre-requisite

     The associated OSS Notes are:

               note 2068693

                         Make sure to read the attachment to the Note, if you have

                         SolMan 7.1 SP10 or higher, there's a tool for checking dependencies

               note 2067859

Best regards,

Andy.

[Former Member]

Hey Andy,

I'm not a hard core security guy, so the "DSA" name itself doesn't mean a whole lot.

Is it clear to you that to avoid POODLE  AKA CVE-2014-3566 then you must update your CryptoLib using SAP note 2067859?  Then essentialy rebuild all your PSE's (basically what note 2068693 is saying?)

I ask because our Firewall team decided to "block" all SSLv3 certificate exchanges and one of the things we do in SAP from our end, is call a credit reporting agency via RFC type G.  But doing that, we use an "anonymous" cert, see my post: http://scn.sap.com/thread/3637765

Once they blocked SSLv3 cert exchanges, we were screwed.

My firewall folks are telling me to "get off" SSLv3, so as a basis guy, I want to play nice.  So I was wondering how we do that in SAP..I mean start using TLS?

Hope that was clear.  Thanks for starting this discussion

NICK

[Former Member]

My understanding is also that you must recreate your PSE for the system and if you created own PSEs for signatures (unfortunately these are often signed by the system and not a signature scenario) then you should recreate them as well.

And then distribute / re-establish the public keys to the trusting systems, which might also be SAP JAVA stacks or non-SAP systems.

We had performance problems today, but that was because we patched many things at the same time, had to restart several times and forgot to run SGEN the last time.

As mentioned before, please be considerate that the basis folks have real work to do and don't irritate them with some obscure GRC issue in the next 2 weeks...  🙂

Cheers,

Julius

[petr_solberg]

Hi Nick,

funnily enough that SSL3 question landed on my desk on Friday in regard of Transport Layer Security in PI.

I used two OSS Notes to get to the conclusion:

     I used Section 7 of this OSS Note: 510007 - Setting up SSL on Web Application Server ABAP

          and

     this Note: 1433874 - SapSSLReloadCred fix, SSLv3/TLSv1.0 configurability, GOST

Basically there's a profile parameter which needs to be set to configure the system to use TLS instead of SSL3 and that is described in section 7 of 510007.

Kind regards,

Andy.

p.s. I am also not hard core  Security, hence putting questions here and seeking the advice of others to fill the gaps in knowledge and put doubts to rest 🙂

[petr_solberg]

Hi Julius,

correct, when you upgrade the CryptoLib, you need to create new PSE's and by creating new PSE's you will invalidate all certificates which you have shared with satellite systems, therefore, the certificates need to be distributed again to satellite systems.

Best regards,

Andy.

[mathias_essenpreis]

Hi Nick,

Poodle and the security threat in note 2067859 are two distinct cases.

So replacing the crytolib as motivated in note 2067859 will NOT solve POODLE.

Regards,

Mathias

P.S.: One option to fix POODLE is to disable SSLv3 as Andy already described.

[petr_solberg]

Hi Mathias,

do you know of other options for mitigating POODLE which can be shared here ?

Kind regards,

Andy.

[martin_voros]

Hi,

POODLE is a design flaw in SSL3 when it uses block cipher in CBC mode (cipher block chaining). There is no fix for this. The only fix is NOT using SSL3. There is no other option. The "fix" for OpenSSL is just preventing downgrading client from TLS to SSL3 but it does not solve the issue if client only supports SSL3. SSL3 is quite old so it's a good idea to stop using and use safer successors.

Cheers

[former_member206857]

I to have been looking at this. I knew from the start that POODLE and the SAPCRYPTO was a separate issue. Poodle is a vulnerability in the Protocol being used to create the Secure tunnel.

So in this case, any tunnels being created with SSL3.0 are vulnerable if someone can get in the middle and sniff packets and steal cookies..Its a massive long shot but a known issue.

So if a webserver receives a request from a client, the server and client negotiate on what protocol to use and if conditions are that both can only speak on SSL 3.0, bang you have a problem.

Now with SAP, we have webservers both on ABAP and Java, the following note  http://service.sap.com/sap/support/notes/510007 section 7 does describe very well versions of sapcrypto and parameters to make it only use TLS1.0 protocol, but where would I find this info on the Java engine?

[petr_solberg]

Hi Joshua,

good question.

This OSS Note doesn't give the precise solution, but it does point us in the direction of where those configurations are made on the Java stack:

      1663313 - SSL not working after applying Microsoft KB 2618444/2585542    

Obviously, where you don't have a Visual Administrator you'll need to look through the SSL Provider in the NWA.

Best regards,

Andy.

[former_member206857]

OK yes that's where they are!

[martin_voros]

Check this blog related to BEAST. It's basically same thing. For older releases check this blog. But both systems are using ICM so it's same config option described in 510007.

Cheers

[former_member206857]

I see the following explanation, but how would one know the SSL3.0 ones?

A cipher name is a set of algorithms used for ensuring secure message communication. Let’s dissect a cipher suite name and see what is behind it. For example SSL_RSA_WITH_RC4_128_MD5:

• SSL -  protocol (alternatives are e.g. TLS)
• RSA – key exchange / authentication (alternatives are e.g. PSK)
• RC4_128 – message encryption cipher and key length (alternatives are e.g. CBC)
• MD5 – message authentication/integrity (alternatives are e.g. SHA)

To mitigate BEAST attacks, RC4 ciphers should be preferred. Stronger encryption with longer keys should be preferred as well. For message authenticity SHA should be preferred as it is considered more secure than MD5. Having this in mind, I suggest the usage of the following ciphers in this particular order:

TLS_RSA_PSK_WITH_RC4_128_SHA

TLS_PSK_WITH_RC4_128_SHA

TLS_DHE_PSK_WITH_RC4_128_SHA

SSL_RSA_WITH_RC4_128_MD5

SSL_RSA_WITH_RC4_128_SHA

[martin_voros]

The first 3 letters of ciphersuite? Or am I misunderstanding what you are asking?

BTW the POODLE similar to BEAST is attack against suite that uses block cipher in CBC mode. So you could keep SSL_RSA_WITH_RC4_128_SHA for compatibility purposes. I would strongly suggest not using anything with MD5.

Cheers

[former_member206857]

LOL, my thought also. I checked my SOLMAN and didn't have anything like SSL30 but did see SSL20 so I wasn't sure.

[martin_voros]

Does anyone know more technical details about this issue? I found this blog but section Technical Details lacks details :-). I am really interested in this. I thought that SAP is also suffering from POODLE CVE-2014-3566 but that really seems to be specific to OpenSSL.

Cheers

[Former Member]

There are several speculations and "advisories" from external services already, but thy generally regurgitate terms and send you back to SAP to apply the kernels.

Responsible disclosure is at least 90 days for the admins to implement corrections and in this case it is not externally exploitable yet as it is an internal correction (bar this post and the bandwagon, only real customers were informed).

Only real customers were informed in advance (assuming they have their own processes). Obviously that process does not work for long.. 🙂

I place my bets on 10 days until someone posts the code to reverse engineer the DSA digest and remove (trap) the encoding / decoding of the SID in the signature.

I allow myself the comment that the origin of the problem was the idea to have an external ITS way back in 6.10 for HR and BP "portals". Can anyone confirm that?

I dont judge it because mistakes can always be made, but there are still many ITS out there. Many are not even used, but they are there.

Cheers,

Julius

[Former Member]

Hi Julius,

I'm not quite sure, where you are heading to with your speculations . The DSA issue is not related to POODLE and simply was a bug and not a feature and especially no feature with regards to the ITS.

Regards, Patrick

[Former Member]

Hi Patrick,

Sorry for the speculation - I should have disclosed it better as guesswork.

I was not trying to head anywhere either, but rather track the problem back to where it comes from in the first place.

These DSA signatures to verify tickets date back to the external ITS times, which at the time was called "the portal" in projects I was involved in. Hence I made a connect to the ITS.

Of course the DSA is widely used in other areas now as well and there is no external ITS anymore (bar the installations still out there).

I guess the curious folks will have to wait the 90 days grace period (or most likely longer in this case).

Cheers,

Julius

[petr_solberg]

Hi Julius,

that Portal you're talking about, you mean the good old WorkPlace (ITS) Portal from back in 1999/2000 ?

Those were the days.

Andy.

[Former Member]

Yes, we used to call it the "enterprise portal" at the time.

All things need prototyping, I don't judge it. But there are still some out there.

Cheers,

Julius