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.