Weird computer?

[Killer360]

I mean you don't have administrative permissions so it wouldn't work. You can't even access the control panel so that wouldn't work.

There's this whole concept called "hacking" that's based on this dilemma. It came out in like the '40s.

No shit... it would take a really "smart" student to glitch or do anything like that and the library computers are monitored very closely.

[Ender]

No, it would take a mentally retarded 13 year old with an index card of instructions.

[Ender]

Just out of curiosity, is the computer that this happened on running Windows XP?

[Killer360]

Just out of curiosity, is the computer that this happened on running Windows XP?

Nooooooooooo...

[Joe]

In computer class, sometimes I'd have a friend who sat in the row in front of me walk into class with a USB receiver, and I'd be wielding a wireless mouse. When the kid next to me isn't paying attention, the guy in front plugs in into the back. "Wtf" followed.

But yeah, I think it's a VNC-esque program. Interesting what they were doing though.

Network traffic rules at my old school did nothing to block VNC. I used it nearly every day when I was working with two computers at once (I did a fair deal of network-related programming towards the end of the semester, so this was often).

[Sidoh]

Well, the rules you're talking about there are internal network traffic.  That's usually a lot different than incoming network traffic.

[Joe]

Oh, I figured whoever "hacked" his machine did so internally.

[Skywing]

You can put a VNC client/server on a USB drive and run it from there if you want ;)

That sort of 'vulnerability' should generally be blocked by network traffic rules.  Clearly your school's IT department is not up to par.

This is a fallacy for Internet-connected computers.  If any external network access is allowed to unspecified remote endpoints (i.e. if you can use a web browser), you'll be able to tunnel whatever you like through it.  For example, a backchannel can easily be constructed using HTTP traffic (or even DNS).  Firewall rules aren't going to stop that.  And the ability of even deep packet inspection is highly questionable too (what if you hide packet data inside compressed images, or if you run the link over SSL?).

[Killer360]

Wait, hold on... it was running Win 2K... sorry 'bout that.

I believe it was also the only one in the library that was still running 2K... I was using it 'cause that was the only one available at the time.

[Chavo]

You can put a VNC client/server on a USB drive and run it from there if you want ;)

That sort of 'vulnerability' should generally be blocked by network traffic rules.  Clearly your school's IT department is not up to par.

This is a fallacy for Internet-connected computers.  If any external network access is allowed to unspecified remote endpoints (i.e. if you can use a web browser), you'll be able to tunnel whatever you like through it.  For example, a backchannel can easily be constructed using HTTP traffic (or even DNS).  Firewall rules aren't going to stop that.  And the ability of even deep packet inspection is highly questionable too (what if you hide packet data inside compressed images, or if you run the link over SSL?).

I wasn't referring to just firewall rules, basic Packet Inspection can easily detect tunnelled traffic, even encrypted.

[iago]

You can put a VNC client/server on a USB drive and run it from there if you want ;)

That sort of 'vulnerability' should generally be blocked by network traffic rules.  Clearly your school's IT department is not up to par.

This is a fallacy for Internet-connected computers.  If any external network access is allowed to unspecified remote endpoints (i.e. if you can use a web browser), you'll be able to tunnel whatever you like through it.  For example, a backchannel can easily be constructed using HTTP traffic (or even DNS).  Firewall rules aren't going to stop that.  And the ability of even deep packet inspection is highly questionable too (what if you hide packet data inside compressed images, or if you run the link over SSL?).

I wasn't referring to just firewall rules, basic Packet Inspection can easily detect tunnelled traffic, even encrypted.

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.

[Chavo]

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

[Skywing]

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.

[iago]

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 the point that "Chavo" is trying to make is that this is likely an externally-sourced connection, so it would be difficult to build the tunnel in the first place. Although it is possible for the tunnel to be built from within the network (especially easy if one of the computers is a member of a botnet), it seems like a lot of trouble to go to in order to use VNC (or similar) on Killer360's computer.

It's more likely that somebody who's already on the network (back when I worked in government, multiple schools in Winnipeg (which is where Killer360 lives) were on the same network, and may not have had security devices to separate the schools' networks). I think that's more likely than somebody using an encrypted tunnel.

Another option is that the computers are thin clients, and a connection got crossed or something. :)

[Skywing]

I think the point that "Chavo" is trying to make is that this is likely an externally-sourced connection, so it would be difficult to build the tunnel in the first place. Although it is possible for the tunnel to be built from within the network (especially easy if one of the computers is a member of a botnet), it seems like a lot of trouble to go to in order to use VNC (or similar) on Killer360's computer.

It's more likely that somebody who's already on the network (back when I worked in government, multiple schools in Winnipeg (which is where Killer360 lives) were on the same network, and may not have had security devices to separate the schools' networks). I think that's more likely than somebody using an encrypted tunnel.

Another option is that the computers are thin clients, and a connection got crossed or something. :)

Perhaps I was unclear about that point.  The article I linked to and my posts were relating to the compromised host building out a connection instead of the other way around.  "Reverse link" connections like this are actually extremely common for malware nowadays, so ruling it out as "a lot of trouble" is something I would avoid doing.