Xblog

So starting with the outer bits of the code first, it is pretty clear that the bulk of the message is escaped Javascript which is fed in to eval. Not exactly a good sign, but not necessarily a bad thing. The first step I took was to unescape the relevant data (without performing the eval of course), which yielded this.

The source was clearly obfuscated, so I went through it, cleaned up the formatting and attempted to assign more meaningful names to variables and functions. This yielded this. The transform1 function included a use of eval(someString.replace(/blah/, ”)), which was clearly just a way of obfuscating how myCallee was computed, so I performed the replace and substituted the result, yielding this much clearer source, which shows that myCallee is actually the function itself!

So, it now becomes clear that the obfuscation of transform1 was not entirely random in nature, as the source itself was used as part of the key to decode the “payload” (the string passed in to transform1 after its definition). The easiest way to accurately decode this was to create both the original fpTu function in all its obfuscated glory, then set myCallee to fpTu in transform1, and then see what we got back from transform1 when we passed it the payload.

Not surprisingly, we have another somewhat obfuscated chunk of Javascript. After reformatting it (thank you Steve Yegge for js2-mode and providing some more meaningful function and variable names, the payload now looks like this.

There are still a bunch of places where the replace(/blah/, ”) idiom is being used to obfuscate things, and another place where a variant is used where all alphanumeric values are being replaced with a period, and then all instances of multiple periods are replaced with a single one. After unraveling those, the intent of the code becomes clear and we can attach more meaningful names to the functions and variables. Thus I ended up with this.

We can now see that the code points to 3traff.cn (don’t you feel safer already? ;-), and it cleverly embeds an iframe pointing to 3traff.cn in to each document as it is loaded. I’m not up on my browser exploits, but it looks like the intent of all this is to at the very least track users as they go off site, and also might be hoping to confuse a browser about which domain a document came from, and therefore potentially cause cookies to leak to 3traff. Either way, this isn’t the kind of code I like running in my browser.

The net effect of all this was to completely tie up my mail server and for the most part prevent any mail delivery. I’ve now tweaked the server a bit so I do eventually get mail, but it is still rather grim. So far, I’m killing connections to clients after two errors, I’ve trimmed my accept queue depth, and dramatically increased the number of simultaneous connections I will process. The overall effect has been pretty taxing on my mail server, and I still see significant delays in delivery times, so I’m all ears to any brilliant suggestions on how to address this problem.

If you are a mail admin and are wondering why your queues are backed up with tons of jslopez@xman.org e-mail, please, please kill it. I suspect thought that most of my mail is coming from bots, so I’ll probably need to start adding immediate filtering at connect time that drops suspected bots.

Is this happening to anyone else?

So the problem that a number of commenters have pointed out is that these TSO’s are making up arbitrary rules, potentially violating the law and even constitutional rights of passengers, and the TSA lacks an effective mechanism for dealing with it. It’s great that they are capable of recognizing an error when it was reported, and in this case I don’t think any laws were broken (other than laws of rational thought perhaps ;-), but as far as I can tell, they could have been.

Here’s the thing: I expect local TSA offices to come up with their own procedures and policies. You need to give offices enough autonomy that they can adapt to local situations and/or come up with innovations. Security needs to flexible and adaptable. So a changing landscape at each office is par for the course and a sign the TSA is actually doing their job. The problem is, there are rules and laws that simply cannot be violated, no matter the rationale of the local office.

Simple straw man: on the off chance that passengers might carry an explosive in their stomach, it is not okay for TSO’s to punch each passenger in the gut as they walk through the security line (hmm… I’m sure there is a the makings of a good comedy sketch in there somewhere). Let’s just say for a moment, this were to actually happen. I’m going through the line and I notice TSO’s punching everyone in front of me. When it’s my turn, I protest, saying they can’t hit me, and if they do, I’ll charge them with assault. They then counter that they are required by law to punch each passenger in the gut before allowing them to board. I say, “I’ve never heard of something so ridiculous in my entire life. Show me the law that allows you to do this.” Guess what the answer is? Sorry, we can’t show you the law. In fact, not only can we not show you the law, but if you continue to protest this, we’ll arrest you. Either let us punch you or leave the airport. Even if I call the ACLU and start to file legal complaints, the case won’t be allowed to go forward. The only hope of getting this mess resolved is to contact the TSA, hope that someone with the right authority listens to me and agrees with me, and then acts. As seen in the “electronics” case, while the TSA can respond quickly, we’re still talking about weeks here, and that’s if I catch a sympathetic ear. With all the people that go through airports each day, we’re talking about potentially thousands of violations of people’s rights.

TSO’s wield a rather significant amount of authority. They have the power to keep you from making your flight. They have the power to arrest you, and can justify it simply on the grounds that you are creating a disturbance! This is very intimidating for most passengers, making it hard for them to defend themselves. A published set of laws would provide a mild counter balance to this, and make it easier for passengers to anticipate and accept new, innovative security procedures. Yes, there is a security advantage in hiding the rules of the game from your adversary, as it makes it harder for them to assemble a plan with a high degree of confidence it will work, but we’re talking about a “secret” shared by the thousands of employees of the TSA, which in my book is a secret only to citizens who don’t have the resources or the inclination to compromise a secret shared by thousands… and the courts (convenient that). To a well organized attacker, obtaining a secret known to so many people is trivial. The other thing is that I’m not expecting to have the actual procedures published (although the TSA frequently does this with new polities), just the laws governing what they can and cannot do. That way, if a TSO gets out of line, you have recourse.

Here’s the problem with harping on the security button when advocating Linux. First of all, consumers, for the most part, don’t care. You know why most software is provided “as is” with no warrantee? Because consumers would prefer that to a product released years later, with fewer features, and much greater cost. Let’s just say for a moment you win that battle, and in a post 9/11 world, you manage to convince them that security should be their first priority. Well then, the designers of competing software, particularly Windows, would simply shift resource allocations and product priorities accordingly, and within a surprisingly short period of time the Linux world would find itself falling behind the massive software juggernauts of the world, for they are, if nothing else, responsive to changes in customer expectations. In fact, we’ve already seen a glimpse of this with Windows XP SP2, which Microsoft pushed very aggressively despite not making a dime of revenue off of it. Let’s just say for a moment though that these big software juggernauts are too slow to notice the shift and have too much old crufty code to fix up to get the job done anytime soon. Here’s where the real can of worms starts to open up: what happens if people actually buy your argument and start shifting over to Linux en masse? Linux becomes preferred target #1 for hackers, and suddenly Linux starts falling victim to all kinds of nasty exploits (and consumers will be a lot more angry about this than they are about security problems with Windows, because you’ve made them more concerned about the issue and made the mistake of promising a product-based solution). I’ve heard people wave off this argument, but I think they fail to look at the raw data. There have been, over the years, a lot of remote exploits found in various distributions of Linux. Maybe not as many as have been found with Windows, but we’re within an order of magnitude here. Despite this, Windows has had easily a hundred times more instances of malware and security compromises reported. That should tell you something.

Now, don’t get me wrong, I feel more confident about the security of my Linux systems than I ever feel about any Windows systems I have set up. There are some good reasons for this. For starters, I know how Linux works a lot better than Windows. I know just enough about Windows to be really dangerous, but Linux I really understand. So, I can spot oddities a lot more easily, and I know a lot more about what needs to be done to secure, monitor, and respond to security threats on Linux. Admittedly, knowing and doing are two different things, but I have that problem with Windows too. :-) I’m also more confident about Linux because of the “process”. I know Microsoft has sophisticated processes for auditing code and finding bugs but I don’t know much about them so I can’t tell how much I can trust them. Linux’s open source processes are transparent and really do help minimize and mitigate security flaws. Finally, the Linux community tends to have a more sophisticated user base, which means they are more likely to have a proper security process in place, which makes Linux a less desirable target in the first place.

