So, we have an intarweb that lets us post all sorts of zany things all over the place, from a ratty MySpace page to a litany of comments on news clippings and blogs and forums.

I know Dan Morrill talks now and then about making sure an employer Googles prospective employees. But what if someone has been posting using your name in various places? For instance, I make little to no effort to mask my online moniker, LonerVamp. But what if someone started using that name maliciously and posting hate and other garbage around that eventually gets indexed?

In response to the 7 things sysadmins forget, Rebecca Herold commented and I wanted to pull it out for a separate post.

Forgetting that their sys admin job ultimately exists to support the business

No kidding! I think there are three mindsets when it comes to sysadmins (and really, IT/business in general).

1. Sysadmins who understand this concept and make decisions themselves on how their job relates to the business.

I consider these sysadmins to be empowered admins who understand their job. They can prioritize their time and make decisions frequently on their own that really do benefit the company and their own role. The sysadmin with this mindset tends to perform risk assessment and decision-making in her head and can sometimes be seen as making rash (but hopefully accurate) decisions.

2. Sysadmins who don’t care about this question and instead defer this layer of involvement in the business to their boss.

Sysadmins at this stage seem to need lots of things escalated to their manager, even when small ticket requests have slightly larger implications. They do their job well, give a nice point to their manager on their views, but ultimately let someone else make a decision for them. Some sysadmins may get forced into this position based on the company and managers they interact with. When bureaucracy does not exist, this may be a result of lack of respect and trust given to the sysadmin such that he is not allowed to make his own decisions. Other times, this is just the style the business prefers.

3. Sysadmins who forget this all the time and really think the business exists to serve their job, or better yet, they only see their job as being ultimately important.

These sysadmins are typified by saying secure this secure that, even if it impacts business negatively. They make decisions based on their job only. Sometimes this is good, especially in a large corporation where you only really have a small slice to make decisions around anyway, but typically this is a negative mindset where the admin is likely never feeling fulfilled and really never fully gets his way…ever.

I think it would be beneficial to see which sysadmin one is, and what sysadmin the company nurtures. Even something as simple as me being a #2 sysadmin but in a #1 company can lead to unhappiness and underperformance. For instance, I like making decisions quickly on my own about what security and IT initiatives to do and how to do them, but if I am in a company where my boss and other managers hate that, I likely won’t be very effective and we might all end up turning in sourpusses over time.

A goo friend of mine and I were talking this weekend and the topic came up of corporate (and beyond) cyber espionage only just starting to be a force. I really believe that as more and more people have insecurity skills and our society continues to become more digitally dependent on information as our lifeblood in business, corporate espionage (which really has always been around) will only become more and more prevalent.

I wonder how many corporations (truly!) think it would be moral/immoral to:

1) Do some cyber “recon” at tradeshows on your competitors. Or maybe just DoS them during their demos? (active and passive attacks)

2) Hire some group to perform a DoS against a competitor’s website/service during a particularly important moment.

3) Perform recon to continually footprint and find systems and sensitive information. Do you know how often a company can give away new projects just by their public DNS entries?

4) Perform dumpster diving regularly?

5) Feel ok with profiling and possibly probing employees home networks (particularly wireless)? Think c-levels and remote sales, for starters.

6) Send malicious emails to targeted persons in a rival company hoping to root the system? Do you know how quickly someone running as local admin can have a malicious program installed which can then sniff and or grab email account passwords for very important people and then send it back to someone who can log into webmail whenever they want?

7) Try to guess some webmail passwords of important people?

8) Pay for someone who has information about a rival because this person just sits at major airports and attempts wireless attacks against travelers, looking for juicy connections and info to sell?

I really think this is only going to get worse and much more commonplace. Besides, much of this stuff is still way too easy to perform, and in a way that is still way too anonymous. And I think anyone who has been online any amount of time knows that laws are more “easily” broken when you’re not standing in front of a police officer. Physical presence is a barrier that most often protects our physical safety, but that deterrent is completely absent online.

