back to article X.509 metadata can carry information through the firewall

A security researcher, who last year demonstrated that X.509 certificate exchanges could carry malicious traffic, has now published his proof-of-concept code. Fidelis Cybersecurity's Jason Reaves has disclosed a covert channel that uses fields in X.509 extensions to sneak data out of corporate networks. The X.509 standard …

  1. FF22

    Who would have thought?

    Bad code can do bad things. A communication channel can be used to transmit data. Who would have thought that? Amazing discovery on part of the researcher.

  2. Anonymous Coward
    Anonymous Coward

    Erm...

    Ya what? So if I can make a TLS connection through a firewall I can transfer data? Whodathunkit?

    Not to pass on the fact that certificates are signed, and it's part of the design to be able to validate that they are issued by who you expect, and contain the correct data. In fact, I'm pretty sure if you are doing TLS decryption at said firewall, you'd have to do this (and if you're not decrypting the TLS, I really don't understand why you put the data in the certificate, not in the encrypted TLS stream).

    1. Daniel B.

      Re: Erm...

      The certificate contains the data because that way, you can initiate a TLS connection, have it fail and the firewalls and IDS/IPS systems will only register a failed connection. However, the data dump will already have been sent.

      It's sending information on a channel nobody's expecting to actually contain data.

      1. Anonymous Coward
        Anonymous Coward

        Re: Erm...

        You can do the same with DNS: make DNS queries to <datastring>.<some-domain-you-control> which in turn returns a TXT record with zero TTL; nice bi-directional channel. There's open-source code out there to tunnel an SSH session through it. You can use it to get Internet access from behind wifi captive portals (so I've heard).

        If you are able to establish a network connection to anywhere, you can use it to send data. Simple example: every second either make a TCP connection (1) or don't make a TCP connection (0) to a specific host. If the firewall lets those TCP SYNs through then you have a 1bps covert channel.

      2. Anonymous Coward
        Anonymous Coward

        Re: Erm...

        If you even remotely care about security, you’ll need to check the client certificate at the firewall (and drop the connection immediately *before* sending it through)

        The example of “care about data leakage” and “don’t care about client certificate validation” has no real world intersection.

        1. Anonymous Coward
          Anonymous Coward

          Re: Erm...

          > If you even remotely care about security, you’ll need to check the client certificate at the firewall

          You can't do that unless your firewall is performing a man-in-the-middle attack on the session - that is, spoofing a false server certificate back to the client, which the client is configured to trust.

          Apart from breaking the whole TLS end-to-end security model, most vendors' implementations of that approach are pretty terrible and significantly reduce the security of TLS.

          If you really want to inspect all your users' web traffic on the wire, then go the whole hog and force them to use a proxy.

          1. Daniel B.
            Boffin

            Re: Erm...

            > If you even remotely care about security, you’ll need to check the client certificate at the firewall

            You can't do that unless your firewall is performing a man-in-the-middle attack on the session - that is, spoofing a false server certificate back to the client, which the client is configured to trust.

            Both are sort of right. You can check both client and server certificates at the firewall, because at that point, the communication is still being made in cleartext. Certificate exchanges are sent as part of the initial handshake. Firewalls are capable of MITMing stuff... however, parsing an X.509 certificate and validating it is going to be resource intensive. It's less the job of a regular firewall and more of an IDS/IPS thing, and even then it's going to be so resource intensive that it'll slow down all outgoing traffic. Why? Because you'll need to check all outgoing traffic, see if it's an SSL/TLS handshake, then check the handshake itself, parse the X.509 certs, validate them .... you get the idea.

            This is going to suck, because the only way I see this being mitigated is by forcing all traffic to go through proxies, then having those proxies offload all CONNECT requests to an IPS. There's a lot of software out there that shits itself whenever you try to make it go through a proxy...

    2. Voland's right hand Silver badge

      Re: Erm...

      Not to pass on the fact that certificates are signed, and it's part of the design

      Slightly different angle. In addition to being signed, they can contain a nearly arbitrary amount of metadata. You are limited solely by the size of the parse buffer which in GNUTLS if memory serves me right was around 32k (larger in openssl).

      Passing data INTO the target this way is esoteric. If you are able to extract it you own the mark already. That still leaves a few applications such as sending instructions to a bot herd or a RAT though.

      This is more interesting as an EX-filtration method. Certificates can be used for authentication and supplied by the client. That is a channel nobody checks. It will work once or twice courtesy of being obscure though. If it is used, it will become target for the firewall and AV vendors.

    3. Roland6 Silver badge

      Re: Erm...

      >So if I can make a TLS connection through a firewall I can transfer data? Whodathunkit?

      Well the issue here is the data contained in the first packet. If memory is correct, you've always been able to transmit some 'user' data in the connect request - in fact protocols such as XTP made a virtue out of this capability, so it is totally possible to transfer data across the Internet without actually establishing a connection, the receiving host simply discards or refuses the connect request.

      >Not to pass on the fact that certificates are signed

      That may be the case, but the signature can only be validated, after a complete certificate has been transferred...

  3. Anonymous Coward
    Anonymous Coward

    If you have compromised inside the remote network already...

    ...then getting data out unnoticed is the easy part. This approach is entertaining but irrelevant.

    1. Claptrap314 Silver badge

      Re: If you have compromised inside the remote network already...

      I'm not sure I agree with this. If you are using USB sticks for your attack, for instance, getting the data out can be VERY interesting. Phishing emails, probably less so.

    2. Roland6 Silver badge

      Re: If you have compromised inside the remote network already...

      >...then getting data out unnoticed is the easy part. This approach is entertaining but irrelevant.

      Disagree, the benefit of this approach is the lack of traces left in the logs and the requirement for malware scanners to perform additional stateful inspection, so could be useful to cloak the transmissions between a malware client and its CCC.

  4. Anonymous Coward
    Anonymous Coward

    TrendMicro/Affirm Trust

    Has anyone else noticed the Affirm Trust Commercial certs with the "friendly name" of TrendMicro in Windows 7 that have every purpose under the sun enabled?

    They seem to be in several Linux distros now as well.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like