The biggest delusion I’ve seen in this regard comes form people who deny that there are any “real” security holes in Linux, because they’ve never had a compromised system. So first off, there are plenty of well documented cases where worms or other malware has been able to exploit security flaws in Linux. Secondly: how do you know you have never been compromised? Few people use tools like tripwire, rkhunter, chkrootkit, Nessus, etc. correctly, and even if you do, some rootkits are VERY good at hiding. The most insane counter to this point has been, “well, if I can’t observe it, is it really not a problem”. The “If a tree falls in the forest…” metaphor breaks down when your machine is used to stage a giant DDoS blackmail, a phishing scam, or a big spam dump. You may not observe it, but you can bet that somebody will someday, and you may find yourself at the wrong end of a criminal investigation, a lawsuit, etc. More importantly, exploited machines, loosely coordinated through a “botnet”, are probably the biggest security threat on the Internet right now. Just like a poorly maintained house in a neighbourhood, compromised machines drag down everyone in the neighbourhood (and unfortunately, on the Internet, the neighbourhood is quite large). Don’t be lazy: keep your systems patched.

This is why I am so irritated by “software freezes”. I’ve worked on more than a few projects where the attitude is “I know a new version of software X is out, but we’ve deployed with this old version and it is working for us so far… I don’t think it is worth the risk to upgrade to the new version. It might break things.” Sure, it probably will break things. To quote the agile software folks: embrace change. Repeatedly updating your software will teach you were you are making too many assumptions, where the underlying API’s are least mature, where your protocols lack backward compatibility, where you need to clean up your build and deployment process, etc. Sadly, by not embracing these changes, your software starts to ossify, and it becomes nearly impossible to contemplate platform upgrades. That becomes a huge issue when a new security flaw is discovered and you need to roll out a patch. Just expect to have to do an update every couple of weeks as new security flaws are discovered, take the hit with all the breaks that come from that, and the world will be a better place for all of us. I say this having worked at companies that are still running slightly patched variants of the software platforms they first launched with…. years ago. Updating is a huge mess for them, and I suspect whenever a new security flaw is discovered in their platform, all hell breaks out in the IT department.