It sounds like someone traced back the TJX breach back to a store in Minnesota that employed WEP as their only(?) protection for their wireless system. While this is a simplistic announcement, it certainly is not the whole story.

This illustrates how just one weak part of a huge network (or business) like TJX can bring the whole thing down. You can roll out secured (?) wireless to 1,000 stores, but it just takes one store whose manager doesn’t quite understand the technology (should they really, though?) or one overlooked site by the techs doing the setup and you suddenly become a part of security and business history.

I also wonder where the layered protections were. Did this Minnesota store get automatically bridged into the corporate network that had access to all this sensitive data whizzing by? Did no one have any logs or tripwires up on anything to monitor access? How well did the attackers cloak themselves to look like innocuous or expected systems? Was anyone watching the wireless access logs, or anomalies in data collection/transfer that most probably occurred?

I see that the article mentions software patching was lax. I see that employee logins were sniffed (NTLM or clear text to proprietary system?). Sadly, for as much as we need details to improve security both at TJX and with PCI auditors (and the rest of us!), this is so costly that I doubt we hear more details for years until the courts release it. Did they ever rotate wireless passphrases? What was the real need for wireless in the first place?

So let’s say I’m in Minnesota and see a Marshall’s using WEP on their wireless network. I crack WEP and do some testing and practice some patience to make sure no one’s watching the access and that I don’t trip any IDS. Eventually I get comfortable enough to log onto the network and perform some stealth scans to see what I can see. I bet I can see a lot, including some unpatched machines which I can get a foothold into (in a best case scenario for me, I might just be right on the full corporate network through some dedicated VPN setup). This pretty much shows me that admins at TJX aren’t quite as diligent as they should be, which can put me and my cohorts at ease. From there, I can sniff on systems I own and pilfer what I can. Lack of software patching standards probably mean shared passwords everywhere too.

Blah blah blah…there’s plenty of places where TJX should have detected and or slowed down these attackers. Death by a 1000 cuts is becoming a pet phrase of mine…

David Maynor recently caught some attention by being critical of how Airtight protects a wireless network from rogue APs (and clients). I’ll let the link speak for itself on that, as well as the Airtight CTOs take on the comments section of a post on Andrew Hay’s site (and Mike Rothman’s for that matter).

What I found even more intriguing was the link to a 2005 paper from Joshua Wright discussing the flaws and details in wireless IDS/IPS methods of containing rogue wireless clients. Joshua Wright has an amazing ability in his papers to write very clearly and plainly, making the information easy to follow, and while the paper comes in only at 17 pages, I thought I would paraphrase his key points a bit in this post.

• Wireless IDS detect and then try to disassociate/deauthenticate (deauth from here on) rogue clients.
• Some try send deauth frames to the clients, some also to the appropriate access point.
• Some just vomit out deauth frames, others are more timed to respond efficiently.
• The deauth mechanism is not set in stone, meaning implementation of frames can be done many ways. This combined with the various features means an attacker can detect and fingerprint a wireless IDS to better attack/evade it.
• Detection/fingerprinting can be done via sequence number anomalies in the frames. Some vendors have set sequence numbers. Sometimes sequence numbers can be noticed as different between the wireless IDS frames and the real AP frames.
• Detection/fingerprinting can be done via disconnect notice bit anomalies.
• Detection/fingerprinting can be done by watching access point traffic in relation to deauth frames. If an AP really did issue a deauth, it wouldn’t overlap that with assoc or other frames. If an IDS did the deauth, the APs frames may overlap, giving away the IDS.
• Detection can be done by comparing the signal strength bits of deauth and normal frames. Deauths of a different signal strength can give away the IDS presence.
• An attacker can sometimes slip data into a network by slipping in between deauths that are spaced too far apart. Some vendors allow this to be variable or simply leave more time in between deauths so as not to further saturate the wireless media.
• An attacker can modify his wireless drivers to ignore deauth frames such that if an IDS only sends deauths to the client and not the AP, the connection is never torn down because the client takes no action.

