how to keep IT from spying on me

[flyinmac]

There are places that actively monitor, watch, read, etc. every line of code that passes through the wired and wireless network. Regardless of whether it is personal or company computers.

The local university does that. And guess what... they can continue to monitor and trace that wifi communication as they walk the halls and locate the offenders wifi device.

We've even messed with them by hiding a wifi device in the walls and ceilings without telling anyone. And the IT department came running straight to it in less than 3 minutes. They are on it.

Some companies take this stuff seriously. Fortunately, in our case, while we were busted, they were impressed by what we had set up, and how well we had concealed its tracks, that they gave us a little bonus to encourage further development of our skills, as long as we promised to not do it on their network again.

And for the record, nobody at the school had any idea that we were even contemplating the little experiment. So IT was at their usual level of alert.

But, they do come running fast anytime any student attempts to violate any rule. And they will walk right up to you and identify you as the problem.

Every packet of data on the network is actively monitored. And every violation of the rules is immediately caught. You see them coming.

After observing this a few times, the instructor taught us to use the same tools. It's actually very simple. And it's interesting to play with.

We can actually sit in the classroom and monitor the data traffic in the building if we want to. And the portable tracer is very accurate. We've been experimenting with trying to trick it (under supervision). It's an interesting device.

 

[OriginalAppleGuy]

it will come down to local laws and enforceable clauses in their employment contracts

Companies own their networks and are responsible for any activity that occurs on them. As has been posted already, companies will generally be concerned with network traffic. They can, though, state that they may require access to files on a device attached to the network.

Wouldn't information like logins be sent over HTTPS?

You know that passwords are encrypted right? Even in the case of stored passwords, they are not stored in plain text

True - but companies can insert a device that decrypts SSL traffic, inspect it, then re-encrypt it and send it on its way. They have the option to not do that with some traffic and many ethical shops will not intercept banking information.

A great security team on large network always should set a Server group rule that users could not use USB open ports!

USB ports are required for a number of things. On servers, maintenance items may be USB only. A good practice may be to enable them only when needed, which should be rare. For PCs, however, it gets tricky. There are some workflows that may require USB access. A company can install a client to inspect what is being copied to and from USB. One to keep Malware from installing. Another to ensure certain types of protected data are either logged and/or prevented from being copied.

It's never a good idea to try to thwart IT on a company network. Many things are logged for later reference. Because the company is responsible for what happens on its network, it has the right to monitor and take action. I've known people who used VPN tunneling from company assets that were terminated for the behavior. I really like the idea someone posted about using a virtual desktop to use while you are at work but you have to understand the host system may still reach out with questionable activity. A dual boot system would work best or as another poster stated, create a new login that has restricted directory rights.

 

[Toutou]

I use the WIFI at work … IT can watch you … going through my files and stuff

If you're on their network, they can intercept every byte sent or received by your computer, but that's all. Nobody can just "go through your files", unless you have some kind of file sharing or remote login service set up. Your computer is a "black box" to the outside.

It's YOUR computer and if they're okay with you using it, it's none of their business. And wouldn't be even if you had 2TB of weird japanese porn saved right on your desktop.
Just be careful not to download that stuff through THEIR network

 

[soundsystem00]

I just ended up making a second user and have been using that at work. I feel much more comfortable like that. like I said, I don't have anything to hide, but I don't want people seeing my stuff either. The company is fairly small, and I think there is just one IT guy. He looks like a stoner/heavy metal dude. I don't mean to profile, it just seems like he might get bored one day and decide to snoop or something. I don't know if I trust him. Haha. Plus, my main profile had my name on it, and I am gaining popularity at the company. SO, it would be easy for him to decide "okay lets see what this guy is doing, I am bored."

 

[thekev]

True - but companies can insert a device that decrypts SSL traffic, inspect it, then re-encrypt it and send it on its way. They have the option to not do that with some traffic and many ethical shops will not intercept banking information.

That's non-trivial, and inspecting banking information would be asking for a lawsuit. I'm not saying it would be winnable, but that kind of nonsense is an unnecessary liability.

 

[Mikael H]