Sadly, I think we’ve got enough of a botnet problem right now that the Internet could start to be a real ugly place. It’s time everyone recognized the mess and cleaned up their part of the neighbourhood.

First off, I don’t, in fact, take issue with his central thesis: data mining through the general population as a means of generating a list of suspects to be investigated by FBI agents doesn’t seem like a good way to hunt down terrorists. My problem is that it is a straw man argument that likely misrepresents the manner in which authorities are attempting to use data mining.

I know a thing or two about the applications of data mining. While not an expert in the field, I’ve worked in search engine companies for the last five years, three of which I spent in research, where I had a chance to talk to researchers about successes and failures of the field. So I have some sense of how one can usefully (and not so usefully) use data mining techniques. As Bruce states, it is a terribly useful tool in all kinds of situations, but it is far from a magic bullet. You need to know how to use it. His essay seems to assume the government is astonishingly ignorant in this regard, despite investing countless billions on the technology.

I think the central flaw in Mr. Schneier’s thinking likely stems from where his thinking started from, which I suspect is best summarized with this line:

There is something un-American about a government program that uses secret criteria to collect dossiers on innocent people and shares that information with various agencies, all without oversight.

Of course, the truth is, this kind of thing is (with apologies to Robert Wuhl) “as American as apple pie”, which is exactly why Mr. Schneier is fearful of it (I’d say “paranoid about it”, but that implies that his fear isn’t rationally justifiable).

So, let’s assume three things:

1. The government isn’t completely incompetent with understanding how to employ these technologies (remember, this is all “brought to you by the people who brought you ECHELON”), and more importantly is informed by the multiple experts in the fields machine learning and data mining that they employ.
2. Folks working on these programs are highly motivated to catch terrorists.
3. Folks working on these programs are at least somewhat fearful of the same kind of abuse of powers that Mr. Schneier is, particularly if they think it could be directed at them or their friends and loved ones.

You might take issue with any of those assertions, but they all seem highly plausible to me, although my “American as apple pie” links make me somewhat dubious about #3. Frankly, if the other two aren’t true, we have got way bigger problems to worry about than a little misuse and abuse of data mining and machine learning techniques.

Now, if we go with these assumptions, how might the government employ something like ADVISE? Let me suggest some ways:

• Sifting and sorting the raw data
• Trimming down a suspect list
• Prioritizing leads

Sifting and sorting the raw data

This one comes right from the horse’s mouth. Mr. Schneier quotes Michael Chertoff as saying, “It is an experiment to see how you can better analyze data that you already have, that you’ve already legally collected, to see if you can understand it, sort it and make use of it more readily than simply doing it manually.” Let’s say for a moment, you’ve got all this data on 1000 people, and someone tells you, “there is a decent chance one of them is a terrorist with plans to attack innocent Americans in the coming year, could you go through this data yourself and give us a best guess as to who to investigate and in what order?” Okay, I’d probably get a team of people reading over every scrap of data right away. I’d start to collect more detailed data on the top candidates, but I’m not going to start asking for court orders, because all I’d have would be someone’s best guess as to whether this person is a terrorist. Now imagine you have the same data on 300 million people, or worse still, everyone on the planet? Are you really going to assemble a team to go over the data of all those people? Of course not! They’d likely retire and perhaps die before completing the task and by then the output would be moot anyway. Now, what if you could get a computer to sift through and sort the data such that it could produce a list of the top 1000 candidates. I’d sure be interested in that computer’s list. Sure, I’d know that I don’t even think there are anywhere near 1000 terrorists and odds are only like 1 in 100 that even one of the candidates is actually a terrorist, so I’m not going start arresting these people or opening up files on them, but I might assemble a team exactly like in the first example in order to refine the list further. Suddenly, I’ve gone from literally having no actionable data to being able to act on it, albeit in a limited way.

Trimming down a suspect list

