FYI … I took down the “keysigning” email address from my domain a couple of days ago (after I got an email from someone whom I was expecting to send me their key).

I’ve already asked the UTOSC folks to plan on me doing two (or more?) sessions for the keysigning party in 2010. For next year, I plan on doing a presentation session, where I will talk about the reasons why keysigning is so important, how the system as a whole (the web-of-trust, the keyrings, etc.) works and provide a brief introduction to the actual protocols and algorithms used. The idea is that someone can come away from that session able to do three things:

1. Make a well informed decision to participate in the web-of-trust.
2. Explain just enough to help their friends also understand it.
3. Understand it enough to trust it based on their own understanding, instead of just entirely on the word of us “experts” who have been using it for years.

The second session would be the keysigning party, itself. Perhaps there could be two of these? The main one would be in the second evening and the second keysigning party could be a family-day thing.

Anyway, we’ll all be much better prepared for next year.

This year, I’m not doing any presentation. I have some ideas for next year.

I will be running the keysigning party on Friday, October 9 at 7:15pm at the conference. I’m stepping into doing this a bit last minute, so we’re going to provide some additional info and the instructions for the keysigning party on the UTOSC website should be updated very soon.

To participate, just show up. If you want help generating a key pair and getting started, there will be several people there who can assist you, just be sure to bring your own notebook computer. If you have keys, please, email me your full key ID (not a short or medium) at keysigning@openbrainstem.net. It is a good idea to digitally sign that email. If you have multiple keys, include them all. I actually have three separate keys these days and 2 of them have multiple IDs associated with them.

(and PGP) allow us to digitally sign messages (usually email, but can be used with other communications systems, too), code and other documents. It also let’s us encrypt files, emails and just about anything else. This is an extremely important technology for a lot of reasons, some of which I’ve discussed in past articles on this blog (and others). Defending our privacy and ensuring the integrity of our personal, family and business communications is vital. We sign each other’s keys to build a “web of trust.” This is the critical step that makes the whole thing usable.

If you have never used PGP or GPG (a.k.a. GnuPG, Gnu Privacy Guard) before, visit the GnuPG website for a basic description of how to generate your key pair.

