Problem unlocking a 1500 PLC with passwords when using TIA 19 and firmware 3.1

[yogiTheBear7000]

The access control for the 1500 controllers has been revised with firmware 3.1. User+password must now be transferred, or the anonymous user must be enabled for the PLC.

If passwords are to be transferred, “legacy control” must be enabled and a password must be assigned for each enable level. I have tested the control with the PLCSim.

The anonymous user works without any problems.

However, if I want to transfer a password (with “legacy control” enabled), the connection is denied.

It would be great if the security functions of firmware 3.1 would also work with the S7CommPlusDriver. The transfer of the password or even better the transfer of user+password.

Thanks a lot..

[Ich-Eben]

Hi Yogi,

I'm the author of the PR that introduced accessing password protected PLCs. I had a quick look at the telegrams exchanged between plcsim with the new firmware and TIA today. Unfortunately every time I use my mitm proxy to be able to decrypt the packages, the access to the PLC is denied. But without the proxy it works just fine. So it seems like, they somehow detect mitm attacks now.

I'll have a closer look into this the upcoming weekend I think.

[thomas-v2]

I haven't TIA V19 available, but maybe you can see where the difference is, if you use legacy PG/PC communication for the current session, via menu "Online" -> "use only legacy PG/PC communication" inside TIA Portal? I haven't checked how different the login process is when TLS is not used.

[Ich-Eben]

Good point. I somehow always thought the password protection only works with encryption enabled. With legacy communication enabled the login works and I can see the telegrams. Fingers crossed its not different when TLS is used.

On first glance the difference to the older firmware is in the SetVariable request after we received the 20 bytes challenge from the PLC. Before there were only 20 bytes send back to the PLC. Now they send a blob of 291 bytes!

Oh boy, this will be quite a challenge to figure out.

[thomas-v2]

I believe when TLS is not used, it used the special cryptographic method based on the challenge/response which is used for pre-TLS authentication, where as far as I know for password authentication a different derived key is used. That was the advantage when using TLS, that you can just miss the ServerSessionResponse, even when the Challenge is there.

[yogiTheBear7000]

Good morning, what I don't quite understand about Tia19 and the new firmware: If the new "Legacy Mode" is activated within the access control and the anonymous user is deactivated, you can store a password for each access level.

The controller should then behave in the same way as with the old firmware versions. This should ensure that older devices can also communicate with the new control units.

The old communication should still work, but it does not.

[Ich-Eben]

Quick update: when TLS is enabled, they really use a different method of authentication. The difference to the older firmware is that after we receive the 20 bytes challenge from the PLC, TIA sends back 48 bytes. So, one could think they simply switched from sha1 to sha384. But when I used the proxy to manipulate the challenge send from the PLC to fix it down and send multiple login attempts the 48 bytes coming from TIA still change at random.

I guess they properly salt the hash now. So maybe its still a sha1 + salt?

I’m pretty sure they use some secret from the TLS connection as salt as well when hashing the password. That would explain how they detect the mitm attack.

I tried to extract the TLS secrets directly from TIA by using a patched OpenSSL library with no luck. As far as I understand it, they don’t use the OpenSSL library for TLS at all. Actually, I think they don’t use any external library but have implemented their own? Can someone confirm?

[yogiTheBear7000]

Hi, thats maybe sounds like a salted 384 hash. Because the 48 Bytes length. Sha1 is actually discontinued by all major manufacturers, it would make sense if they had switched to SHA384.

What you wrote sounds plausible that perhaps an additional value from connecting the challenge before hashing is added.

What I still haven't understood is how Siemens wants to maintain compatibility when connecting to older controllers or panels when this central mechanism is changed?

[Ich-Eben]

Yes, I wonder the same. Did you already check if it’s possible to connect, let’s say from TIA V17 to a PW protected PLC running firmware 3.1? If that’s possible, maybe there’s a third way of authentication we can use for the driver.

[yogiTheBear7000]

Hi, I did the following test: Under V19 a 1511 with firmware 3.1 set up and assign different passwords for the individual access level. All this uploaded and tested in the PlcSimV19. Then V18 opened and there set up a 1511 with firmware 2.9. Here is a password for HMI access. Then connected with Tia V18 on the PlcSim V19. Telegrams were exchanged and then a command prompt came late to enter the password. After input, the connection would be successfully established. This shows me that there seem to be mechanisms to grant access to older devices as well. Hope, this is helpful...

[Ich-Eben]

Hi, it's been a while. But I finally figured it out!