That's non-trivial, and inspecting banking information would be asking for a lawsuit. I'm not saying it would be winnable, but that kind of nonsense is an unnecessary liability.

I'm sure laws differ, but where I live, as long as we can show that we do our best to keep an up-to-date whitelist and inform users that their traffic may be monitored on company networks, there's really not much more to it.

When it comes to inspecting SSL traffic you need the clients to accept the certificate(s) of the inspecting device(s). This basically means you need to have control over devices whose traffic you analyze if you want to do it silently - otherwise much of the well-written software out there will refuse to work at all, and you'll get all kinds of visual warnings when using a web browser. An observant user will see that even though the closed padlock is there in the address bar, indicating you've got transport layer security, the certificate it has verified belongs to the company whose network they're using, not to the server they're visiting.

 

[960design]

Wouldn't information like logins be sent over HTTPS?

We can see http traffic on the network

 

[thekev]

I'm sure laws differ, but where I live, as long as we can show that we do our best to keep an up-to-date whitelist and inform users that their traffic may be monitored on company networks, there's really not much more to it.

When it comes to inspecting SSL traffic you need the clients to accept the certificate(s) of the inspecting device(s). This basically means you need to have control over devices whose traffic you analyze if you want to do it silently - otherwise much of the well-written software out there will refuse to work at all, and you'll get all kinds of visual warnings when using a web browser. An observant user will see that even though the closed padlock is there in the address bar, indicating you've got transport layer security, the certificate it has verified belongs to the company whose network they're using, not to the server they're visiting.

Sure. I get most of that, although I know very little about the specification details of SSL. I meant it's lawsuit material in the sense that someone is likely to sue if their information is compromised, and most companies would prefer to avoid dealing with that.

 

[C DM]

We can see http traffic on the network

You are saying you can see encrypted data and decrypt it?

 

[960design]

You are saying you can see encrypted data and decrypt it?

[attempted-sarcasm]actually typed it, but[/attempted-sarcasm] yes.

 

[flyinmac]

What should be recognized, is that the encryption is performed using a predefined method. Decryption occurs on the other end because the receiving machine already knows which protocol is going to be used for encryption. Since the method is established, and not random, decryption isn't really that complicated if the code is viewed while in transport.

Understand that viewing network traffic is not intercepting it or diverting it. No alert will be provided to the sender. It is just code passing through a wire. Viewing that code, can be done live, and then copied and decrypted.

It's like watching a bird fly past the living room window. I saw the bird, the bird doesn't know I saw it, and neither does anybody else. But, I could take a picture of it as it passes by, and then analyze the picture if I so choose.

Given that encryption and decryption of information requires a universal language to allow the receiver to know how to interpret the information, all that needs to occur is to view the code as it passes through the wire, and then decrypt it using the same protocol that it was encrypted with.

It's not really that complicated. Security and encryption are only secure as long as nobody cares to invest the effort. One should assume that everything you do is being viewed by somebody somewhere, because it's quite possible that it is.

 

[C DM]

[attempted-sarcasm]actually typed it, but[/attempted-sarcasm] yes.

So that's a no then? Not sure what you are trying to say.

 

[Altemose]

IT rarely has the time to randomly watch people. They're too busy resolving help desk tickets.

At least someone understands what we really go through...

Dang! I have nothing to hide other than a small amount of legal porn on my browser history and in my file folders. Still though, I feel weird that they could access that at my job. Also I don't like them seeing my facebook passwords, bank password, and countless personal info. What if I open a new user account on my computer and just use that at work?

Essentially, any traffic that goes across their network is at liberty to be exposed. Your personal data stored on the local machine will not be accessed unless they have installed some software to do so.

 

[Mikael H]

What should be recognized, is that the encryption is performed using a predefined method. Decryption occurs on the other end because the receiving machine already knows which protocol is going to be used for encryption. Since the method is established, and not random, decryption isn't really that complicated if the code is viewed while in transport.

Actually, that's pretty much exactly the opposite of true.

The entire point of a good encryption scheme is that it doesn't matter whether you know everything about how it works as long as you don't know the private key of the recipient/server. Most encryption schemes in wide use today are good - as far as we know.