Check the paper for more details, including patching madwifi drivers to ignore deauths.

Lists by IT guys cum journalists can be pretty interesting things. Either they’re obvious junk or sometimes just plain wrong. I eagerly checked out this link Marcin sent me about 7 things sysadmins forget to do thinking it would be pretty stupid. I was pleasantly surprised with a few of the items. Here’s some of my comments.

1. Forgetting to Delete a Former User’s Account – This is one of those obvious ones, but I will defend poor sysadmins like myself and say that we don’t just willy-nilly disable user accounts, even if we hear gossip that someone left. Too often, account disabling is not a breakdown of sysadmins, but a breakdown in the process of notifying sysadmins that someone has left. I really hate hearing someone “left 3 weeks ago” through the grapevine. (Or conversely, that “I have someone started tomorrow morning…”) Maybe in huge environments things like identity management should be looked at to solve this issue, but in smaller or medium environments, I really think HR and IT just need to make sure there is a process for account notification that is followed. In the end, all the sysadmin lists and processes are naught if no one says so-and-so is gone.

2. Forgetting to Regularly Search for Rootkits – Ok, this is just kind of a weird one. I don’t think I’ve ever “forgotten” to search for a rootkit so much as I just don’t look for them, or if a system is so obviously overrun it gets reformatted rather than spend more time on it.

I think the author has good points about how to mitigate rootkits and detect them, but seriously, how many admins put forth that much effort? Rootkits are the Harry Potters of the corporate IT household. They want to be kept under the stairs or up in their room and ignored and not dealt with…and for good reason. It is almost like having mice in your building. You can put out some traps, but really, no one is going to bother much with tearing up the walls trying to find their homes.

I sound kinda defeatist here, but the effort to find and protect against rootkits is a big investment, really. I just think this isn’t so much forgotten as it is just chosen not to be done.

3. Forgetting to Use a Trouble Ticket Tracking System – Here’s a personal bit about me: I’m a stickler about documentation and the sharing of information. There is too often a HUGE amount of organizational knowledge that leaves when an IT worker leaves a position. That shouldn’t be the case, they should keep things documented for someone else to reference.

A trouble ticket system is part of that. If I know I’ve worked on something before, I want to be able to search the tickets and see what remediation occurred previously. I think some of this comes from my science background where experiments have to be documented such that someone else can recreate your findings. That”s a big part of what a ticket system is to me.

Not only that, but it can be used to audit changes and requests. If Sally requested file server permission changes and was authorized to do so, but made a stupid request that caused data loss, that can be traced back to her ticket and the information in it. I also feel that, as a heavily-worked IT guy (and later on in my career, likely a manager of some sort), the ticket system is a natural means to track work loads and inefficiencies and reduce forgetfulness. Unless a ticket system has no means for internal notes (things not sent back to the requester) I really hate, hate, HATE to see tickets answered with, “Done,” and absolutely no details on what was done…

There is one caveat to this, however, and would be Needy Users who have Stupid Questions but they insist on asking in person or calling in about them when their deadline is 1 hour away. Often, it might not be sysadmins who forget to use the ticket system, but users who bypass the ticket system to saddle IT with work requests. Sysadmins are then left to hopefully remember to put in the ticket themselves.

4. Forgetting to Set Up Technical Documentation and Creating a Knowledge Base – Based on my notes above, it’s pretty obvious this is a sticking point with me as well. I deeply believe in the need for clear, effective documentation and maybe even a knowledge base. This should occur in IT shops of 1 person or 1,000 people. Even if I don’t plan on leaving a job, there are always systems and processes that occur every 6 months or longer, and I hate to get to those points and not remember what to do. Referencing documentation helps speed up memory, get the tasks done efficiently, and improves consistency by not forgetting steps or retracing old mistakes. This can even be part of a DR/BCP or backup strategy, where network diagrams, IP distributions, config files, and other settings are documented somewhere for use in continuing the business in the case of large of small issues.