If you have never participated in a keysigning party, check out the Keysigning Party HOWTO and/or [ http://keysigning.org/ ].

Immediately following the Utah Open Source Conference 2007 keysigning party, I wrote a simple script to help help you sign-lots-o-keys. You can download the script from [ http://www.openbrainstem.net/download/sign-lots-o-keys ]. If I have time before the keyparty in just two days, I have some little updates that I would like to implement in that script. But don’t hold your breath. Perhaps there will be time at the conference on Saturday?

So, please, plan on joining us on Friday. These are always good fun.

Of course, it’s very important to have good, strong password security practices. If you have poor passwords, none of this will matter, as you’ve probably already been compromised whether you know it or not. This means that all users have to have strong passwords. Techniques for helping users to create and use strong passwords are beyond the scope of this article, but I will write about these things in the near future.

Here’s the configuration that I put into place. I’m showing this as the the iptables commands that you would run on the command line, adapt to however you persist your Netfilter configuration. Also note that these lines should replace anything that you now have in there for SSH. I’m also including the additional ESTABLISHED,RELATED rule here for completeness:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -i $OUTSIDE_INTERFACE -p tcp --sport $UNPRIV_PORTS --dport 22 -m state --state NEW -m recent --update --seconds 10 -j REJECT --reject-with icmp-host-prohibited
# iptables -A INPUT -i $OUTSIDE_INTERFACE -p tcp --sport $UNPRIV_PORTS --dport 22 -m state --state NEW -m recent --set -j ACCEPT

These three rules mean:

1. Accept traffic for “conversations” that are already in progress. This rule works for traffic in both directions and will handle everything in the ongoing connection.
2. If an IP packet matches these criterion:
   1. “-A INPUT -i $OUTSIDE_INTERFACE” — coming in on the Internet connetion (I create a variable with the value “eth0” or whatever it is and use that in my firewalling scripts);
   2. “-p tcp” — carry TCP (for Layer 4) in the IP packet payload;
   3. “--sport $UNPRIV_PORTS” — coming from an unprivileged TCP port (legitmate clients should only come from source ports 1024 through 65535, inclusive);
   5. “--dport 22 — destined for TCP port 22;
   6. “-m state --state” — the state module doesn’t have a record of this packet as being part of an existing connection;;
   7. “-m recent --update --seconds 10” — the update module has a record of another connection attempt matching this one within the past 10 seconds.

   Take these actions:

   1. “-j REJECT” — throw the packet away;
   2. “--reject-with icmp-host-prohibited” — return an ICMP host-prohibited response to the client who tried to initiate this connection.
3. The last rule is essentially the same as the second, except for:
   1. “-m recent --set” — make a note of the time that this connection attempt occurs at;
   2. “-j ACCEPT” — if all criterion match, accept the packet (which will stop further rule processing here, BTW).

Basically, what we’re trying to do here is to limit the number of failed connection attempts that are allowed.

Let’s say that human being tries to connect via ssh lamont.example.com and they don’t have an account or the mis-type their password several times to the point where sshd cuts off the connection, so they re-run their ssh command to try again. It will probably work and let them in, as it probably took them longer than 10 seconds from the first packet of the first TCP connection until the first packet of the next TCP connection.

However, the cracker-bot-nets don’t work like humans. They automate the process of trying to connect as fast as they can, so they will try only 1 or maybe as many as 3 or 4 passwords before closing the TCP connection and starting another. Since they don’t have to be as slow as people, they’ll usually be coming back again in under the 10 seconds. Most of them actually try to establish multiple connections (2-20ish at a time) in order to try more passwords.

Once the crack-bot starts seeing TCP connection failures, they usually skip your IP and go on to try and find softer targets. If they can’t connect to SSH, then why bother wasting time trying.

After setting up this configuration and letting it run for a week, I can report that it works marvelously. I’m getting under 10 break-in attempts per day, now. If you’re going to have SSH visible to the world (and why shouldn’t you?), then I would recommend adopting these Netfilter rules in your firewall configuration.

Take a look at http://www.overcomingbias.com/2007/09/926-is-petrov-d.html. This was probably one of the most important moments and one of the best decisions anyone ever made in the entirety of the 20th century.

Petrov decided to not destroy the world just because a bunch of flashing lights told him that five (that’s right only five) US missiles might be heading towards the USSR.

I’m posting the script, which is still very rough, as I didn’t both taking any time when I whipped it up last night to take care of everything that it really should be doing. Still, I’ll work on it here and there, I’m sure. You can download it from http://www.openbrainstem.net/download/sign-lots-o-keys. If you feel like makeing some fixes, either post your patches (please, create them as a unified diff file, if you wouldn’t mind) and put a link in the comments here and/or on your own blog.

Enjoy!

It seems that several TSA inspectors at several different airports were mistaking the laptop battery for a possible gun in Ben’s notebook bag as it went through X-Ray scanners.

The recent MSNBC story, “Computer security problems found at IRS,” discusses security problems found at the IRS. One of the more interesting items:

Sixty-one of the 102 people who got the test calls, including managers and a contractor, complied with a request that the employee provide his or her user name and temporarily change his or her password to one the caller suggested, according to the Treasury Inspector General for Tax Administration, an office that does oversight of Internal Revenue Service.

But even more disturbing:

Only eight of the 102 employees contacted either the inspector general’s office or IRS security offices to validate the legitimacy of the caller.

Matt Bishop’s comments on the nearly total lack of cooperation from the California Secretary of State’s office gave to the review process are utterly amazing. It’s good to see that Debra Bowen (California’s Secretary of State), has now taken the step of decertifying, dis-approving all previously approved eVoting systems.

Avi Rubin has some excellent comments on the whole eVoting situation.

The State of Florida is getting into the act, reporting on their own security reviews of commercial eVoting systems (PDF). In this letter to Diebold (PDF) which the State of Florida has published, they give Diebold an ultimatum:

Based on the report, the Bureau of Voting systems Certification has determined that certain vulnerabilities outlined must be corrected by August 17, 2007, to continue this certification. Failure to do so will result in a denial of certification.

There’s 3 pages of required fixes attached to that letter.

The U.K. Electoral Commission recently released their report detailing serious security flaws in eVoting systems.

Electronic voting is a hard problem, but that doesn’t excuse Diebold Election systems, Inc., Hart InterCivic, Sequoia Voting Systems and Elections Systems and Software, Inc. from their demonstrated complete lack of fundamental understanding of how to secure … well, anything and in particular, they’ve all shown that they have no one with even the first clue of how to either implement nor apply cryptography correctly.

Applause go to both Florida and the U.K. for recognizing bad vendor crap in the first place. An extra-hearty ‘atta-girl’ goes out to Debra Bowen in California for throwing out approvals and certifications of these seriously flawed systems.

This topic is far too important to leave in the hads of the proprietary, closed-systems mindset crowd. It must be open. The code must be open and available to everyone. All systems must be thoroughly tested by reputable, recognized, outside authorities. I hope we’ll see an open source/free software implementation of an eVoting system that could be used for governmental elections. Such a system wouldn’t be limited to only government use, either, but I believe it would find place in many corporations and other institutions.

Well, the illustrious and all wise folks at the US Department of Homeland Security have apparently decided that they should have copies of the DNSSEC key-signing keys. Given that someone told them that these were the “cryptographic keys to the Internet,” it’s very understandable that they would drool over them.

I wonder how disappointed they’ll be if they succeed in commendiering a copy of the key-signing keys and then learn what they really are; merely the keys used to sign keys used by DNS servers which are authoritative for registered domains, and nothing more.

What’s next? Is DHS going to start demanding the key to every city, too?

I can understand parents wanting to protect their children. Security isn’t always about the actual security. Sometimes, the perception of security is more important than the value of the actual security itself. In this case, parents have a greater peace of mind so they feel more secure.

But what about the children? Do you think that they might be a bit more emboldened knowing they have the armour on? In that case, such children are actually at a much greater risk then they were before. Do you think some would take it off as soon as Mom & Dad are out of sight? After all, many kids have done the same with their clothing.

P.S. If the story was about body armor in the U.S., I would have spelt armour differently.

Taking a look at the bullet points in the article, the very first one jumps out and says to me, “I’m the #1 reason that Microsoft reimplemented their TCP/IP stack from scratch.” That one reads:

Dual IP layer architecture for IPv6

After all the embarasing failures to produce a workable IPv6 stack (I first remember seeing “beta” code from Microsoft in 1999), it would seem they finally realised that the whole thing would have to be rearchitected.

Most of the bullet points in the article are fluff with a little bit of BS thrown in there two (obviously, the marketing department is still in full control of the Microsoft’s website). Lest you think I’m only here to bash Microsoft, here are some things that looks like improvements to me:

The interfaces in the current TCP/IP stack for TCP/IP security (filtering for local host traffic), the firewall hook, the filter hook, and the storage of packet filter information has been replaced with a new framework known as the Windows Filtering Platform (WFP). WFP provides filtering capability at all layers of the TCP/IP protocol stack. WFP is more secure, integrated in the stack, and much easier for independent software vendors (ISVs) to build drivers, services, and applications that must filter, analyze, or modify TCP/IP traffic. For more information about WFP, see Windows Filtering Platform.

This isn’t exactly new. Windows has had hooks into some parts of the network stack. Windows XP Service Pack 2 added some more key hooks. But one of the problems with the pre-Vista implementations is that tools which used these hooks couldn’t be guaranteed to always be able to process traffic. Although I haven’t gotten in-depth details of WFP, what I have read about it’s architecture it looks like it’s much more robust and complete.

The Next Generation TCP/IP stack can offload the processing of TCP and other types of traffic to Network Driver Interface Specification (NDIS) miniport drivers and network interface adapters. Offloading TCP and other protocol processing can improve performance for high-bandwidth networks or high-volume servers.

Although some NICs (mainly 3Com) have offloading engines that can take much or most of the load of IP and/or Ethernet packet/frame contruction and processing from the main CPU, thus freeing it for other tasks, the networking configuration of a particular Windows machine often prevented such offloading from occuring. Although I do not know any of the details as to why this happened, I have been told (by people who would have such detail) that it was due to the networking architecture of Windows. Again, I don’t have much detail on the architecture of this new feature in Vista, but what I have read leads me to believe that the new stack will make these NICs more useful as well as being easier for driver writers to implement.

The architecture of NDIS 5.1 and earlier versions limits receive protocol processing to a single processor. This limitation can inhibit scaling to large volumes of network traffic on a multi-processor computer. Receive-side Scaling resolves this issue by allowing the network load from a network adapter to be balanced across multiple processors. For more information, see Scalable Networking with RSS.

This is a much needed improvement for some systems, like Data Center Server (which already had something similar) and some beefier Windows Server boxes, but will not benefit end users much. If you were running a game that only utilized 1 of your multiple processors, theoretically, having the ability for the other processor to take over the networking processing would improve performance. Realistically, I doubt you could see the difference. Still, this is another welcome improvement in design.

The Next-Generation TCP/IP stack has an infrastructure to enable more modular components that can be dynamically inserted and removed.

Welcome to the 21^st century! Linux has done that since kernel 2.0 was released (the first version that supported kernel modules).

The Next-Generation TCP/IP stack uses a new method to store configuration settings that enables more dynamic control and does not require a computer restart after settings are changed.

Of course, Windows 2000 supposedly eliminated almost all the code paths where networking changes that would require a reboot. I remember a Microsoft event where they told me that NT 5.0, as it was still called at that point, only had 6 remaining code paths (down from 27 or so) with the whole OS where a configuration change would require a reboot. However, in practice, most people experienced a need to reboot the system to make common networking configurations changes actually effective approximately 1 out of 2 times such changes were made.

One could also read, “We changed the configuration storage methods so you won’t know where to look anymore,” into that one.

From a security perspective, I’m very concerned about their new Inspection API (emphasis added):

The Next Generation TCP/IP stack exposes an Inspection API, which provides a consistent, general-purpose interface to perform deep inspection or data modification of packet contents. The Inspection API is part of WFP. The Next Generation TCP/IP stack provides access to the packet processing path at the Network and Transport layers.

So, it’s easy to hook into the Inspection API and use that to modify network traffic. It looks like it would also be trivial to inject any traffic you wanted to. Given the definition of the word inspection, I wouldn’t expect to find a modification mechanism integrated into the same sub-system.

Having a good set of instrumentation hooks into the entire network stack is important for certain types of software development, security research, auditing and a few other things. None of these should be taking place on production machines. However, it looks like Vista does not provide a way to disable the Inspection API. This could be used by a malicious program to monitor any network traffic it wanted to, or even to implement network communications that could possibly be entirely hidden from other programs (including security tools) and users. At the very least, the Inspection API should not be installed as part of the OS. Even the ability to disable it might not be enough, especially given Microsoft’s security track record.

Overall, however, I feel that I can agree with some of the reasons it appears were behind Microsoft’s decision to reimplement the TCP/IP stack from scratch for Vista and I feel that there are several valuable improvements.

That said, I still do not consider Windows networking stack, even the new one in Vista, to be remotely secure. There are too many unknowns and there is no proper, un-biased, third-party code scrutiny. Closed software simply can not be secure. Peer review by recognized outside experts is mandatory in order to build good security. That’s why burglar alarm companies invite ex-cons and security experts to do their best to penetrate their systems. That’s why insurrance companies do the same with all automobile security systems (as well as letting them asses the relative value of each system for their purposes). Microsoft doesn’t understand that and there’s no reason, from their perspective, that they need to; they’re in business to make money. Until the liability for bad security is placed on Microsoft (and other software vendors) there is no incentive for them to fix it.

Well, the crooks have found a way to rob you of your gift card balance. If you buy Gift Cards from a display rack that has various store cards you may become a victim of theft. Crooks are now jotting down the card numbers in the store and then wait a few days and call to see how much of a balance THEY have on the card. Once they find the card is “activated,” and then they go online and start shopping. You may want to purchase your card from a customer service person, where they do not have the Gift Cards viewable to the public. Please share this with all your family and friends…

Normally, that last line would be a sure giveaway for chain-mail. However, I’ve been looking into this one, and I think it’s legit.

The email originated with a Sheriff’s Deputy. I’m witholding his name for now, because I have not gotten his permission to publish it, yet. I have phoned him, but only left a message on his voicemail, so far. I’ll update this as I get more info.

Hilarious.

But there’s a great security point here, too. They wanted to reduce the incidence of “dine-n-dash” events, where people skip out without paying. Holding your driver’s license would surely help, or so they thought. But they didn’t count on the reaction to this violation of privacy or, more importantly, the inconvenience this was to their customers.

Security Rule #1: Security is only as good as the weakest link.
Security Rule #2: You’re weakest link will (almost) always be the users.
Security Rule #3: To users, security = inconvenience.

Observation of End Users in the Wild: Users will fight inconvenience.

Good security is invisible to users, or at least, it isn’t overtly present and doesn’t require them to do anything. That’s why supermarkets and convenience stores place monitors where customers can see that the front doors (and other high-value areas) are being watched. People make the assumption that the camera feeds are also being recorded (which is not always true, but often).

At least this IHOP incident wasn’t condoned by corporate management.

Bruce Schneier, CTO of BT Counterpane, author and world-renowned security expert & privacy advocate gave an interview regarding RFID passports. It is available as a podcast.

There isn’t any new information in there, at least, nothing that I haven’t talked about before. However, it is an excellent, easy to understand explanation of the key issues surrounding RFID chips being embedded in government issued IDs. It’s not very long, but is good information for everyone from the technically challenged to government officials and even security experts.

Abstract:

By failing to implement an appropriate security architecture, European governments have effectively forced citizens to adopt new international Machine Readable Travel Documents which dramatically decrease their security and privacy and increases risk of identity theft. Simply put, the current implementation of the European passport utilises technologies and standards that are poorly conceived for its purpose. In this declaration, researchers on Identity and Identity Management (supported by a unanimous move in the September 2006 Budapest meeting of the FIDIS “Future of Identity in the Information Society” Network of Excellence[1]) summarise findings from an analysis of MRTDs and recommend corrective measures which need to be adopted by stakeholders in governments and industry to ameliorate outstanding issues.

Thanks to Bruce Schneier for posting this on his blog.

There are a couple of things that I wanted to comment on (there is a lot of excellent information here, so read on):

The most obvious threat model is theft of hard drives. The solution to this is to encrypt all data on the drives.

Encrypting your data storage is an excellent defense mechanism, however, it is not a silver bullet that will magically make you secure. Russel doesn’t suggest that it is, but in my experience, most people will begin to think that it is.

The first level of this is to simply encrypt the partitions used for data, support for this is available in Fedora Core 6 and has been in Debian for some time.

I hadn’t noticed (yet) that Fedora Core 6 had added support for encrypted partitions. I’ll have to look into that support when I install FC6 on my notebook (look for a later article on that adventure).

As many of you know from my series of articles on my work blog on setting up encrypted partition support for Fedora, I’ve been using encrypted partitions for a long time.

Also, Debian isn’t the only distribution to provide this support. SUSE has had it in their installer for at least 7 years.

The more difficult feature is encrypting the root filesystem, …

SUSE’s support for encrypting partitions even works for encrypting root at install time.

… encrypting root means that important system files such as /etc/shadow are encrypted. Also if the root filesystem is encrypted then an attacker can’t trivially subvert the system by replacing binaries.

Excellent points.

Once the data is encrypted on disk the next thing you want to do is to make the machines as secure as possible. This means keeping up to date with security patches even on internal networks. I think that a viable attack method is to install a small VIA based system in the switch cabinet (no-one looks for new equipment appearing without explanation) that sniffs an internal (and therefore trusted) network and proxies it to a public network.

This can work so well because people still employ the crustacean model of security; a hard outer shell (border firewall) with soft, gooey innards (the internal environment).

The big problem with the crustacean security model is that firewalls have holes in them. They have to or else they would be useless. Also, the firewall only protects from things traveling through that particular piece of wire. So, if someone is on the inside, the firewall does nothing to them.

This isn’t just an issue of securing applications, it also means avoiding insecure protocols such as NFS and AoE for data that is important for your secrecy or system integrity.

When talking about insecure protocols, my first targets are usually things like FTP, Telnet & the “r-tools” (rsh, rlogin, etc.). But I’m glad that Russel chose to talk about NFS & AoE:

An option for using NFS is to encrypt it with IPSEC or similar technology.

This is a good option. IPSec (see also RFC2401) is very useful for a lot of places.

Another option that carries a larger number of benefits is to set up Kerberos on your network and use NFS v4 (see RFC3530 for all the gory details). Kerberized NFS is only supported in Linux for NFS v4. When Kerberized, not only is authentication for NFS operations protected, but everything going over NFS can be encrypted.

AoE can be encrypted with cryptsetup in the same way as you encrypt hard drive partitions, it doesn’t use IP so IPSEC won’t work but it is a regular block device so anything that encrypts block devices will work. I have been wondering about how well replay attacks might work on an encrypted AoE or iSCSI device.

AoE and iSCSI are both in the same boat, here. Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance.

Russel has the solution exactly right, here: AoE and iSCSI devices are just block devices and can be utilized (including encryption) just like any block device.

Another important thing to do to secure your AoE and iSCSI systems is to isolate them onto their own dedicated networks, without interconnections to other networks. In other words, separate your storage networks from your communications networks. The main reason to do this is so that all of the available bandwidth is dedicated just to the AoE or iSCSI operations, but the security benefit is very important, too.

Security technologies such as SE Linux are good to have as well.

Probably more than 90% of the “solutions” found around the web for problems even remotely relating to SELinux, are to completely disable SELinux on your systems. It always goes something like, “In my opinion, SELinux is much more trouble than it’s worth, especially since it provides almost zero security benefit, so just turn it off. I do that first thing when I install [whatever].” This is so wrong!

The main benefits of SELinux come into play once someone breaks into a system. The observant reader may note that I said, “when,” not, “if.” With SELinux, even if they manage to get root access, they will still be limited to the bare minimum needed to allow the service they compromised to function normally and will be completely cut off from the rest of the system with no way out.

SELinux is an intimidating topic. I tell people that it looks much more complex than it really is. Once you wrap your brain around the basic concepts, it’s really quite easy to manage. Even if you don’t bother to learn how to write policy, troubleshooting and fixing 99.9% of the problems that actually occur with SELinux is very easy.

So, don’t turn it off. If you don’t know how to troubleshoot it, ask. Your local LUG mailling list should have plenty of people on it who can help you.

Prevent access to some hardware that you don’t need.

Great advice. Russel goes into some detail on this point in the article. I would recommend that you read it.

One thing that a commentor to Russel’s post mentions is the pam_usb.so PAM module. I’ve known about this module for some time and have even toyed with it a bit.

I’m not currently using pam_usb.so, but I want to be. It’s quite simple to use. I simply haven’t found the time to sit down and get it working with the various distributions that I have installed on my notebook. Sigh. Hopefully, I’ll get it done, soon. Maybe after I install FC6 on here.

Security monitoring systems are a good idea, unfortunately they can be extremely expensive.

Yes, they are and excellent idea and can be quite expensive. But, if you do a little shopping around and are a bit creative, you can put together a good monitoring solution on even a meager budget. I can recommend taking a look at Norther Video Systems for a great range of gear.

Don’t forget, though, monitoring systems do not only have to be comprised of audio/video systems. There are many other useful sensors available, too.

There has already been at least one recorded case of a webcam being used to catch a burglar. I believe that this has a lot of potential.

I agree, webcams have great potential to supplement physical security monitoring. In addition, they can be quite inexpensive while still providing acceptable quality. For example, I was at CompUSA just the other day and walked past the “webcam” aisle. There were several small, compact notebook models ranging from US$25 – US$99 each. Just remember, the hard part will be wire lengths with USB cables. powered hubs can help with that, though.

In conclusion:

• Use the tools available (encryption, firewalls, PAM, IDS, etc.)
• Never forget about physical security
• It’s all about risk management
• Even on a budget, there are simple things that can help out a lot

So, give it some thought. If you’re not sure what to do or how to do, find a good, security-conscious person to help you out, hire a real security expert (I can recommend BT Counterpane).

Since the electronic voting equipment manufacturers are completely incompetent when it comes to security, I and any other person with a working brain (when it comes to security, that is) have been expecting that we would be hearing an awful lot about machines “malfunctioning” in this year’s election.

If you haven’t caught any of the stories yet, check out Pete Ashdown’s recent post on some voting experiences that have been sent in to him, as well as this story on KFDM’s website.

There are other stories surfacing already.

Pay very close attention to your voting. Make sure the machine shows what you really wanted to vote for before you commit your vote. Double-check the printout from the voting machine and make sure that every one of the items marked is what you really wanted to vote for.

It’s your responsibility to ensure that your vote was recorded as you want it. The electronic voting systems adopted in the state of Utah are so insecure that it doesn’t matter how good the elections officials and workers are at their jobs; votes are going to be stolen this year and with greater ease than in any past year.

It’s up to you, the voter, to protect yourself and your vote.

There is nothing groundbreaking in this article, but it is a good collection and summary of these important and truly basic, programming principles. Some are easier to implement in an existing development pipeline and a couple could require some very large changes. Still, it’s worth considering.

Rather than talking further about this, I’ll let you read the article. It’s very good. But I would like to point out that there are a lot of parallels in network & systems security that could be drawn here.

It’s about time! Too bad they are trying to tiptoe their way back to sanity. Like we’re not going to notice? But, that’s OK. as long as they continue to move in the right direction. Keep it up.

P.S. Nice timing; I’m in Massachusetts this week, without my toothpaste. Don’t worry, I bought some here, but it would have been nice to travel with mine.

I had read about TrackMeNot a little more than a week before on Bruce Schneier’s blog, and so I already knew TrackMeNot was a flawed idea. Peter also makes some very good points in his post, but, unfortunately, it falls short of pointing out some of the more serious problems with TrackMeNot.

I’ll just summarize the problems here. For further explanation, read Bruce’s post:

1. It does not hide your searches (they are still identifiable with you).
2. It’s far too easy to spot (and therefore, far too easy for AOL and others to defeat) and it’s schedule is regular & fixed.
3. Some of the generated searches are worse than what you would try to hide.
4. It wastes lots of bandwidth, while returning absolutely no privacy or security benefit.

I like this quote from Bruce’s post:

Yes, data mining is a signal-to-noise problem. But artificial noise like this isn’t going to help much.

You really should read the whole article,even though I summarize it here.

The folks at FairUse4WM cracked Microsoft’s PlaysForSure DRM software in Microsoft Windows Media Player.

If you really want to see Microsoft scramble to patch a hole in its software, don’t look to vulnerabilities that impact countless Internet Explorer users or give intruders control of thousands of Windows machines. Just crack Redmond’s DRM.

It only took a couple of days for the FairUse4WM people to compensate. I’m sure it won’t be long before Microsoft tries to patch this again.

But the real moral of the story is that companies like Microsoft don’t actually care about security except when it embarrass them or directly threatens their strategic agreements (like with record labels).

I also disable all SSL3/TLS encryption suites that provide less than 128 bits of key and all 3DES (a.k.a. triple-DES, DES EDE mode or TDES) sets. This is not just because 3DES is insecure, but also because 3DES is so slow. It consumes significantly more processing time and doesn’t really provide much better security than standard CBC mode DES. It’s just not worth the overhead. In addition, there are several vulnerabilities in both 3-key & 2-key 3DES that significantly reduce the complexity to brute-force them. 3DES is not considered a safe protocol.

In their paper titled, “Key-Schedule Cryptanalysis of IDEA, G-DES, GOST, SAFER, and Triple-DES“, John Kelsey, Bruce Schneier and David Wagner describe one weakness found in 3-key 3DES that isn’t present in 2-key 3DES (among other interesting things).

From what I’ve read in the past about browser 3DES support, although nearly all browsers say they use 168 bit 3DES keys (3-key 3DES), many actually use(d) 2-key 3DES (112 bit). I’m not sure how true or false this is in modern browsers, I’ll have to do further research to find out.

A paper license tag, a salad and stories that didn’t make sense pricked the suspicions of a state trooper who stopped the car of a wanted fugitive polygamist in Las Vegas.

But it was the pumping carotid artery in the neck of Warren Steed Jeffs that convinced Nevada Highway Patrolman Eddie Dutchover that he had cornered someone big.

This is an excellent example of security “Done Right”. Dutchover correctly applied behavioral profiling. It takes a smart person with the right training to be able to correctly do behavioral profiling without it degrading into racial profiling or some other mostly ineffectual form of profiling.

Eddie Dutchover, I take my hat off to you and your expert application of such effective techniques. Bravo!

Also, in the same CNN story, you can read about how Utah is getting first crack at prosecuting Jeffs.

There are also a couple of interesting video clips linked within the article. They are linked via a JavaScript thingy, so I’ll refer you to the CNN article to view them (I could work out URLs to give you some direct links here, but I’m not going to take the time to do that, tonight).

First, they put spam up that includes links to their phishing sites on blogs they troll the net for. This part is very easy, thanks to services like Technorati and Blogger.

Next, “young” bloggers (i.e., those who are still fairly new to the “sport” of blogging), see comments. Either they naively authorize the spam comment, don’t moderate at all or decide to follow the links and check it out before authorizing the comment. If the comment gets posted to the blog, then others who read the blog can fall into the trap. If the blogger decides to visit the pages, they could get sucked in to all kinds of things.

But as I looked at a few of the links, they turned out to cause redirects to either www.abusepost.com or www.spamcop.net (I didn’t make those into links on purpose; DISCLAIMER: GO TO THOSE SITES AT YOUR OWN RISK, I’M NOT RESPONSIBLE FOR YOUR CHOICES). Of course, the vast majority of bloggers, both experienced and just getting started might think that those sites are providing a pretty good service. Looking a little more closely at the form and at the HTML itself reveals that these sites look suspicious. They require your name, email address and website address (which will be the blog that they hooked you at in the first place, for most people).

Were you paying close attention? They require you to provide the exact information spammers want in order to “report” a site that they are already “about to shut down”? Doesn’t make much sense to me.

Do you smell phish or am I the only one?

A word to the wise: Just Say No.

Here are some simple rules for Internet safety, though, they apply (with proper contextual edits) to any online communication:

1. Moderate — Whether it’s comments on your blog(s), forums (which I hate, BTW) or mailing lists. Moderation is currently the most consistently effective way to defeat all forms of SPAM.
2. Never give out your information if you don’t have to — Just because a particular website’s “form” says that it requires your information, doesn’t mean they should be given any. We all know not to publish our credit card numbers online, but it’s amazing how many people don’t understand that your name, email address, street address, phone numbers, websites, employer’s name, favorite color, mother’s maiden name, etc. are not needed by most websites. When in doubt, don’t give it out.
3. The only stupid questions are the ones you do not ask — In other words, ask someone you know who has lots of experience with the Internet, email, spam, security, etc., any questions about specific websites or other items in general. Keeping yourself safe is hard enough to do, but keep trying to do it without the right information and you just might make things much worse.
4. Don’t open HTML emails — If someone sends me an HTML email (and I think it’s worth this effort), I send it back to them with a simple, polite note explaining that for security reasons, I do not accept nor read emails that are not in plain text. Too many people are using stupid email programs like Microsoft Outlook and Outlook Express that have hundreds of severe security flaws when it comes to processing HTML email, alone.
5. Don’t Panic — It can be easy to let fear take over at this point and abandon your dreams of blogging and the “Internet lifestyle”. Don’t worry, it’s not that hard to keep yourself safe. Once you know how to recognize the dangers, it’s easy to avoid them.
6. Think — (OK, this one could sound kinda mean, but it’s not; it’s just a sad truth, so don’t take it too personally) The spammers and the Phishers keep doing what they do because it works. There are just too many people on the Internet who do not think for themselves. You have a brain and I’m sure it functions at least well enough to read this far. I’m sure you have a lot more capacity to figure things out than you might be giving yourself credit for. Being able to think is not enough on it’s own, but with a little bit of knowledge, your brain can be used to help keep yourself, and your loved ones, safe on the Internet.
7. If in doubt, bail out — You don’t have to go any further than you already have when visiting any website or continuing a discussion on IM in a chat room or on a mailing list. You can pull the rip-cord at any time.

I’m sure there are other things that we could put in that list. Perhaps some commenters will try to help me out in that regard. But I think these basics should be enough to get you started.

This is one of my favorite Turkish proverbs:

No matter how far you have gone down the wrong road, turn back.

Although I’m not a lawyer in Canada or anywhere else, but it sure feels like this guys rights were ignored. It is especially disturbing to me that his notebook was riffled after he was already cleared; after the authorities decided that it was a complete false alarm.

I also think that it’s both good and bad that these kinds of overreactions are being ignored by the mainstream media. It’s good because they’re not fearmongering as much as they did. It’s bad because they are not showing how the recent fearmongering is still affecting us and they are missing out on the civil rights/anti-privacy story. Then again, it would seem that the mainstream media doesn’t understand privacy. Perhaps it’s not in the “journalist’s Glossary”?

Thanks again go to Bruce Schneier for bringing this example to our attention.

The point of terrorism is to cause terror, sometimes to further a political goal and sometimes out of sheer hatred. The people terrorists kill are not the targets; they are collateral damage. And blowing up planes, trains, markets or buses is not the goal; those are just tactics. The real targets of terrorism are the rest of us: the billions of us who are not killed but are terrorized because of the killing. The real point of terrorism is not the act itself, but our reaction to the act.

And we’re doing exactly what the terrorists want.

Did you catch all that? If you’re not sure, then go back and read it again before continuing on here.

Terrorists do not attack their real targets. Terrorist attacks are designed to cause as much fear and disruption as possible amongst those who were not directly targeted by the tactic used.

Our politicians help the terrorists every time they use fear as a campaign tactic. The press helps every time it writes scare stories about the plot and the threat. And if we’re terrified, and we share that fear, we help. All of these actions intensify and repeat the terrorists’ actions, and increase the effects of their terror.

(I am not saying that the politicians and press are terrorists, or that they share any of the blame for terrorist attacks. I’m not that stupid. But the subject of terrorism is more complex than it appears, and understanding its various causes and effects are vital for understanding how to best deal with it.)

I completely agree. It is an unfortunate reality of our societies that many feel they must use whatever opportunity they can squeeze out of disastrous and painful events for their own personal gain. In one small way, I can understand how this happens; as events beyond their control unfold around them, some people seek to exert a measure of good into the outcome so they will feel better about having been through it. I’ll call this the “Silver Lining Syndrome” of disaster reaction.

Another thought experiment: Imagine for a moment that the British government arrested the 23 suspects without fanfare. Imagine that the TSA and its European counterparts didn’t engage in pointless airline-security measures like banning liquids. And imagine that the press didn’t write about it endlessly, and that the politicians didn’t use the event to remind us all how scared we should be. If we’d reacted that way, then the terrorists would have truly failed.

Look, it’s this simple: Yes, we deserve to know what is going on in the world, however, we need to be responsible with that information. We need to temper our reactions with uncommon sense.

It’s time we calm down and fight terror with antiterror. This does not mean that we simply roll over and accept terrorism. There are things our government can and should do to fight terrorism, most of them involving intelligence and investigation — and not focusing on specific plots.

Intelligence and investigation provide real security. What’s going on with TSA and friends at America’s airports today is little more than security theater. The sooner we stop wasting resources on that, the sooner we can spend some of those billions in places that will really work.

Remember how much criticism the Bush Administration received (mostly from the mainstream press, by the way) shortly following 9/11 when the stories broke about how much money was being poured into beefing up the CIA, NSA and other U.S. intelligence community members?

Bad security often looks good, good security works and great security does it without you realizing it’s there even though you can see it.

Here are a few more snippets from Bruce’s article, though I highly recommend you read the whole thing, yourself:

… our job is to remain steadfast in the face of terror, to refuse to be terrorized.

The surest defense against terrorism is to refuse to be terrorized.

… our job is to fight those politicians who use fear as an excuse to take away our liberties and promote security theater that wastes money [without making] us any safer.

What we all really need to do is take DNA’s advice from The Hitchhiker’s Guide to the Galaxy:

Don’t Panic.

I am not the least bit surprised; I (and many others) predicted that this overload would result from the rule changes “prohibiting an entire state of matter” (liquids) and prohibitting gels in carry-on luggage. For me, I have to now check my suitcase instead of just carrying it on because of toothpaste and the particular deodorant I was traveling with when these new rules were put into effect (I’ve since switched back to my usual traveling solid).

I don’t want to leave my toothpaste at home, but if these new and useless rules stick for long, I may just ditch it, instead making sure that all of my hotels can provide me with some. That way, I would again be able to take my suitcase carry-on and skip the check-in and baggage carousel entirely. However, when I travel, I prefer to have everything I need with me.

Because of the methods these individuals planned to use for smuggling explosives aboard, security restrictions on what passengers may carry-on commercial airlines in England are very stringent. Basically, you get to keep your wallet, keys, some money and the clothes you are wearing. No cell phones, computers, DVD players, audio devices or any other electrical apparatus are allowed.

I happened to be in Los Angeles at the time this happened. As the week wore on, I read and heard that some U.S. airports had adopted the same extra security restrictions now found at London Heathrow & Gatwick. On Thursday & Friday, I was told by several people that they had heard that LAX (Los Angeles International Airport) was not permitting any carry-on luggage at all. This worried me only because I have no desire to find out just how well this notebook would survive the tender, caring baggage handlers’ grasp. In other words, I never check my computer bag or the computer.

However, there was nothing to fear. When I arrived at the airport, it turned out to take longer to walk from the ticket counter to the security checkpoint leading to my gate than it took to get my boarding pass, check my 1 bag (suitcase with a week’s worth of clothes) and get through security, combined. I’m sure the fact that I have nearly three hundred thousand miles of flights with Delta didn’t hurt either. As it turned out, if I had been willing to throw away my deodorant and the little traveling tube of toothpaste I was carrying in my suitcase, I wouldn’t have had to check that bag, either.

For me, the “extra” security measures only amounted to my having to wait for my bag when I got to Salt Lake.

As I was at the airport at 3:45pm for a 6:08pm flight, I ended up standing around at my gate for just over 2 hours before boarding. I try to not spend too much time sitting in airports, since I’m going to be spending so much time sitting on the planes.

But that wasn’t the worst part.

The worst part was that there was a 4:50pm flight and they “couldn’t” put me on it. Was I there in plenty of time to switch to the earlier flight? Yes. Were there seats available? Yes. But only in First Class, there were no Coach seats left, so she couldn’t switch me to that flight. Given as much as I travel, I almost always get upgraded for free to First Class. In fact, I was upgraded for the flight there this trip. The agent was kind, she said they really should have a way to let me take one of those seats, which I would have gotten anyway (she could already tell by looking at her screen that no one else was going to get upgraded).

How ironic is that? Oh, well; I made it home that night and to me, that’s the most important part of these travels.

The system “which could only be controlled from the ground would conduct the aircraft posing a problem to the nearest airport whether it liked it or not … [a] hijacker would have no chance of reaching his goal.”

I know I’m not the only who sees the potential for this new system to be abused. I think one of the most telling phrases in the announcement is:

The system would be designed in such a way that even a computer hacker on board could not get round it.

Sorry to burst your bubble, fellas, but there is no such thing as hack-proof. It’s a basic fact well known by anyone with any real security knowhow.

Besides, why would anyone want to hack such a system from on-board when they could hack the ground station? Why not hijack an airplane with as few risks as possible? Like the risk of your people being caught on their way through airport security (which is mostly a joke at this point, anyway); or with almost no risk of anyone on the aircraft being able to retake control; how about the risk of failure during the initial takeover. Gee, thanks 30-European-businessmen for making it so easy to hijack an airliner that there’s virtually zero risk in doing it.

Overall, I think it unlikely that the good part of this idea could be implemented without opening up other, far worse vulnerabilities.

I first read about this on Bruce Schneier’s blog.

In a recent post by Scott Paul Robertson on his blog titled, Django with HTTP Authentication, he builds a workaround for Django’s lack of a proper hook to use the authentication system that he needs/wants to use (BTW, LDAP is a good choice and a secure one). I feel for you man, as I’ve “been there, done that and didn’t even get a lousy T-shirt!”

Since Django can not deal with LDAP on it’s own, he decided to use HTTP Authentication and tie Apache (or so it appears) to the LDAP store. Of course, his app still needs to know, at the application level, that a valid authentication is present, which user it is and perhaps some other information.

Unfortunately, this approach could lead to some little security problems.

Again, I don’t know if Scott has already worked around these or not, but I felt it would be good to publicly discuss the possibilities. For all I know, he already has this licked:

1. There is no way for the server to revoke nor enforce revocation of authentication once credentials have been accepted.
2. By having code rely on HTTP Authentication without the application being able to verify or validate the authentication, an app can be vulnerable to replay and spoofing attacks.

The solution Scott came up with is a common one, and as the potential security implications are non-obvious (that is, until they are, of course :) ), they often go unnoticed.

OK, now for some explanation. These are the things that occurred to me while thinking about Scott’s situation:

1. If Apache is not looking at LDAP, or there are subdirectories (or siblings) that are not also set up with all the necessary bits to have Apache look at LDAP, then you could be vulnerable. However, if you are doing all that extra work, you’ll be fine.

   There is nothing in the HTTP protocol that can be used to revoke HTTP Authentication once access is granted, but, this makes sense given the way that the HTTP protocol itself works. The only way to clear the authentication is to close the browser. Depending on which browser(s) visitors are using, they may have to close just the tab or window in question, or they may have to close out all instances of the program (though this is much more rare today than it used to be).

   Because of this, control over continuing validity of access is now in the hands of the user, not the system. This alone is one of those general great-big-no-no items in security. The user should be able to decide, “I’m done, log me out,” but the system should also be able to say, “Thank you, come again!” In addition, this situation can lead to all sorts of weird and unexpected problems in your application(s). Belive me, it sucks. I know because I’ve dealt with some of them before.

   At this point, one might start to think, “OK. So I can’t revoke access using HTTP. Why not set a flag in the DB when I authenticate and remove that when a user clicks on the ‘logout’ button?” First problem, there is no DB as far as Apache is concerned. Remember, it’s using LDAP, and the mod_authz_ldap module can only do the LDAP authentication. One could start creating a web of code here to compensate, but I think there are much easier ways. Second, what happens if the user doesn’t click “logout”? There’s a really good reason right there to build the authentication into the application rather than use HTTP Authentication.

2. There are two kinds of attacks this architecture could leave an application vulnerable to. However, if the webserver is successfully protecting every single subdirectory involved (i.e. issue 1 isn’t an issue), then these attacks should be quite a bit more difficult to mount:

   1. Replay attack: A replay attack is when one simply records the packets going by and then “replays” them back to the server, changing the source IP address (and probably the port, too). The attacker doesn’t have to know the magic incantation (password, etc.), they just get in.

      In the context that I’m talking about in this post, it might be possible to replay the HTTP headers that followed successful authentication, or the headers from the authentication step itself.

   2. Spoofing attack: A spoof is when one constructs packets that pretend to be what an application expects. In the case of web based applications, it is very common to see developers use the “Referrer” security model (which isn’t secure in the least). That’s where their pages assume, “you must have authenticated successfully, since you were referred here by the login page.”

      In this case, the entire authentication step could possibly be bypassed. This will depend on some other factors and even if it can’t be bypassed directly, then someone could use a replay attack or simply reuse someone else’s session by snarfing a browser that had a window (or tab) open to the app. Since the app can not verify that authentication actually took place (since it can’t get involved with LDAP or other verification), it can only assume that it must have been successful if you are getting “here” from “there” because it sees the browser presenting information that it should only have if it is coming from “there”. The problem is, that information is unreliable and easy to forge.

Here are some other ideas to help deal with it.

When it comes to web applications and the need for authenticated access, the only way to make sure that authentication is enforced is to wrap every protected page generation operation within a “blanket” of verifying the authentication. Here is a simple pseudo-code example:

if (logging_in) // In other words, we're processing the login page.
{
   result = login_function ();
   if (result)
   {
      already_logged_in = TRUE;
   }
   else
   {
      Redirect back to the login page, perhaps showing an error.
   }
}

if (already_logged_in)
{
   if (verify_authentication ())
   {
      Deal with generating/providing the requested page.
   }
   else
   {
      Go to the login page.
   }
}

As you can see from this sample, the same authentication system can re-verify that the user is still authenticated and that the connection is valid for each and every page generation. There is no other pathway to the meat. This kind of architecture is necessary with a stateless protocol like HTTP. Anything less and there will be other ways in.

I see six possible solutions for Scott’s specific problem of Django not supporting LDAP:

1. Wait for Django to get LDAP support
2. Write your own, separate authentication into your application (using the DB)
3. Use a Python LDAP “library” and hook your authentication into your app
4. Write the LDAP support for Django
5. Write PAM support for Django (or just your app)
6. Run

Number 6 means to abandon Django and use a framework which has already taken security seriously, or build one yourself.

I don’t know much about Django. Perhaps it’s just too new and is still missing a lot of key pieces. Perhaps the developers don’t think LDAP is a good way to work with authentication (they would be completely wrong). Whichever it is, it sounds to me like Django isn’t quite ready for prime time. Personally, I am very uncomfortable with it from both a security standpoint and as a framework, since it seems incomplete. I just know that if I were going to write a web app in Python (which I don’t), I would be looking elsewhere at this point. Who knows how many other problems you will run into with something like this.

However, if I were a big Python guy (again, I’m not) and I had some time I could dedicate to helping a project like Django out, I would look a little deeper to see if I thought this thing had real promise for the future. If so, then I would go with option 4 and contribute that back to the community.

Scott, whichever way you decide to take this response, good luck with your application and thanks for sharing your situation with us. For everyone else, I hope these rambling thoughts help.

Oh, yeah, the House of Representatives is just the place to find a plethora of individuals who you would want designing security systems. Not!

Let me boil it down for everyone:

If you have two pathways to enter a secure area (in this case, the airports), one high security path (what passengers go through today) and one low security path (what SecureFlight and other registered traveler programs would do), which do you think terrorists are going to attack? If you said the low security path, you’re right.

It’s that simple. These programs will, if allowed to launch, completely undermine the rest of the security operations at airports.

I love WordPress; it’s just so easy to deal with the SPAM. Still, it will be nice when open-source people finally create software that fully neuters all SPAM.

Privacy is a very important matter. Privacy is a central, core component to liberty and true freedom. If we (US Citizens) don’t pay attention to it, there are forces who would like to take it away. Most of the time, we call those forces terrorists, but there are other more subtle forces also at work in the world.

My good friend, Pete Ashdown has an exellent position on the issue of privacy, and I support him on these efforts.

I’m not the political activist type person. I’m not going to use my blog that way, either. But I do consider it very important to let your voice be heard in matters that affect basic liberties. I vote.

Privacy is the most priceless freedom of all. It underlies every human right. Without true privacy, there is no liberty.

That’s my view. I’m Lamont Peterson and I’m not running for any political office. But if I win as a write in, I’ll throw a good party. :)