What we are discussing in this thread, is exactly what you said isn't being done: diverting data from a connection between a client computer and a server computer, presenting the client computer with a certificate that they trust so they don't suspect anything, and acting like an otherwise invisible proxy between the client and the server so the server doesn't suspect the client has been compromised. This is a classical man-in-the-middle attack, only when it happens on a corporate or state level we usually use euphemisms for it.

 

[flyinmac]

Actually, that's pretty much exactly the opposite of true.

The entire point of a good encryption scheme is that it doesn't matter whether you know everything about how it works as long as you don't know the private key of the recipient/server. Most encryption schemes in wide use today are good - as far as we know.

What we are discussing in this thread, is exactly what you said isn't being done: diverting data from a connection between a client computer and a server computer, presenting the client computer with a certificate that they trust so they don't suspect anything, and acting like an otherwise invisible proxy between the client and the server so the server doesn't suspect the client has been compromised. This is a classical man-in-the-middle attack, only when it happens on a corporate or state level we usually use euphemisms for it.

There's a difference between interception and watching.

The tools for watching the data on the network provide you the ability to view data as it flows. And, guess how the private key is transmitted.... that's right, over the network. If your admin is actively watching all data packets that transfer over the network, he does have your "private" key. The private key is transmitted in the first packets of a session the "CLIENTHELLO and SERVERHELLO". If he saw that first packets go by, then he has your private key.

It is also possible that an admin could simply set to capture a copy of all data if he didn't want to bother with watching it pass through live. Essentially, the program would just watch all data that went over the network, and when he came back later, he could view the log.

It's quite different from a man in the middle, because it is not being intercepted or redirected. You are just watching it as it passes through your own network.

The reality, is that none of the methods used are "secure". Security is only good, if nobody is watching or if nobody cares to invest the time to read your data.

If someone decides to monitor all data that passes through the network, they will have everything they need to "decrypt" the data.

If they miss the crucial packets, then perhaps it may become more difficult. But, that just means that they'd need more advanced tools.

Nothing done on the Internet is going to be truly secure. There is just "more secure" options available than having no security.

 

[Mikael H]

There's a difference between interception and watching.

The tools for watching the data on the network provide you the ability to view data as it flows. And, guess how the private key is transmitted.... that's right, over the network. If your admin is actively watching all data packets that transfer over the network, he does have your "private" key. The private key is transmitted in the first packets of a session the "CLIENTHELLO and SERVERHELLO". If he saw that first packets go by, then he has your private key.

It is also possible that an admin could simply set to capture a copy of all data if he didn't want to bother with watching it pass through live. Essentially, the program would just watch all data that went over the network, and when he came back later, he could view the log.

It's quite different from a man in the middle, because it is not being intercepted or redirected. You are just watching it as it passes through your own network.

The reality, is that none of the methods used are "secure". Security is only good, if nobody is watching or if nobody cares to invest the time to read your data.

If someone decides to monitor all data that passes through the network, they will have everything they need to "decrypt" the data.

If they miss the crucial packets, then perhaps it may become more difficult. But, that just means that they'd need more advanced tools.

Nothing done on the Internet is going to be truly secure. There is just "more secure" options available than having no security.

I'm sorry, but we may be talking about two completely different concepts.

First of all: Yes, it is entirely possible to siphon off network traffic without affecting it, by connecting some kind of sniffer/netlogger to a dumb network hub, or to a dedicated monitoring port on a network switch.

In the case of regular, unencrypted network traffic, this will tell you all you want to know provided you have the storage space to save enough traffic, and the patience to make sense of it all.


But you completely misrepresent (and, it seems, misunderstand) how TLS and other applications of asymmetrical cryptography work, so let me talk you through it:
The basis of asymmetric cryptography (or public key cryptography) is that the private key is never ever shared. Only the private key can ever be used to decrypt a message.
The public key, on the other hand, is perfectly safe to hand out to anybody. It can be used to encrypt messages, but it it can never be used to decrypt them.

Grasping it all so far? The public key is spread all over the place, and can never decrypt encrypted material. The private key is never ever sent across the line, and is the only thing that can decrypt the message, provided there's nothing inherently wrong with the encryption algorithm.