5. Forgetting the Risks of Flash Memory Drives – This also falls into “I didn’t forget it, we just don’t do this” category. By now, I really think everyone knows the issues with USB drives. They can introduce things not wanted and are a vehicle for data egress. You’ll notice the author gives not even a single sentence on how to address this or what approach could be taken. There’s likely a reason for that. Many people either don’t know how to manage USB devices (do you know how to stop USB drives but allow USB mice/keyboards?) or can’t get senior management to back the blocking of ports. Ever try to block USB/Firewire ports and have all the ipod users mutiny? Ever try to justify buying a certain USB brand for “official” use and tell people their personal ones won’t work? This isn’t so much forgotten as it is just not a battle to be fought or teams lack the knowledge to truly tackle it. There are far easier fires for most sysadmins to fight right now. The coming years should hopefully make tools to do these things easier for us admins, but they won’t be getting cheaper or easier on the workforce at large, unfortunately.

Of note, for anyone who wants to limit USB drives, did you also limit floppy drives back in the day? Do you limit CD drives now? What is your basis for managing those differently? Honestly, USB drives can be argued to simply be part of our culture now, just like cell phones and the compact disc. Just be aware of that when trying to limit them and how that might affect employee happiness aka productivity, especially if your business is not subject to stringent regulations about tracking data egress.

6. Forgetting to Manage Partial Root Access – I don’t really have anything to say here.

7. Forgetting Courtesy – This is a mixed bag with me. I agree, courtesy needs to be extended in a company, not just from IT, but from everyone. Each company is really just one big team trying to work together to do Great Things, but too often that courtesy breaks down somewhere, and that little ghost of rudeness gets passed around like a flatulence cloud hovers and moves unexpectedly.

Yes, some IT guys are just rude and give evil looks when asked to assist with something. But I’ve often seen and felt that some of that rudeness is not something IT guys inherently do, but have been trained to do by poor management or abusive users. How many IT guys have tried to do the right thing by helping people, only to get sucked into tasks that aren’t their responsibility just because they happened to make eye contact at the wrong time or try to help someone else?

At my last job, we had an HR director who needed regular help with her computer. I gladly stepped up and enthusiastically helped her early on. But she was one of those people who cannot be satisfactorily helped unless you do her job for her. Sadly, I couldn’t do that, and some of the things she wanted were simply not even possible. She became the “oh god, don’t help her, don’t get involved because you can’t win! Even if you win, she’ll eventually get you to do things that you just can’t do and then you’re in the shitter!” IT support nightmares. In fact, I think every IT guy at that company who has tried has either left that company or is still in the shitter with her (and being in HR, you know what that means…). (Hell, I even got in trouble once because she asked me to rewire an electrical outlet and I said that needed to be done by a qualified outside contractor that the CFO would set up…)

Too often I really think IT guys are conditioned to be evil eye guys and this is as much a reflection on the corporate culture and their managers as it may be their inherent personality. Some people are assholes, but a lot of us are not.

(By the way, a lot of us IT guys have a ton of things to think about as we walk the halls to get from one place to another; we’re often thinking about some problem or improvement, so if you stop us in the middle of the hall with some Stupid User Question and get a queer look, that just might be us trying to switch into help mode or tie off our internal thoughts to properly come back to them later. Or we know that Needy User has just circumvented the aforementioned ticket system by asking us in person, and will give us his own Evil Look when we plead that he make a ticket request since we’re currently in the middle of something for More Important Needy User…it’s a no win situation for us sometimes.)

Start the weekend off right with some off-topic reading pleasure. EW has a list of the top 25 moments in sci-fi in the past 25 years (and proper apologies for not being able to include Star Wars 1977 because it is too old). I definitely think I have a few television shows to watch as they appear on DVD. Excellent list!