So as expected they are deriving a secret from the TLS connection. But instead of using a simple hash they actually encrypt the username and password with AES 256 CBC.

They use a rolling key that changes on every login attempt. To roll the key they simply hash it with sha256. The initial key is derived from the TLS exporter secret with the SSL_export_keying_material function. As IV they use the first 16 bytes from the challenge response that comes from the PLC.

The unencrypted legitimation data looks like this:

00000000  00 17 00 00 9d d0 82 bb 51 00 04 02 82 bb 52 00  |.....Ð.»Q....»R.|
00000010  14 00 04 74 65 73 74 82 bb 53 00 14 00 0a 54 65  |...test.»S....Te|
00000020  73 74 31 32 33 34 35 36 00                       |st123456.|

(user: “test”, password: “Test123456”)

I’ve implemented this quick and dirty in the driver with a hardcoded username and password and am now able to successfully connect to a password protected PLC that runs in PLCsimAdv v6 with firmware 3.1.

I’ll prepare a pull request, but it will take some additional time as this time I want to properly test this with all the firmware versions and especially with real hardware before I push it.

Expect an update after the easter holidays.

flowchart TD
    F[TLS connection established] -->|derived exporter secret| G
    G[roll key on every legitimation attempt with sha256] -->|Key| A
    E[TIA] -->|Username+PW+Data| A
    C(PLC)-->|20 byte challege response| D
    D[take first 16 bytes] -->|IV| A
    A[AES 256 CBC] -->|encrypted legitimation response| B(PLC)

[yogiTheBear7000]

Oh, that's good news, Congratulation...

I've just gone through this theoretically. If I assume that the key from the TLS negotiation is 32 bytes long and the composition of user and password is about 40 bytes long, the AES 256 CBC encryption would result in a byte array with a length of 48.

At the top of one of your previous messages, you write that a blob of 291 bytes is transmitted. Is it now sufficient to send the 48 bytes, or how do you end up with the 291 byte blob?

This is just the result of my theory, or i am making a mistake?

[Ich-Eben]

Hi, your theory is correct. TIA sends 48 bytes back to the plc as the legitimation response. It depends of course on how long the username and password is.

The 291 bytes are only sent, if legacy communication is used between TIA and the PLC. This makes sense as they cannot derive any secret without an TLS connection. So my guess is that they fallback to the old authentication method that was used before TLS was introduced when you use legacy communication.

[Ich-Eben]

If you already want to play around with it, here is my quick and dirty changes I did to the driver to make it work in plcSImAdv.

if (omsSecret == null || omsSecret.Length != 32) {
    //create oms exporter secret
    omsSecret = m_client.getOMSExporterSecret();
}
byte[] key = sha256(omsSecret);
omsSecret = key; //roll key
Console.WriteLine(BitConverter.ToString(key, 0, key.Length).Replace("-", ""));
byte[] iv = new ArraySegment<byte>(challenge, 0, 16).ToArray();
Console.WriteLine(BitConverter.ToString(iv, 0, iv.Length).Replace("-", ""));
challengeResponse = EncryptAesCbc(Convert.FromBase64String("ABcAAJ3QgrtRAAQBgrtSABQAAIK7UwAUABQvteE0GfyJJGhl56Mk9HbsYk6HQAA="), key, iv);
Console.WriteLine(BitConverter.ToString(challengeResponse, 0, challengeResponse.Length).Replace("-", ""));


// Send challengeResponse
var setVariableReq = new SetVariableRequest(ProtocolVersion.V2);
setVariableReq.InObjectId = m_SessionId;
setVariableReq.SessionId = m_SessionId;
setVariableReq.Address = 1846;//Legitimate//Ids.ServerSessionResponse;
setVariableReq.Value = new ValueBlob(0, challengeResponse); //new ValueUSIntArray(challengeResponse);

(S7CommPlusConnection.cs)

public byte[] getOMSExporterSecret() {
    byte[] secretOut = new byte[32];
    int ret = (int)Native.SSL_export_keying_material(m_pSslConnection, secretOut, (uint)secretOut.Length, "EXPERIMENTAL_OMS".ToCharArray(), 16, IntPtr.Zero, 0, 0);
    return secretOut;
}

(OpenSSLConnector.cs)

Just keep in mind that the implementation will change quite a bit. As there’s still a lot of work to do, like:

• Passing the username and password to the application by the user.
• Allowing to use just the password without the username for legacy logins.
• Figuring out how to build that payload that contains the username and password the correct way.
• Test this with other firmware versions and real hardware.