OK, let's introduce certificate authorities (CA), which are the basis for TLS as we know it on the Internet, and which are the weak point here: A certificate authority is an organization that is generally trusted to identify the owner of a public key.
As I wrote earlier, a public key is used to encrypt a message only the corresponding private key can decrypt. So how do you know that the public key you just got actually belongs to whom you think it belongs? You could get on a plane and meet them personally, check each other's ID, have a notarius publicus vouch for your respective identities, and so on... Or you can have a number of organizations that do that for you and who keep a register of a bunch of public keys and their respective owners. This is safe, generally speaking, because again: The public key can't decrypt anything. A CA is basically one of a number of "yellow pages" for public keys.

What happens in your browser when you visit an https:// site?
Your browser is handed a public key. If the public key is signed by a recognized CA who vouches for the server name you've requested, you get the padlock symbol in your address field, and all is well. If it isn't signed by a CA, or if the certificate doesn't match the server that replies, or if the public key has been revoked, or if the certificate signature for the key has expired, you get a big red warning sign.

So how do we use this knowledge to peform a man-in-the-middle attack?
The list of valid CAs your browser uses can be modified. If you can tell somebody's browser that you are a valid CA, you can vouch for your own certificates, and so you can create an intermediate connection through your own server. The user's browser opens an encrypted connection. The public key they receive from your server corresponds to a valid CA (or so it thinks), and you can decrypt their traffic while they see a nice and safe-looking padlock in their address bar. After decrypting it and reading it, you pass it on to the indended server, which thinks you are the user and replies back to your own snooping server where you again can decrypt the traffic, analyze it, and pass it back to the user, who still sees a nice padlock in their browser, and therefore think everything is OK.

If the man-in-the-middle isn't a true CA, however, it's easy to check whether this is happening to you: Just click the padlock and see if it's a known CA who has issued the certificate your browser accepted as valid, or if it's the company whose network you've been using pretending to be a trusted CA.

On the state level, an organization may actually be issued true, valid CA certificates with which they may sign their own "snooper certificates", and then it gets truly hard to know whether someone actually is eavesdropping on your traffic. To avoid that, you'd have to personally verify each public key you choose to trust, rather than letting the browser decide for you.



Wall of text, I know.
TL;DR: No properly configured encrypted communications channel will ever transfer its private keys as part of the handshake. It isn't feasible to decrypt the contents of such communication while the contents are still relevant without cheating, and the weak link isn't the encryption protocol but the humans using it.

 

[960design]

So that's a no then? Not sure what you are trying to say.

The typing part was the sarcasm... sorry I should have just said yes.

The answer is yes, I can look at ssl traffic on my network very easily.

 

[C DM]

The typing part was the sarcasm... sorry I should have just said yes.

The answer is yes, I can look at ssl traffic on my network very easily.

And you could see that traffic and decrypt it how exactly?

 

[960design]

And you could see that traffic and decrypt it how exactly?

Knowing that this is all academic and you would never use this for nefarious purposes, I'll give you a couple of freebies that are pretty well known.

1) Easy ( script kiddie level ): Duplicated captive portal ( McDonalds, Starbucks, ect ) to trusted root CA cert install ( naming it something familiar like 'VeriSign' ). The user receives the familiar popup during the standard captive portal 'acceptance' then off and running, easy peasy.
2) Medium ( college hacker level ): sslstrip -> arpspoof = MITM
3) Browser https vulnerabilities, common root CA cert exploitation, malware to premaster key push, precomputed ( rainbow table ) stream analysis...

 

[Mikael H]

And you could see that traffic and decrypt it how exactly?

See my previous post. If you control the exit point between the private network and the Internet, it is possible, but doing it covertly as a private entity requires that you can install a certificate on computers accessing the Internet.
On a corporate network with company-issued computers, that's not a problem at all in the majority of cases.

With private machines, like in the case of the OP, it's still possible to forcibly break open SSL traffic in the way I described, but a) any sane person will be unable to ignore the big red warning signs, b) most browsers will do their utmost to stop the users from using TLS connections through such a proxy, and c) sanely written web-based services won't accept a client that can't show evidence of working end-to-end encryption.