I’ve posted about baretail previously as a tail program for Windows, but now I see there is a similar tool with some more functionality to it. fLogViewer picks up and runs with the “Windows way” by taking a simple tool and putting more and more features onto it (note: Yes, I am fairly sarcastic there, but the features are appreciated nonetheless!). I kinda like this tool, although the necessity of an install and the way it uses some older system files than what I have on my XP system anyway are detractors to replacing baretail with fLogViewer.

I like the idea of posting regularly the things that I’ve learned. I’ve long put off getting SSL on this site, but I think I need to get with it to secure what few logins I have (which I only use at work and home anyway…). Curiously, this week I’ve been working with SSL at work, so I learned a few things running OpenSSL. Here are the basics. (technically I relearned this since I’ve done this all years back, but had to look it all up again anyway…)

To split an exported private key/certificate from IIS (.pfx format) into a more readable format:

openssl pkcs12 -nodes -in exportedfile.pfx -out outfile.pem

If you provided a password (like a good IIS admin!) to the exported private key, you will be prompted for it. To view the private key and certificate parts, just open the resulting pem file in a text editor. Both parts are enclosed in appropriate tags.

To just view the private key and certificate from the pfx file:

openssl pkcs12 -info -nodes -in exportedfile.pfx

To make a Certificate Signing Request (CSR):

openssl req -new -newkey rsa:2048 -keyout yournewkey.pem -nodes \
-out yournewcsr.pem

Save the key because this is the private key. Provide the yournewcsr.pem contents to the preferred CA such as Verisign, Thawte, or even your local CA if you have your own PKI. Once you get the certificate back and you’re using Apache, you want to follow Apache instructions (I’ll post this another time) to place the private key file and this cert file where Apache can use them. If you’re using IIS, you probably want to convert it back into the normal pcks12/pfx format:

openssl x509 -in certnew.cer -inform DER -out yournewcert.pem \
-outform PEM

You can then import it into IIS for use with web sites. In my case at work, we just left the pieces separated for use in our new Load-Balancer/SSL Terminator. Our IPS, however, would prefer the compounded format used by IIS along with the passphrase.

What if you just want a self-signed cert? This means it is free to you, although your browser may give fairly benign complaints about the cert not being signed by someone you trust. This is ok for most sites, including mine and other internal stuff:

openssl req -x509 -days 365 -newkey rsa:2048 -keyout myselfsignedkey.pem \
-nodes -out myselfsignedcert.pem

Might want to increase the 365 days to many, many years. Ten years is pretty decent and a bit easy to calculate (3650).

All of these commands used -nodes which does not mean “nodes,” it means “No DES.” This leaves the private key unencrypted. For anyone who has studied CISSP material (or even Security+) you really don’t want to leave your private keys unencrypted. You want them encrypted:

openssl rsa -des3 -in  \
yourprivatekey.pem -out yourprivatekeyencrypted.pem

This will prompt for a passphrase and output the private key in an encrypted form. If you want to decrypt this key later:

openssl rsa -in yourprivatekeyencrypted.pem -out yourprivatekey.pem

I think that about does it for now. OpenSSL has tons of little options and modes, so if you find yourself getting an itch to learn more about SSL, check it out. Oh, and it comes in Linux and third-party Windows flavors for convenience. I actually really like the Windows version as it gives some nice, powerful tools for quick use to otherwise clunky Windows GUIs and servers.

Roger A. Grimes recently posted up an article that made a lot of simple sense. He talked about the effect of consistency, even amongst just the basic security principles, and how that can increase security. I really couldn’t agree more. Consistency is highly important. Of course, metrics are important, but also make sure to pick the right ones and be consistent with them as well.