[yogiTheBear7000]

Hi, I have now also played with it a bit and after a few obstacles I was able to legitimize it. The good news is that it also works with the brand new firmware 4.0 (tia 20).

But what I have also noticed now. With the newer firmware > 3.0 (1500) or 4.6 (1200), the normal login with a single password no longer works. They have probably also changed it from SHA1 to SHA256. When I send the old credentials to an S7-1200 with firmware 4.7, it crashes completely and has to be unplugged. Let's see....

[Ich-Eben]

Thats great news! I really had my doubts regarding firmware 4.0. I tinkered around with the legecay login (only password) yesterday and figured out that they still sha1 the password and then send the hash instead of a username and password with the new legitimation methode:

00000000  00 17 00 00 9d d0 82 bb 51 00 04 01 82 bb 52 00  |.....Ð.»Q....»R.|
00000010  14 00 00 82 bb 53 00 14 00 14 2f b5 e1 34 19 fc  |....»S..../µá4.ü|
00000020  89 24 68 65 e7 a3 24 f4 76 ec 62 4e 87 40 00     |.$heç£$ôvìbN.@.|

(password: “abcdefg”) The hash of “abcdefg” is: 2fb5e13419fc89246865e7a324f476ec624e8740

We definitely need to detect the firmware version before sending the legitimation package in the feature. To prevent things like this from happening.

Did you test with real hardware as well, or only in plcSim?

[yogiTheBear7000]

Hi, hmm, i have tried to reproduce this once. The result is that the PLC responds with an unknown error and then dies. This happens with a real controller as well as with the simulator. I tested it with an S7-1200 and FW 4.7 and a 1511 with FW 3.1.

The password is "Test123456"

[Ich-Eben]

Hi, you have to encrypt the payload with aes. Even the sha1 payload for the legacy login has to be encrypted. I just finished programming the changes necessary to get this fully working in the driver. You can find my implementation here: https://github.com/Ich-Eben/S7CommPlusDriver/tree/legitimation It would be awesome if you could test it on your side again, as I have no access to real hardware at the moment. I’ve tested with PLCsimAdv 6.0 with firmware 2.9, 3.0 and 3.1 so far. 2.9 and 3.0 with just password and 3.1 with just password and username and password. As soon as we’ve tested this with more devices and firmware, I’ll make a PR.

If you get an Firmware not supported error when using real hardware, the problem is the regex that parses the firmware version: https://github.com/Ich-Eben/S7CommPlusDriver/blob/legitimation/src/S7CommPlusDriver/Legitimation/Legitimation.cs In line 28. Please let me know when this happens.

[yogiTheBear7000]

Hi, thank´s for your great work. I´m currently in easter holidays, so i have´nt access to real hardware.

But i checked this against PLCSIM withe the following results.

S71511 FW 2.9 legitimation with password => okay S71511 FW 3.1 legitimation with password => acess denied, after the telegramm the plc dies S71511 FW 3.1 legitimation with User+password => okay

S71211 FW 4.6 legitimation with password => okay S71211 FW 4.7 legitimation with password => acess denied, after the telegramm the plc dies S71211 FW 4.7 legitimation with User+password => okay

[yogiTheBear7000]

Short update, the PLC only dies if I use the standard PLCSIM. By "dying" I mean the PLCSIm instance shuts down completely and has to be restarted.

If I use PLCSIM Advanced 6 Update1, the PLC returns the message Access denied and does not die.

[Ich-Eben]

I've tried to reproduce this without any luck so far. I've installed update 1 for plcsimAdv v6 and started a new instance of a S71511 with FW 3.1. For me it works just fine. Tried it with TIA v19 and TIA v20 now.

[yogiTheBear7000]

Hello, i don´t know what was wrong yesterday. Today, i checked it again, and it workek without any problems. Maybe the password was wrong in the plc or i don´t know. So, then i have to apologize for your extra work and thank you very much.

[Ich-Eben]

Hey Yogi, don’t you worry. Wired stuff happening when working with plcsim is quite normal. At one point during testing I was wondering why my hard drive was full. Turns out it was 150GB of crash dumps from plcsim. Thanks for testing and now enjoy the rest of your holidays!

[yogiTheBear7000]

Hello, unfortunately I was only able to test it today, I had a bit of stress. Now I was able to work on it again. I was able to test the access with a S7-1211 and firmware 4.7 and a S7-1511 with firmware 4.0. Access with user+password and access with password only now worked. Perfect work...