Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

I’m attending the FBI Seattle Division’s Citizen’s Academy 2008. Highly recommended for anyone interested in the FBI and/or security. One recent briefing was about the Seattle FBI office’s work in retraining employees of the Puget Sound region’s banks in order to help catch bank robbers.

Now I’m sure warning bells are already going off in your head just reading that. Aren’t these people just going to get themselves shot?! That was my initial reaction as well. But these new techniques are deceptively simple, are reportedly already measurably successful, and I like the idea of fewer bank robbers running around.

As an aside, the agent who did the presentation is an enormously entertaining guy – the kind who could sell a ketchup popsicle to a lady in white gloves. And this is predominantly his hard work and research. You can see his picture in the news links below.

Any current or prospective bank robbers: pay close attention.

  • First, the Seattle area has a high rate of bank robberies, on a national level. A few reasons are cited for this, including that bank robbers in Seattle tend to be homeless and are frequently addicted to heroin. And this is a welcoming community for the homeless and for addicts.
  • Second, bank robbers tend to be serial offenders. They’ll do it 10, 20, whatever number of times until they’re caught. That’s an important consideration, because it means if you can catch the bad guy on the second offense, for example, you’ve helped a large number of potential victims downstream. You’ve had an exponential (positive) effect on your crime statistics.
  • Bank robbers tend to target female clerks, and particularly all-female banks (as in, you walk in the door, and all you see are women).
  • Next, cameras are mounted high, so robbers where hats and sunglasses.
  • The bad guys don’t typically go for a take-over; they act like a regular customer, and use a hand-written note (no weapon means less jail time) when they get to the teller counter.
  • After the job, time is a critical factor in getting police on the scene before the guy gets away. As little as 15 seconds is enough to make the difference.

So the new bank employee training scheme goes like this. First, if the teller sees anything potentially suspicious, such as a guy standing in line with a hat and sunglasses, she excuses herself from the current customer she’s helping and informs a greeter. Then she goes back to her customer.

The greeter, preferrably a man, has a desk away from the tellers. His job is basically high-intensity customer service. He goes up to the suspicious-looking person and says, “Hey, I don’t recognize you. Are you here to open an account?” “How can I help you?” Etc.

If the customer is a real customer, he gets a free pass at this point, since he just managed to jump the teller line and, in most cases, get helped by the greeter.

If the customer is a bad guy, the extra attention is most unwelcome. For one thing, he’s being drawn away from the teller counter, so the mechanics of his plan have been disrupted. And depending on his excuse for being there, the greeter is going to ask him for ID. That’s critical for the overall strategy, because it gives the bad guy an easy out: “Oh, my ID? I left it in the car. I’ll be right back.” He’s gone, disaster averted.

What if a note-passer does make it to the teller counter? For one thing, there’s a strategy about how much $$ to give. Too little, and you risk further confrontation. Too much, and you can bet he’ll be back to rob you again next time. Stack smaller bills under some big ones. And once the cash is on the counter, the teller takes a step back and puts her arms out to the side, signaling, ‘there’s your money - take it - we’re done, right?’

Once the bad guy is out the door, the teller who interacted with him is the one who calls 911 - immediately. Everyone else assumes strategic positions around the inside of the bank, looking outside, trying to identify the bad guy’s escape route and/or vehicle.

That last bit is a change from previous practice since, for one thing, banks use offsite security monitoring that’s frequently centralized and hence not located in the same town. The security company, once notified, had to first call the bank and speak to a manager to confirm what’s going on. Only then could they call the police, but not via 911 because they’re not local! And the security company has no idea what the bad guy looks like, which is pretty much the next thing that the police need to know in order to have a hope of catching the guy.

Finally, put the bank security cameras at a low angle so they can get good shots of people at the counters.

Local news links on this:

Permalink | Comments (0)

They’re offering up their articles to included in your next company newsletter. Could be a good way to bulk it up a bit.

http://usergroup.windowsitpro.com/generator/

Permalink | Comments (0)

Heh heh - looks like another error of omission in my OTP article in the latest MSDN: the sample code is compatible with the standards that form that basis of the OATH (as in, ‘open authentication’) OTP architecture.

For comparison, there’s a Java-based reference implementation (mine is C) included with this IETF draft.

Permalink | Comments (0)

Check out Safer Authentication with a One-Time Password Solution in the May 2008 issue of MSDN Magazine. That’s my fourth article for that publication and as always I’m proud to be part of it!

There’s something I should have clarified in my discussion of the two main OTP-generation alternatives, counter-based versus time-based.

Regarding time-based, a given OTP value expires within a certain time delta of when it was generated. The tradeoff is that the client and server must be carefully synchronized, although the technology to accomplish this is more reliable than it used to be.

Regarding counter-based, there’s no need for time synchronization, which simplifies things. However, there’s again a tradeoff: in a counter-based solution, it’s possible for a user to generate a sequence of OTP values in advance. The values could then be written down and given to another user, for example. As long as the values are all used in sequence, they’re all valid until used.

With time-based synchronization, the same attack isn’t possible, assuming the client token is tamper-resistant and you can’t trick it into advancing its clock.

Permalink | Comments (0)

From http://blog.gartner.com/blog/index.php?itemid=1637: “We think Windows SharePoint Services (WSS) is a natural upgrade from LAN file-shares. So much so that, by 2010, WSS will replace a majority of Windows-based, LAN file shares. (We expect explosive growth in WSS deployment and usage.)”