How many of us work in computer security environments where basic
security recommendations are not applied consistently? I think it is
nearly impossible to find a company that consistently and universally
applies basic security tenets. So, we have inconsistencies, cracks in
the system, and bad things are allowed to occur. The very human nature
of purposefully allowing inconsistency as a norm leads to below-average
outcomes. Taking a personal and institutionalized interest in applying
basic security principles consistently will mitigate more risk and lead
to a more secure environment.

If you impose punishments on the troops before they have become attached, they will not be submissive. If they are not submissive they will be difficult to employ. If you do not impose punishments after the troops have become attached, they cannot be used. -The Art of War, Chapter 9: Maneuvering Armies

WSUS 3.0 has been released. I’m bouncing this link over where I found it, The Sean Blog, since he made a nice list of the pertinent downloads. If you don’t know WSUS or don’t use it and don’t do anything special for Windows patch management, you should really look into WSUS. It does one set of tasks and does it very well.

Web browsing (blogs, forums, web-based IRC) – When you browse the web, you leave a trail in your wake: your IP address and sometimes other bits of data that curious persons want to gather. If nothing else, you leave behind your IP in web server log files which any curious or enterprising admin likely picks through. Why do you want to stay anonymous? That was addressed in part 1 of this series.

There are five major realms when it comes to anonymity on the web:
1) general anonymity protections
2) browsing trackbacks such as what is captured in web server log files
3) browser hijacking, remote information leakage, and artifacts like cookies
4) communication channel eavesdropping
5) additional items on newsgroups and RSS

1) general anonymity protections
In general, if you want to stay anonymous online, don’t connect to sites or other servers from your home IP address. Hop on a wireless hotspot or “borrow” a neighbor’s wireless connection (again, I didn’t suggest that…right?). This way any tracebacks will maybe point to the state or area you live in or even your local podunk ISP, but likely won’t be tracked back directly to you without some legal overtures. If you’re doing nothing criminal, the chances are slim that anyone will ever notice. (Although that does not necessarily make it legal or digitally ethical.)

If you insist on doing personal things such as banking or updating your own personal blog that is not so anonymous, those are things you should save your home IP and connection for. Keep in mind that I do not encourage checking your ebay auctions or transferring paypal monies through web proxies or while connected to non-trusted networks. You never know who is eavesdropping on you or collecting information on what you thought was an innocent open web proxy.

2) trackbacks via what is captured in web server log files
Browsing trackbacks include leaving behind information on log files that may contain your IP address, computer name, browser version, and so on.

The biggest means to stay anonymous with general web browsing is to use one or more anonymous web proxies. A web proxy will relay your connection from it to the site you are attempting to browse, such that the target site does not know who you are and instead records information from the web proxy server. Let’s say you want to buy some condoms, but your dad works the counter at the closest drug store that sells them. Instead, you ask someone else to go inside and buy them for you. This person is acting on your behalf, i.e. your proxy. Web proxies work the same way by fetching web pages on your behalf and then delivering them to you. Honestly, once you start using proxies, they are very easy to use and you should probably use them most the time if you are concerned about your anonymity (with the exception of your bill-paying and banking…).

These can be a bit of a pain to work with. Some web proxies are located in odd places of the world and thus their latency is sometimes prohibitive. Others actually translate text for you (eternally helpful, especially if you don’t speak Lithuanian…), and others are simply not meant to be open and can disappear without notice. Some are commercial and some are not and some don’t even know they are open and used.

One long-standing list of web proxies has been samair.ru. Be aware that not all proxies are made equal and you will want to test out just how anonymous you appear. Do not settle for leaking any information, so typically, you want “highly anonymous” or something to that effect. Setting yourself up on a proxy is as easy as picking one out and going into the connection options of your browser. Supply the necessary IP and port as a proxy and surf away. You can check what your IP appears to be at www.whatismyip.com and you can check your actual proxy leakage at samair.ru. I highly suggest Googling up a few proxy checker tools just for second and third opinions. Also, try baselining the information you leak by using these checkers when you’re not using a proxy. Identify what you want hidden, and get it hidden. (Disclaimer: I don’t encourage you to use web proxies that you are not authorized to use; do as you wish.)

