Site Review – LinkedIn – Part 2
- At September 18, 2009
- By Josh More
- In Business Security
0
As a followup to my previous post on LinkedIn, I would like to recount a story that a friend told me the other day. I was visiting with Adam Steen of 25 Connections. Adam’s business is knowing people, and he knows pretty much everyone in the Des Moines business world. If you need a connection in this area, Adam is the guy to go to.
As with many of us in the small business world, he uses LinkedIn to help manage his contacts. However, his business is all about personal connections. This is great for his business, but does introduce a new type of attack that I had not previously considered.
Several months ago, Adam met someone who works in the financial industry. After a pleasant first meeting, he received a LinkedIn connection request. As we all do, he accepted the connection and thought no more of it. Then, last week, Adam got a call from a friend of his who informed him that this connection was using LinkedIn to call Adam’s friends and set up appointments. Of course, he accepted this appointments because the person knew Adam trusted him. After all, if Adam says someone’s good to work with, they usually are. However, Adam didn’t actually vet the connection. Instead, the attacker was using social engineering to make it appear as though he had. Once the appointment was made, Adam’s friend found himself sitting through one of the most uncomfortable high-pressure sales situation he had ever experienced.
So, how did this attack work?
First of all, it is entirely dependent on the nature of the social networking site. If the site is configured to allow your contacts to see one another, you have to consider whether the individuals to whom you are connecting are worth this level of trust.
Secondly, the attack is only useful if the connections are generally trustworthy. If Adam’s name hadn’t meant anything to the person being called, the appointment wouldn’t have been set up and the attack would have been foiled.
Third, if you have a number of close personal contacts who know you but not each other, and you use a social network that allows your friends to see one another, you may be vulnerable.
Now, in Adam’s case, he was able to identify the untrustworthy individual and remove him from his network. Since this particular variant was based on personal contact, the removal of the personal connection foils it. However, it would be trivial to make such an attack far more malicious. An attacker could forge an email from the trusted link that carries a malicious attachment or link. The target then, thinking that the message came from someone very trustworthy, would be fooled into running the code, allowing the attacker to get whatever information they wanted.
So, how do you protect yourself… and more importantly, your contacts?
Think about who you’re connecting to and if you get a request from a friend of a friend, make sure that it’s legitimate. This could be as simple as picking up the phone and calling the purported shared link. (Odds are that you don’t talk often enough anyway.) Also, if you are in the habit of connecting people to one another, try to connect them at the same time. I find that it’s easiest to send an email to yourself and copy them both on it. That way, they get one another’s address, see that you are vetting them both and you have a copy of the connecting email should you need it later. This also makes it more likely that someone who bypasses the process would be more likely to be caught, as it would seem more unusual from the start.
This may be a good time to review your contacts and make sure that they’re really what they should be.
Small Business Defense – Network Reconnaissance
- At September 17, 2009
- By Josh More
- In Business Security
- 0
Yesterday, we looked at the attacker’s view of Network Reconnaissance. Today we consider defenses. As before, your best defense is to segment your network, which limits what an attacker can see from any point on your network. However, there are some things that you can do to reduce the information that an attacker can see if they do get in.
The first is to limit what is actually running on each system. If you have workstations, ask yourself if anyone needs to connect to the systems remotely. If not, turn off all services and activate the local firewall. If so, consider which systems need to communicate and setup VLANs or local firewalls to only allow access from known-good systems.
Second, is to identify the key systems that could be targeted. On those systems, in addition to the basic hardening for workstations, look at scanning defense applications like SentryTools or PSAD. As well, you should be careful to keep all systems up to date. Even if attackers get a network map, it’s not too useful if there is no way to get in.
Lastly, at the network level, there are a few other techniques that can be used. Implementing an Intrusion Detection System will help alert you when someone runs a scan like this. Additionally, you could put a dedicated tarpit system on the network. This system would slow down an attacker and make them easier to detect. Of course, both of these solutions are sufficiently complex that they go beyond the scope of this blog post. However, this will hopefully help get you started.
Small Business Attack – Network Reconnaissance
- At September 16, 2009
- By Josh More
- In Business Security
- 0
Suppose an attacker gets into your network. Last week, we discussed a few tools that they might use to profile different systems, but we didn’t look that deeply into network scanning. Once they’ve done some of the more-basic and subtle checks, they may go on to more active exploration. The advantage of more active exploration is that an attacker can identify all services on all systems in a very short period of time. The disadvantage, of course, is that they are more likely to be detected.
However, since this is an attack day, let’s look at what the attacker can do here. Once they have control of a system, they can use namp to scan the system. Suppose you have an internal file server, other workstations and printers. In seconds, the attacker will have a list of all systems and what’s running on them. For example, here is a (slightly altered) list of systems available from a wireless network.
# nmap 192.168.4.* Starting Nmap 4.75 ( http://nmap.org ) at 2009-09-04 14:01 CDT Interesting ports on 192.168.4.21: Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 8654/tcp open unknown Interesting ports on 192.168.4.249: Not shown: 997 closed ports PORT STATE SERVICE 6006/tcp open X11:6 9220/tcp open unknown 16001/tcp open unknown MAC Address: 00:40:63:99:58:E2 (VIA Technologies) Interesting ports on 192.168.4.254: Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 2000/tcp open callbook MAC Address: 00:B0:D0:C0:54:11 (Dell Computer) Nmap done: 256 IP addresses (5 hosts up) scanned in 12.61 seconds
So here, an attacker would know that 192.168.0.254 and 192.168.0.21 are running ssh, and therefore are likely Linux or Unix servers as well as the brands. For example, a Dell Computer that is running ssh may well be a server worth attacking (in this case, it’s not… but it could be). So, in twelve seconds, the attacker will know exactly what to target. Sure, it’s a noisy and noticeable way to profile a network, but if you don’t notice the attack, it’s well worth the risk.
But what can you do about it?
Security Lessons from Nature – Salamanders
- At September 15, 2009
- By Josh More
- In Natural History
- 0
All amphibians have poisonous skin secretions, which means that the common salamander is coated with a thin poisonous film. While not terribly useful for finding food or mates (the two things that salamanders really care about), it is a good defense against being eaten by passing dogs (or eagles, whatever). Over time, predators have learned to avoid certain amphibian coloration patterns as, not only is poison pretty bad for you, but it probably doesn’t taste too good either (despite the rumors).
So, what we have is a collection of animals who tend not to stray too far from water, aren’t very fast and have almost no practical defenses. To a predator, they would be little yummy blobs of protein but for the little poison problem. What can we learn from this?
The trick is in adapting this technique to business. It’s important to remember that being poisonous doesn’t really protect the particular salamander, as once the poison is ingested, the salamander probably has been as well (and while some salamanders can handle fire, hydrochloric acid probably still burns them).
Since slathering employees in gelatinous strychnine has certain implementation difficulties, we should probably abstract the idea a bit. What we need is a way to let predators know that an attack would be unwise without actually being attacked.
This is often done through the legal system. As Brett Trout has said, a company that has taken legal action in the past is less likely to require legal action in the future. So, one thing to do is to ready your business should court action be needed in the future. This requires a bit more preparation and a bit more attention, but can pay off hugely. For starters, you need to make sure that terms of access are clear and delineated. Practically, this means that each network-accessible service needs to have a banner that makes it clear what is and is not allowed. It means that employee handbooks should put forth clear policies and that local login pages also lay out the rules clearly.
Secondly, you should have some sort of technology in place so you can detect when policies are violated. This could be as complex as an SIEM and Log Management system, or as simple as just looking at access logs every day. Lastly, you should have a lawyer around so that when you do detect something, you can take immediate action.
This way, you have a defense that only needs to be active when under attack (lawyer) and warning coloration (banners). It may not prevent a predator from attacking you, but it would make them unsuccessful and, in the long run, warn other predators away from your business.
Mythic Monday – The Linnet and the Bat
- At September 14, 2009
- By Josh More
- In Mythology
- 0
Aesop’s fable 75, sometimes called The Linnet and the Bat discusses a situation where a bat and a caged linnet* are discussing why the linnet sings at night instead of during the day. The linnet’s explanation is that he was singing during the day and that’s how he was caught and caged in the first place, so now he only sings at night. The bat observes that it’s a mite late for caution, since the linnet is already captured.
The point of the fable is supposed to stress the uselessness of regret. However, it applies equally well to system and network hardening. Many businesses will look into remediation after they have been attacked, when it is far easier to do the hardening work ahead of time. Sure, no one wants to spend money they don’t need to, but as with most things in life, it is far cheaper to invest in prevention than correction.
When you build a server, it takes but a few extra initial hours to apply hardening templates and an hour-or-so a month to keep it updated with patches. However, if an attacker gets in, the server will likely have to be completely rebuilt, losing time in addition to the business loss from the outage. Additionally, it is quite likely that the attacker would have gotten into other systems on the network, so the time spent correcting the problem is multiplied by the number of systems on the network.
Really, it’s better not to get caged in the first place.
* There is a great deal of linguistic controversial about the nature of the bird in this story. The problem is that the word bôtalis, which has been translated as “linnet”, “goldfinch”, “canary”, appears only in this one fable. That none of this matters to the point of the story only serves to illustrate the fact that Classicists have nothing better to do with their lives than debate over ornithological divisions, instead of spending their time on more practical endeavors… such as researching obscure myths and linking them to I.T. security.