Okay, our crack investigative team have identified and arrested some middle man who we know sold supplies to a terrorist with plans to strike. The problem is, this guy sold supplies to a lot of people, some innocent civilians, some organized crime types, and this one terrorist. We also have no idea of where or when he sold supplies to this terrorist. You do have a tape recording of him talking to the terrorist about that crazy waiter at Random Regional Restaurant. This guy has been in business for a while and has been successful, so he has a LOT of customers over the years. We have a customer list of all his customers, but the list is understandably quite extensive, possibly ten thousand customers over the years. You only have enough resources and time to investigate ten people in more detail. How do you decide which ten to look at? Well, you know that your target either lived in or visited Random Region in the past. You just might want to have a computer program go through the customer list, exclude all the candidates who’d never been to Random Region. You’d know that it is entirely possible that you don’t have complete data on the movements of all the individuals (particularly since some are shady characters who don’t like their movements tracked) but filtering in this manner brings you down to a small enough candidate list you can do some basic investigations, like calling each of them to see if their voice sounds like the one on the tape. From that, maybe you can identify candidates for further investigation.

Prioritizing

You have information suggesting someone might try to strike Metropolis in the next couple of months. You don’t know who, but you’ve narrowed it down to people either in Metropolis or who are visiting Metropolis in the next couple of months and you have some additional information that narrows the candidates down to a list you should be able to investigate in a month, now that you have wiretap authorizations for each of their phones. Here’s the problem: the terrorist could strike a lot sooner than a month. So, the order you investigate the candidates is very important, only you have no idea where to start beyond gut instinct! Wouldn’t it be nice to shove that list in to a computer and have it sort the list based on the probability that they are a terrorist and how soon they’ll be in Metropolis? Even if you knew the thing was only 70% accurate, you’d take it, because it would still give you better odds of stopping an incident than if you didn’t use it.

It is not to hard to come up with other scenarios, but these are the first three I could come up with that most closely resemble Mr. Schneier’s original straw man. All of these scenarios would benefit from the application of data mining and machine learning, even if you have crummy false positives and negatives and a target population of one that you are trying to identify. None of these are ridiculous “24”-style scenarios that never happen in reality.

So, what are the problems, beyond motivation, in Mr. Schneier’s reasoning?

Well, first, “base rate fallacy” is only a problem if the cost of a false positive or false negative is high enough as to outweigh the benefits of identifying at least some of the true positives. The classic example of this is with medical tests. Yes, if a disease is rare in a general population, even if there is a significant cost for doing subsequent tests, it may make economic sense to perform the test anyway if the savings from a correctly identified patient is astronomical enough. Sometimes only one true positive is enough to justify the expense of mislabeling half of a population. I see lawyers throwing up ads for Mesothelioma all over the place, even though they know most of the time the ads won’t be seen by a single person with the disease and that they’ll undoubtedly encourage several unsavory types to show up at their office and wasting costly staff time as they try to pretend to have the disease. Why? Because for every single real candidate they do identify is worth a jackpot of money to them.

Second, not having a “well defined terrorist profile” assumes that because one is using a computer a deductive reasoning model must be employed to reach a conclusion. Supervised learning methods like SVM’s excel at performing classifications based on doing the statistical equivalent of inductive reasoning. Sure, they get it wrong some of the time, but in cases where there a multitude of factors that help in the decision making process, these methods can often outperform a human working with the same data (and obviously taking far more time). Humans tend to excel at intuitively or logically identifying a few key indicators out of a possible set of millions, but computers excel at statistically identifying a complex model of interactions between millions of key indicators, which is handy if we don’t even know if any of the factors we’re considering have a real direct cause and effect relationship with the prediction we’re looking for.

Finally, there is an assumption that using these techniques necessarily leads to the government surveilling innocent people they’d otherwise have left alone. That is a matter of application rather than intrinsic to the technology. One could just as easily use the technology to identify innocent people that don’t need a file opened up on them. Heck, if we’d had this kind of thing in Hoover’s day, we might have been able to more easily identify the irregularities in how he was selecting candidates for wire tapping. We’re always hearing reports of authorities using racial profiling or just irregularities in one’s behavior leading to inappropriate scrutiny or persecution (remember the insanity over the whole Trench Coat Mafia thing?), well data mining and machine learning techniques could not only help identify inappropriate police behavior, but also provide a “second opinion” about whether someone was genuinely worthy of further investigation.

In general, tracking down the needle in the haystack is a very hard problem and one would want all tools available to do the job. Sure, I can see how the technology could be used to infringe upon people’s privacy, but that is no reason to throw out the baby with the bath water. Some basic oversight and rules ought to be sufficient to prevent the worst abuses..