Weird computer?

[iago]

Yeah, I understand your point, and you're absolutely right about that. But I'm pretty sure that Chavo is arguing the wrong point, so I wanted to clear it up.

[Chavo]

LAN VNC traffic isn't going to be passing through a proxy with SSL..

The argument you are presenting is fundamentally flawed, because packet inspecting firewalls require knowledge of what to look for in order to prevent "bad traffic".  If an attacker alters the way they hide their data in legitimate traffic, a firewall will be unable to detect it unless someone teaches it how to recognize the "bad traffic".  This is the same reason that antivirus software cannot magically detect "malicious code" - AVs, like packet inspecting firewalls, are based on filters of "good" or "bad" things, and these filters are not useful unless they are newer than the tunneling system in question.

And even then, it may not be feasible.  If, say, SSL traffic is allowed to any Internet host, any hope of packet inspection is hosed for that traffic and any programs that use SSL to protect themselves from said packet inspecting firewall - the firewall is going to have no way to look inside the SSL session and see what's really being exchanged.

I think you might have missed the topic of this thread.  I am in no way suggesting that firewall rules and packet inspection are anywhere near flawless, easy to use, or common knowledge.  Your suggestion that my argument is flawed is based on the assumption that I am referring to all instances.

In our example, one person using a public computer on a private network (since its a Library computer, its probably safe to assume it doesn't even have anything other than a web browser).  Inspecting for 'bad' traffic can be as simple as checking to make sure everything that passes through the web ports (we can again assume that only 80, 8080, and 443 are not blocked by firewall rules) has a valid HTTP header.  Is this possible to forge? Sure.  Is it likely there exists a VNC client that forges HTTP headers right now?  Probably not.

[Skywing]

I might refer you to the Metasploit project, which incorporates (among many other things) a reverse link back channel (i.e. connect out) using HTTP GET/POST that is used to tunnel a stripped down version of VNC.

[Chavo]

I must admit I haven't read anything from metasploit in a long time.  I'm guessing you are referring to the PassiveX Payload in that PDF.  I agree that it seems like a reasonable explanation for this occurence that would probably get through even a well protected network.  It -might- still run it to problems with local policy though depending on what the vulnerability requires and how locked down the workstation he is using.

Of course, we already know the workstation couldn't be too terribly locked down if there is a less-malicious VNC server hiding somewhere, even on a USB drive.  I still think an insecure network with a simple VNC setup by someone that just discovered VNC and wanted to have some fun is more plausible than a malicious user that is familar with a particular vulnerability deciding he wanted to move a random users mouse around for kicks :)

[Camel]

Depends on how the data is hidden. It's especially difficult if it's, say, an SSL connection (which should always be allowed), unless the server proxies all the SSL connections, decrypting/re-encrypting them with its own key, there's no way to inspect it. There's nothing basic about detecting well tunneled traffic.

There are several programs available that will watch any network controller and decrypt SSL. Of course, it needs to see the entire conversation with the server to be able to decrypt it, but that task is trivial if the user can already see the traffic.

[Camel]

In our example, one person using a public computer on a private network (since its a Library computer, its probably safe to assume it doesn't even have anything other than a web browser).  Inspecting for 'bad' traffic can be as simple as checking to make sure everything that passes through the web ports (we can again assume that only 80, 8080, and 443 are not blocked by firewall rules) has a valid HTTP header.  Is this possible to forge? Sure.  Is it likely there exists a VNC client that forges HTTP headers right now?  Probably not.

Actually, one of the goals of more than one VNC project is to tunnel through HTTP. I don't remember which one, possibly TightVNC, but there definitely exists one that has a mode which uses entirely HTTP PUSH/PULL to communicate between client and server. It even provides a web client to use it through a browser.

[iago]

Depends on how the data is hidden. It's especially difficult if it's, say, an SSL connection (which should always be allowed), unless the server proxies all the SSL connections, decrypting/re-encrypting them with its own key, there's no way to inspect it. There's nothing basic about detecting well tunneled traffic.

There are several programs available that will watch any network controller and decrypt SSL. Of course, it needs to see the entire conversation with the server to be able to decrypt it, but that task is trivial if the user can already see the traffic.

Not true. The only way it could be done is by proxying the connection. In that case, the client would connect to the proxy, the proxy would decrypt/re-encrypt the traffic, then the proxy would establish its own SSL link to the remote server. You can't capture traffic simply by analyzing the SSL traffic, that would totally defeat the purpose.

[iago]

In our example, one person using a public computer on a private network (since its a Library computer, its probably safe to assume it doesn't even have anything other than a web browser).  Inspecting for 'bad' traffic can be as simple as checking to make sure everything that passes through the web ports (we can again assume that only 80, 8080, and 443 are not blocked by firewall rules) has a valid HTTP header.  Is this possible to forge? Sure.  Is it likely there exists a VNC client that forges HTTP headers right now?  Probably not.

Actually, one of the goals of more than one VNC project is to tunnel through HTTP. I don't remember which one, possibly TightVNC, but there definitely exists one that has a mode which uses entirely HTTP PUSH/PULL to communicate between client and server. It even provides a web client to use it through a browser.

I am reasonably sure that the Web client is simply a Java applet that implements the VNC protocol in the standard way. As such, it isn't a Web tunnel, it's just a portable app.

[Skywing]

There are several programs available that will watch any network controller and decrypt SSL. Of course, it needs to see the entire conversation with the server to be able to decrypt it, but that task is trivial if the user can already see the traffic.

This is doable if one has access to install a custom root certificate on a computer and then is able to generate certificates with any CN on the fly and substitute them in for SSL conversations.  This can be at the very least detected by checking the issuing CA for certificates application-side (and is only a problem if the box one is on is already controlled by the adversary, although this may be considered an acceptable case if the box is a company box and the device logging SSL traffic is also a company box that is there explicitly to do that).

However, it is still possible to effectively hide information by other means (such as by incorporating data in images or other legitimate binary content that tends to be very difficult to automatically make a "good" or "bad" determination).

[Camel]

Not true. The only way it could be done is by proxying the connection. In that case, the client would connect to the proxy, the proxy would decrypt/re-encrypt the traffic, then the proxy would establish its own SSL link to the remote server. You can't capture traffic simply by analyzing the SSL traffic, that would totally defeat the purpose.

It depends entirely what cipher is being used; they're not all beyond simple obfuscation. I used to have an application for windows that supported winpcap and listened for SSL traffic, decrypting the majority of the traffic. It was a very elemental, proof-of-concept program. Unfortunately, the disk I had it on died, and I can't remember what it was called.

[iago]

Not true. The only way it could be done is by proxying the connection. In that case, the client would connect to the proxy, the proxy would decrypt/re-encrypt the traffic, then the proxy would establish its own SSL link to the remote server. You can't capture traffic simply by analyzing the SSL traffic, that would totally defeat the purpose.

It depends entirely what cipher is being used; they're not all beyond simple obfuscation. I used to have an application for windows that supported winpcap and listened for SSL traffic, decrypting the majority of the traffic. It was a very elemental, proof-of-concept program. Unfortunately, the disk I had it on died, and I can't remember what it was called.

If it was on the local machine, then it's possible that the program either snarfed the client's key locally or grabbed the data before it was encrypted. It all it had was the packets going back and forth, there's no way (excepting what I said earlier) that it could be done. Why would anybody use SSL if it could be decrypted?

[Camel]

I've tested it on wireless networks, and it works just fine. There is no such thing as a cipher that is impossible to reverse without the private keys, and you'd be surprised at how many servers don't support some of the stronger ciphers. Even so, there are some hardcore cypher punks out there that claim to be able to break some of the strongest ciphers. There are numerous unverified accounts of RC4 being rendered useless.

I actually watched someone log in to paypal in a starbucks once, and was able to pick out their password - they were using some crappy browser I've never heard of. I wrote his password on a piece of paper, and 'getfirefox.com' under it, and handed it to him. Priceless.

In any event, the purpose of obfuscating data is to increase the amount of time it would take a determine hacker to decode the data. No matter how you look at it, any data encoded with a finitely complex encryption algorithm can be decoded in a finite amount of time with any turing machine. If you make the amount of work so great that it isn't worth the hackers time to decode it, then you are safe.

While the client does gain great advantage by using an encoding that utilizes public/private keys, since knowing the algorithm isn't all that's required to efficiently solve the puzzle, that doesn't mean the data is completely safe.

[iago]

Yes, the key is that you have to know the public and private keys. I'm guessing you hacked into the remote server to recover Paypal's key? Or do you have some exploit for the SSL protocol that nobody knows about? Because, if so, you should be watching your back. You never know who might try to kill you (TLAs come to mind). It's also funny how you transition from reversing with private keys to supporting strong ciphers in one sentence -- that seems to suggest that those are somehow related? The cipher used is barely related to the private key, and I'm pretty sure that you can't recover the private key, even if the cipher is very weak.

And yes, RC4 has been provably broken. I seem to recall that distributed.net recovered an RC4 key from an encrypted sentence in under 24 hours. So it's not just unverified accounts.

Or were you using an ARP or DNS poisoner? Because that's the type of program that I mentioned earlier, where you can proxy connections and decrypt/re-encrypt the data. This is well known and can't really be prevented. I also don't see how getting Firefox can prevent your unknown mystery exploit program.

It should also be noted that encryption is different from obfuscation. I won't go into details, but the words aren't interchangeable. Neither are encryption and encoding. If you're going to argue about encryption, it's necessary to understand the distinction between those three words.

In any case, you are correct that, given an infinite amount of time or processing power, any encryption algorithm can be broken. However, SSL is the Internet standard, and, as I said earlier, if you can break it, I have some people here who are very interested in keeping you quiet.

[Camel]

It should also be noted that encryption is different from obfuscation. I won't go into details, but the words aren't interchangeable. Neither are encryption and encoding. If you're going to argue about encryption, it's necessary to understand the distinction between those three words.

In any case, you are correct that, given an infinite amount of time or processing power, any encryption algorithm can be broken. However, SSL is the Internet standard, and, as I said earlier, if you can break it, I have some people here who are very interested in keeping you quiet.

I wasn't confusing the words; I was implying that encryption is a form of obfuscation. Also, I said finite, not infinite - every form of obfuscation can be broken in a finite amount of time with a finite amount of computing power. Saying that something can be done with an infinite amount of computing power is equivalent to saying "there may or may not be any known way to do the task."

That said, the program I'm referring to does only work on the weaker ciphers, and you're wrong to say/imply/think that every cipher supported by SSL employs a private key beyond the handshake - I don't know if that's still the case with TLS. The browser this guy was using only supported a weak cipher, and that's why the program could recover the data.

[Skywing]

Any TLS implementation in use out there today should not be permitting the use of weak ciphers.  "Downgrade" attacks like this are not usable against correctly done implementations.