Wow!

Well, I think that the ‘majority’ of Windows file shares will live on at least until the hardware they’re running on fails. After that, will they be replaced by something that’s more complex to deploy and administer? Not sure about that one. The explosive growth prediction is proving true, though.

Permalink | Comments (0)

A bit of an old post, but still up to date on the product lines discussed: http://www.inputoutput.ca/2006/microsoft-sharepoint-2007-licencing/.

Permalink | Comments (0)

That’s the Northwest Entrepreneur Network’s Early Stage Investment Forum, coming up on May 9. I’ve been a few times in previous years and have never been disappointed.

http://www.nwen.org/index.php?option=3Dcom_events&Itemid=3D15&id=3D87

 

Permalink | Comments (0)

Check out Jeff Sigman’s video/blog entry featuring interviews of some of Microsoft’s NAP partners on the RSA trade show floor. Prominently featured are JW Secure customer Blue Ridge Networks and local start-up Napera.

Permalink | Comments (0)

Just got back from this “Red Team” volunteer event. Man, it was so fun! There were nine student teams from all over the northwest, and I’d guess that each team had around 10 people. Today’s red/attack team was another 10 or so people. Add in the support staff, and you can tell it was a pretty big event.

The rules are described at the link below, but in summary, each of the nine defense teams was responsible for maintaining a set of network resources including a router, switches, and a mix of Windows and Linux boxes. Most were pretty well patched by today, but the red team still found plenty of fun!

Indeed, it’s kind of scary how fun it is. I found a few good ones: default “enable” (admin account, basically) passwords on a Cisco router and a switch (two separate teams). And a default MySQL password on a third team. Other red team members found cross-site scripting vulnerabilities, a cracked SAM database or two, and a few other compromised routers
and switches.

We managed to show moderate restraint in terms of exploitation, except that we kept the compromised router and switches until the end, then reset them to the factory settings with 10 minutes left in the competition. Ok, maybe that was kind of mean …

Permalink | Comments (7)

Been doing some research on SharePoint lately, mostly focused on SharePoint Services 2.0, since that’s a dependency of Team Foundation Server.

The SharePoint “administration port” is an interesting feature, if for no other reason than what this TechNet article has to say about it. See the “About Remote Administration and Security” section about two-thirds of the way down.

My recommendation to SharePoint administrators (even if that’s your title only by default) of the world would be to read those instructions carefully, since the default installation requires authentication (good) to the remote admin site, but doesn’t require encryption (bad). Thus, you may be entering sensitive information, such as a password, that can be sniffed on the wire. Be sure to require SSL - there are instructions on that page for doing so.

As an aside, I don’t see why the default installation doesn’t require SSL (and update the shortcuts to the https URL). If there’s no suitable Server Authentication certificate available, just create a self-signed one and warn the admin. That’s better than no-encryption-by-default. Maybe SharePoint 3.0 fixed that; I haven’t checked.

Anyway, what prompted me to post about this is the following text from that article:

“Require the use of a non-standard HTTP port for accessing the Central Administration pages. This precaution makes it much more difficult for malicious users to guess the URL of HTML Administration pages or the remote administration programs. When you install Windows SharePoint Services on the Microsoft Windows platform, a random non-standard administration port is automatically used for the SharePoint Central Administration pages.”

Much more difficult, huh? Well, the use of a non-standard port is not an effective security measure. In fact, the fact that the SharePoint administration console requires its own web port actually makes remote fingerprinting easier. That is, it helps an attacker identify server roles, and versions, simply by scanning for open ports. I’ll demonstrate with the port scanning tool nmap.

Suppose that I’m initiating a network-based penetration test, I’ve identified some interesting IP addresses, and I want to learn more about what’s running on each server. One way to gather more information is to start scanning high ports:

>nmap.exe -r -p1025-65535 192.168.1.183
...
Interesting ports on 192.168.1.183:
Not shown: 64507 closed ports
PORT STATE SERVICE
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
2383/tcp open unknown
15130/tcp open unknown

Now we know there are two high ports on the target server that don’t have known protocol or product associations. A more thorough scan of both doesn’t reveal much more about 2383, but tells us that IIS is listening on 15130 and that it requires authentication:

>nmap.exe -A -p15130 192.168.1.183
...
Interesting ports on 192.168.1.183:
PORT STATE SERVICE VERSION
15130/tcp open http Microsoft IIS webserver 6.0
|_ HTML title: You are not authorized to view this page
| HTTP Auth: HTTP Service requires authentication
| Auth type: Negotiate
|_ Auth type: NTLM
...
Running: Microsoft Windows 2003
OS details: Microsoft Windows Server 2003 SP1 or SP2

Putting my attacker hat on, I’m thinking to myself, ‘why is there a web server listening on a seemingly random port and why does it require authentication? Not only that, but this machine is running SQL as well. Must be a juicy target! And hey, SQL plus a high web port … could be SharePoint!’

A quick test on the server itself confirms the research:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN>STSADM.EXE -o getadminport
...
The SharePoint administration port is ":15130:".

I’m summary, SharePoint administration might as well use a fixed port. And I’d rather that the product not open a management port at all, since securing it requires extra work that many customers won’t understand.

Permalink | Comments (0)
Newer Posts »