EDIT: @960design gave you some examples of how to do it if you don't need to stand accountable for your methods.

 

[GalaDaliGirl]

There are places that actively monitor, watch, read, etc. every line of code that passes through the wired and wireless network. Regardless of whether it is personal or company computers.

The local university does that. And guess what... they can continue to monitor and trace that wifi communication as they walk the halls and locate the offenders wifi device.

We've even messed with them by hiding a wifi device in the walls and ceilings without telling anyone. And the IT department came running straight to it in less than 3 minutes. They are on it.

Some companies take this stuff seriously. Fortunately, in our case, while we were busted, they were impressed by what we had set up, and how well we had concealed its tracks, that they gave us a little bonus to encourage further development of our skills, as long as we promised to not do it on their network again.

And for the record, nobody at the school had any idea that we were even contemplating the little experiment. So IT was at their usual level of alert.

But, they do come running fast anytime any student attempts to violate any rule. And they will walk right up to you and identify you as the problem.

Every packet of data on the network is actively monitored. And every violation of the rules is immediately caught. You see them coming.

After observing this a few times, the instructor taught us to use the same tools. It's actually very simple. And it's interesting to play with.

We can actually sit in the classroom and monitor the data traffic in the building if we want to. And the portable tracer is very accurate. We've been experimenting with trying to trick it (under supervision). It's an interesting device.

LoL.


No one has the time. I work for a company that has all of these tools (Veriato) and no watches. Trust me.

They only open these up when there is an incident.

But no one is watching packets like this. None of these dudes has the time.

Should they be? U bet.

But I know that 99.99% of companies that have these tools rely on basic security - USB GPOs and rogue device detection.

No one is watching your packets 24/7.

Lots of foolish talk in this thread. Some legit. Some useful. But mostly fluff.

Use teamviewer portable, rename the EXE, and login to your home machine. Best way to play. That's how we do it.

 

[960design]

No one has the time. I work for a company that has all of these tools (Veriato) and no watches. Trust me.

That is the truth. Not enough people power to even watch a single stream, much less an organization. We only look if given an obvious reason. We spend enough time just trying to keep our systems safe, much less watch yours.

Use teamviewer portable, rename the EXE, and login to your home machine. Best way to play. That's how we do it.

Teamviewer accounts are not safe. The name doesn't matter, the port detection and transit IP would trigger investigation. Tunneling into computers leads to data leaks at best and loss of your bank accounts at worse.

 

[GalaDaliGirl]

I work in IT for one of the largest professional services firms in NYC and our security guy has no clue how to block teamviewer. All of us use it and he has zero clue.

This fact represents 95% of all IT shops.

TeamViewer with MFA is pretty safe. Of course I can tunnel into my ASA as well.

Anyhoo. The guy wants to play at work, easiest way is to have a MiFi of your own in your pocket. Or use teamviewer. Don't connect to your Corp network if you don't want drama. BYOC. TV.

 

[MacDann]

As an IT security professional in a government environment, I can assure you that every byte that crosses our firewall gets inspected and logged. We use SSL decryption to "see" encrypted traffic with a few exceptions. We employ appliances such as Gigamon, Palo Alto and a SIEM to log, review and retain copies of the traffic and to let us know what it is and where it's going to or coming from. Data loss prevention in our ESAs allows us to drop and grab copies of email and other traffic with sensitive information.

While many enterprise level shops might not go to this length, it's not difficult to do for the most part. There are plenty of open source tools out there that allow you to do what expensive appliances do with a fair level of accuracy. You just need the staff to manage and maintain it, which is typically the issue where most organizations drop out.

All I can say to the OP is that I would definitely run a VM isolated from the host for my work stuff. That and use my mantra, "If it's not work related, leave it at home" to assure that there is no concern about what is and isn't appropriate.

MacDann

 

[m4v3r1ck]

(...) and use my mantra, "If it's not work related, leave it at home" to assure that there is no concern about what is and isn't appropriate.

MacDann

Exactly this!

Cheers