I also have seen a site called www.e-proxy.info (thank you Chris!) which can deliver web pages to you through a browser-based proxy. This is really pretty slick and actually works in my office, bypassing SurfControl while also not looking too obtrusive by hiding up at the top of my browser window. Sweet!

As an advanced technique, if you want to set up a series of proxy servers to route your traffic through, this is typically called chaining, in case you want some Google terms to search for.

Are these foolproof? Like almost everything in life, no they are not. But for many instances, a relatively simple step like using a web proxy gives quite a lot of gain. One potential problem comes up if you use some arcane or exotic user agent or web browser. If you leave behind an anonymous IP but a user agent like “BriansTestBrowserBar 0.4,” you may as well ditch the proxy.

3) browser hijacking, remote information leakage, and artifacts like cookies
While you can remain relatively anonymous on the web using just a proxy to relay your connections, there are still means to leak information. You might run into hostile scripts that will try to hijack your system or perhaps harvest cookies from your browser, just to name a few.

To thwart such attacks, it is best to not pretend you are safer or anonymous using Windows or Internet Explorer, especially in combination. Use a non-Windows OS and Opera, Firefox, or even a graphical browser.

Keep your cache and stored cookies as clean as possible. Try not to store cookies and definitely do not store passwords in your browser. Just write them down or store them more securely out of band of your browser. In fact, it makes a lot of sense to do your anonymous web browsing from a virtual machine that you can revert to a known clean state every day.

Be sure you also do not leak information by reusing usernames and passwords. If you use the username TheAvengerr69 on 4 forums and you use the same password on each one, simple Google searches can draw the lines between them and start revealing a profile of who you are and what you do. This is especially useful to someone looking to manipulate you. Also assume that every site you sign up for has curious admins who now have your account information. Do not blindly reuse login names and/or passwords.

Here is an illustration. Think about how many forums you might have signed up for and posted one, maybe two questions, and then never revisited again. What if those forums, like the many thousands out there, do not get updated with new forum software versions. This might mean that one of those forums may get owned and leak out its database of users (sure, they just want the emails to spam, right?). Now your account information is in someone’s hands just because you visited there once. Now let’s say your username was DopplegangerJoe69 and your email was a hotmail address and your password “sitonyourface.” In fact, that’s the same password and username you use in a few places. Oh my, and that’s the password you use for that hotmail account. Sucks to be you, Joe. I hope you don’t store a lot of “password reminders” and “thanks for signing up here’s your password” emails on that hotmail account!

4) communication channel eavesdropping
Generally, there is not much you can do to protect the communication channel from eavesdroppers, if, for instance, you are browsing the web from a public hotspot. If the site itself does not have SSL enabled, you are typically out of luck. However, some proxies can be set up to relay secured communications. Better yet, find yourself a box or shell account or buddy who doesn’t know better and set yourself up an SSH tunnel which can act as your first hop. While your entire communication may not be hidden, at least you are hidden from where you physically sit to some arbitrary place on the net. The easiest way to do this might be to set up an SSH server and tunnel through your home connection. From there, relay through a web proxy to anonymize yourself. You can also utilize Tor onion routing, which I plan to go over in a separate post.

Of note, I do consider this step to be beyond most everyone but the paranoid, but it does make sense to technically-friendly people who browse from untrusted networks often. Personally, I love hotspots at coffeeshops so I tend to tunnel through SSH whenever I do anything beyond browsing the news.

5) additional items on newsgroups and RSS
Two minor tidbits on newsgroups and RSS feeds. Try to not use stand-alone clients on your box for RSS or newgroups browsing. They typically aren’t as universal when it comes to proxy support, so they tend to directly connect to the target and leave behind your IP address, if nothing else. Whenever possible, sign up for Google Reader or Google Groups and leverage the extra hop that Google provides in hiding origin. Let Google’s servers act as your proxy. Be aware that there is still theoretical talk about malware abusing RSS feed parsing. I don’t consider this a reality yet, but the theory is sound. Newsgroups also may have messages that contain malware or malicious links. Be cautious.

Bonus: For the truly paranoid, watch what terms you search for in search engines. Last year there were some high profile disclosures of search terms that, while “sanitized” still revealed sensitive or private information. If I searched for “Michael Dickey” in Google from my “anonymous” web proxy that I’ve used for years, I’ve just tied that web proxy IP to that search term. Do enough of those personally identifiable searches and you can leave behind a small trail. Now, the chances of all the planets aligning to reveal your searches and shatter your web of anonymity are slim, but there are some people that are this paranoid. If you want to help prevent this, just search for personal stuff on your own home connection, just like you should be doing your banking and other sensitive stuff from your trusted home connection. Likewise, don’t search for HideousPurplePeopleEater69, your super-secret online pseudonym, from your home network and tie that name to your home IP.

Do I go to these lengths myself? I definitely do not get draconian about my search terms, but I do encourage using different networks or web proxies for browsing the darker bits of the web. If I felt the need, I likely would also utilize a throw-away VM to do some browsing as well. I think myself and most tech-savvy persons can get by with following, to some degree, steps 1, 2, 3, and 5. Setting up your own remote secure access and being mindful of your searches are really for either the more technically-inclined or the ultra-paranoid.

If you would like more information about staying anonymous on the web, I suggest searching Google for “staying anonymous on the web,” “onion routing,” “SSH tunnel,” and other keywords found scattered above.

Chief Security Monkey has a story post today about being careful what you say as an IT expert:

I went back to my friend, told her that there was nothing unusual on the IDS and mentioned the targeted Word attack that had been reported [by another company] and its similarities. Unfortunately, the helpdesk tech overheard our conversation and subsequently reported back to his boss that I said we were infected and that was the cause.

Oh man, I really hate that! And some people wonder why we become a little guarded and seriously careful about what we say! I’ve had occassion where I’ve responded to spyware or virus and mentioned something about attackers or hackers and the gossip centers on just one word that you can easily guess: “We’ve been hacked!” I’ve had sales people email each other for hours escalating the issue just amongst themselves before someone had to step in and tell them to shut up because it wasn’t true.

Of course, this happens in IT as a whole too. I hate having to say, “Well, in our environment we really can’t implement technology X very well at all…” only to have their Geek Squad son say, “Sure they should be able to do that!” which causes me months and months of grief and point-counterpoint.

Again, I say, it’s no wonder we can quickly become guarded and quiet unless absolutely sure about something.

So, to spin this back around into something positive, how does one combat this? I think it is just all about people skills and communication skills. Make sure people know you as the expert and that mistakes or misstatements can still happen, but you’ll gladly offer correction as needed. Don’t be afraid to be wrong and don’t be so arrogent that everyone wants to hold your mistakes over your head for years to come. Learn who the drama queens are in the company, and be extra careful what you discuss with them.

I see ISC has posted about a vulnerability just disclosed in Trillian. The vulnerability is a little exotic but does have a scary side to it. First, it involves the use of the Trillian IRC client. Thankfully, I don’t know many non-geeks who use IRC and none that use Trillian as their IRC client (I would hope!). The scary part is it is trivial to determine if someone’s IRC client is Trillian and the vulnerability is triggered by merely hovering over a link posted in chat. Yikes! I expect milworm or even Metasploit to have an exploit available soon enough.

One big question for this is: Do you know what apps your users are running? Are some of them running Trillian? And if so, who is then responsible for upgrading to more secure versions of their apps? (Then again, maybe they don’t need IRC at work anyway, so just block the ports at the firewall and hope they’re not on laptops at home being rooted?) More fuel if you don’t have a handle on corporate policy for unauthorized software.