November 24, 2024

Counterfeits, Trojan Horses, and shady distributors

Last Friday, the New York Times published an article about counterfeit Cisco products that have been sold as if they were genuine and are widely used throughout the U.S. government.  The article also raised the concern that these counterfeits could well be engineered with malicious intent, but that this appears not to have been the case. There was an immediate Slashdot thread as well, but a number of issues are still worth commenting on.

First things first: the facts, as best we understand them.  The New York Times reports that approximately 3500 counterfeit Cisco components (worth $3.5M) have been discovered as a result of a two-year FBI investigation.  A Cisco spokesman is quoted saying that they found “no evidence of re-engineering.”  In other words, we’re talking about faithful knock-offs of legitimate products.

If you go to the FBI’s unclassified PowerPoint presentation (dated January 11, 2008), you’ll see all the actual information.  This is a fascinating read.  For starters, let’s talk about the cost.  The slides claim you can get a counterfeit router for approximately 1/6 the cost of a genuine router.  (You can do similarly well buying used gear on eBay.)  The counterfeit gear looks an awful lot like the genuine article.  Detecting differences here is as difficult as detecting counterfeit money, counterfeit Rolex watches, or counterfeit signatures from sports stars.  Given the apparent discrepancy between component cost and street value, we should be no more surprised to find knock-off Cisco gear than we are to find knock-off everything else.

Counterfeit vs. Original Cisco line card

It’s claimed that these counterfeits are built to lower manufacturing standards than the original equipment, causing higher failure rates. One even caught fire due to a faulty power supply.  Likewise, the fakers are making stupid errors, like building multiple components with the same MAC address.  (MAC addresses, by design, are meant to be unique – no two ever the same.)

The really interesting story is all about the supply chain. Consider how you might buy yourself a new Mac.  You could go to your local Apple store.  Or you could get it from any of a variety of other stores, who in turn may have gotten it from Apple directly or may have gone through a distributor.  Apparently, for Cisco gear, it’s much more complicated than that.  The U.S. government buys from “approved” vendors, who might then buy from multiple tiers of sub-contractors.  In one case, one person bought shady gear from eBay and resold it to the government, moving a total of $1M in gear before he was caught.  In a more complicated case, Lockheed Martin won a bid for a U.S. Navy project.  They contracted with an unauthorized Cisco reseller who in turn contracted with somebody else, who used a sub-contractor, who then directly shipped the counterfeit gear to the Navy. (The slides say that $250K worth of counterfeit gear was sold; duplicate serial numbers were discovered.)

Why is this happening?  The Government wants to save money, so they look for contractors who can give them the best price, and their contracts allow for subcontracts, direct third-party shipping, and so forth.  There is no serious vetting of this supply chain by either Cisco or the government. Apparently, Cisco doesn’t do direct sales except for high-end, specialized gear.  You’d think Cisco would follow the lead of the airline industry, among others, and cut out the distributors to keep the profit for themselves.

Okay, on to the speculation.  Both the New York Times and the FBI presentation concern themselves with Trojan Horses.  Even though there’s no evidence that any of this counterfeit gear was actually malicious, the weak controls in the supply chain make it awfully easy for such compromised gear to be sold into sensitive parts of the government, raising all the obvious concerns.

Consider a recent paper by U. Illinois’s Sam King et al. where they built a “malicious processor”.  The idea is pretty clever.  You send along a “secret knock” (e.g., a network packet with a particular header) which triggers a sensor that enables “shadow code” to start running alongside the real operating system.  The Illinois team built shadow code that compromised the Linux login program, adding a backdoor password.  After the backdoor was tripped, it would disable the shadow code, thus going back to “normal” operation.

The military is awfully worried about this sort of threat, as well they should be.  For that matter, so are voting machine critics. It’s awfully easy for “stealth” malicious behavior to exist in legitimate systems, regardless of how carefully you might analyze or test it. Ken Thompson’s classic paper, Reflections on Trusting Trust, shows how he designed a clever Trojan Horse for Unix.  [Edit: it’s unclear that it ever got released into the wild.]

Okay everybody, let’s put on our evil hats.  If your goal was to get a Trojan Horse router into a sensitive military environment, how would you do it and how would it behave?  Clearly, the weak supply chain is an excellent vector for getting the gear into place.  Given the resources of a nation-state intelligence agency, you could afford to buy genuine Cisco parts and modify them, rather than using low-cost, counterfeit gear.  Nobody would detect you; you wouldn’t screw up and ship multiple boxes with the same serial number.

How will you implement your Trojan Horse logic?  Pretty much any gear you’ll ever find of any modest complexity will have software running inside it.  Even line cards have embedded processors of some sort.  For all that hardware, there’s software, and that’s what you’d go to install your logic bomb.  The increasing use of FPGAs in industrial designs means you could also “rewire” those parts to behave arbitrarily, much like the Illinois hack; you’d really want to get a hold of the original VHDL “source code”, leveraging your aforementioned spying prowess, to simplify the design and implementation of your malicious behavior.  Hacking the raw netlists (the FPGA-equivalent of machine code) would be possible, but would be far more painful. [See Sidebar.]

What sort of behavior would you build in?  The New York Times raises the idea of a kill switch.  I send your router a magic packet and it dies.  That’s too easy.  How about I send your router a magic packet, it then forwards it on to all of its peers, repeatedly, and then they all die a few seconds later?  That’s a pretty good denial of service attack (nevermind a plot device that was the basis of a popular science fiction television series). Alternatively, following the Illinois idea, we could imagine that the magic packet turns on a monitoring feature, allowing our intelligence agency to gather all kinds of information, reconfigure the router, and so forth.  If they don’t want to generate extra traffic, which might be detected, they could instead weaken the encryption of a VPN tunnel, perhaps publishing the session key through a subliminal channel of some sort, acquiring the ciphertext through “other” means.

In summary, it’s probably a good thing, from the perspective of the U.S. military, to discover that their supply chain is allowing counterfeit gear into production.  This will help them clean up the supply chain, and will also provide an extra push to consider just how much they trust the sources of their equipment to ship clean software and hardware.

[Sidebar: Xilinx supports a notion of “encrypting” a netlist.  Broadly speaking, the idea behind the technology is to encrypt the description of your FPGA configuration with a crypto key, such that anybody who reads the file out of your board gets encrypted garbage.  However, the FPGA has the key material to decrypt the configuration and then initialize itself normally.  This sort of technology is meant to serve an anti-piracy / anti-reverse-engineering purpose.  It could ostensibly also serve an anti-Trojan Horse purpose, although at that point it’s really no more or less secure, semantically, than Microsoft’s Authenticode.  This technology, more broadly, is also an active research area (see, for example, Roy et al.’s EPIC: Ending Piracy of Integrated Circuits).  Again, if we’ve got a nation-state intelligence service tampering with the system, none of this is going to provide meaningful protection for the end-user against Trojan Horses.]

NJ Voting Machine Tape Shows Phantom Obama Vote

I’ve written before (1, 2, 3) about discrepancies in the election results from New Jersey’s February 5 presidential primary. Yesterday we received yet another set of voting machine result tapes. They show a new kind of discrepancy which we haven’t seen before – and which contradicts the story told by Sequoia (the vendor) and the NJ Secretary of State about what went wrong in the election.

The new records are from three voting machines in Pennsauken, District 6. We have the result tapes printed out by all three voting machines in that district (1, 2, 3). As usual, each result tape has a “Candidate Totals” section giving the vote count for each candidate, and a separate “Option Switch Totals” section giving the voter turnout in each party. We also have the Democratic vote totals reported by the county clerk for that district (and some others), which were apparently calculated from the memory cartridges used in the three machines.

The county clerk’s totals show 279 votes in Pennsauken District 6. The per-candidate counts are Clinton 181, Obama 94, Richardson 2, Edwards 1, Kucinich 0, Biden 1, which adds up correctly to 279. The turnout sections of the three result tapes also show a total Democratic turnout of 279 (133+126+20).

But the Candidate Totals sections of the tapes tell a different story. Adding up the three tapes, the totals are Clinton 181, Obama 95, Richardson 2, Edwards 1, Kucinich 0, Biden 1, which adds up to 280. The Candidate Totals on the tapes show an extra Obama vote that doesn’t appear anywhere else.

(Everything seems to add up on the Republican side.)

The State claimed, in response to some (but not all) of the discrepancies I pointed out previously, that I had misread the tapes. This time the tapes are absolutely clear. Here are the Democratic candidate totals from the three tapes:

Here are the turnout sections of the three tapes:

(These images are all scans – the original documents Camden County sent me are even clearer.)

This is wrong. It is inconsistent with Sequoia’s explanation for the previously-noticed discrepancies. It is inconsistent with the State’s theory of what went wrong in the election.

It’s time for an independent investigation.

The Security Mindset and "Harmless Failures"

Bruce Schneier has an interesting new essay about how security people see the world. Here’s a sample:

Uncle Milton Industries has been selling ant farms to children since 1956. Some years ago, I remember opening one up with a friend. There were no actual ants included in the box. Instead, there was a card that you filled in with your address, and the company would mail you some ants. My friend expressed surprise that you could get ants sent to you in the mail.

I replied: “What’s really interesting is that these people will send a tube of live ants to anyone you tell them to.”

Security requires a particular mindset. Security professionals – at least the good ones – see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.

This kind of thinking is not natural for most people. It’s not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don’t have to exploit the vulnerabilities you find, but if you don’t see the world that way, you’ll never notice most security problems.

I’ve often speculated about how much of this is innate, and how much is teachable. In general, I think it’s a particular way of looking at the world, and that it’s far easier to teach someone domain expertise – cryptography or software security or safecracking or document forgery – than it is to teach someone a security mindset.

The ant farm story illustrates another aspect of the security mindset. Your first reaction to the might have been, “So what? What’s so harmful about sending a package of ordinary ants to an unsuspecting person?” Even Bruce Schneier, who has the security mindset in spades, doesn’t point to any terrible consequence of misdirecting the tube of ants. (You might worry about the ants’ welfare, but in that case ant farms are already problematic.) If you have the security mindset, you’ll probably find the possibility of ant misdirection to be irritating; you’ll feel that something should have been done about it; and you’ll probably file it away in your mental attic, in case it becomes relevant later.

This interest in “harmless failures” – cases where an adversary can cause an anomalous but not directly harmful outcome – is another hallmark of the security mindset. Not all “harmless failures” lead to big trouble, but it’s surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.

To see why, consider the donotreply.com email story that hit the press recently. When companies send out commercial email (e.g., an airline notifying a passenger of a flight delay) and they don’t want the recipient to reply to the email, they often put in a bogus From address like . A clever guy registered the domain donotreply.com, thereby receiving all email addressed to donotreply.com. This included “bounce” replies to misaddressed emails, some of which contained copies of the original email, with information such as bank account statements, site information about military bases in Iraq, and so on. Misdirected ants might not be too dangerous, but misdirected email can cause no end of trouble.

The people who put donotreply.com email addresses into their outgoing email must have known that they didn’t control the donotreply.com domain, so they must have thought of any reply messages directed there as harmless failures. Having gotten that far, there are two ways to avoid trouble. The first way is to think carefully about the traffic that might go to donotreply.com, and realize that some of it is actually dangerous. The second way is to think, “This looks like a harmless failure, but we should avoid it anyway. No good can come of this.” The first way protects you if you’re clever; the second way always protects you.

Which illustrates yet another part of the security mindset: Don’t rely too much on your own cleverness, because somebody out there is surely more clever and more motivated than you are.

Sequoia's Explanation, and Why It's Not the Whole Story

I wrote yesterday about discrepancies in the results reported by Sequoia AVC Advantage voting machines in New Jersey.

Sequoia issued a memo giving their explanation for what might have happened. Here’s the relevant part:

During a primary election, the “option switches” on the operator panel must be used to activate the voting machine. The operator panel has a total of 12 buttons numbered 1 through 12. Each party participating in the primary election is assigned one of the option switch buttons. The poll worker presses a party option switch button based on the voter authorization slip given to the voter after signing the poll book, and then the poll worker presses the green “Activate” button. This action causes that party’s contests to be activated on the ballot face inside the voting booth.

Let’s assume the Democrat party is assigned option switch 6 while the Republican Party is assigned options switch 12. If a Democrat voter arrives, the poll worker presses the “6” button followed by the green “Activate” button. The Democrat contests are activated and the voter votes the ballot. For a Republican voter, the poll worker presses the “12” button followed by the green “Activate” button, which then activates the Republican contests and the voter votes the ballot. This is the correct and proper method of machine activation when using option switches.

However, we have found that when a poll worker selects the lower of the two assigned selection codes, followed by pressing an unused selection code and then pressing the green “Activate” button, the higher numbered party on the operator panel has its contests activated instead while the selection code button for the original party stays active on the operator panel.

Using the above example with the Democrat Party as option switch 6 and the Republican Party as option switch 12, the poll worker presses button 6 for Democrat. The red light next to button number 6 lights up and the operator panel display will show DEM. The poll worker then presses any unused option switch. The red light stays lit next to option switch 6 and the display still says DEM. Now the poll worker presses the green “Activate” button. The red light stays lit next to button number 6, but the operator panel display now says REP and the ballot in the voting booth will activate the Republican party contests.

In each and every case where a machine displays the party turnout issue at the close of the polls, this is the situation that would have caused it, and it can be duplicated on any machine. In addition, for this situation to have occurred, the voter that was in the voting booth at the time of the poll workers action would have voted the opposite party ballot instead of telling the poll worker that the incorrect ballot was activated and the machine would not allow them to vote the party they intended. If they had informed the poll worker, they could have made the party selection change and the voter would have then voted the correct ballot style.

Several points are in order.

First, it’s obvious from this description, and from the fact that this happened on so many machines across the state, that even if Sequoia’s explanation is entirely correct, there was some kind of engineering error on Sequoia’s part that caused the machines to misbehave. Sequoia has tried to paint the anomalies as poll worker error, but that’s not plausible in light of Sequoia’s own explanation.

Consider the scenario described above: there is a moment when the red light next to the DEM button is lit, the operator panel displays DEM, then the poll worker presses the Activate button – and the Republican ballot is activated. No competent engineer would design a system to work that way.

No competent engineer would design this system to ever display REP in the operator panel while simultaneously lighting only the DEM light.

No competent engineer would design this system to ever activate the Republican ballot when the poll worker had pressed the DEM button but had not pressed the REP button.

Sequoia’s own explanation makes clear that they made an engineering error that caused the voting machine to behave incorrectly.

Second, this doesn’t look like fraud, only error. A malicious attacker who had access to a machine would have had much more powerful, and much less detectable, options at his disposal.

Third, Sequoia seems to avoid saying that what they describe is the only possible cause of such errors. Note the careful wording, “In each and every case where a machine displays [an error], this is the situation that would have caused it …” (emphasis added). They don’t say this “did” cause the errors; they say it “would have”. The sentence is either clumsy or artfully worded.

Fourth, Sequoia’s explanation involves a voter seeing the wrong party’s ballot being activated, and not complaining about it. Assuming (as press accounts say) that the problem happened about sixty times in New Jersey, one would expect that many voters noticed and complained. And one would expect that in at least one of those cases, a poll worker would have noticed that the operator panel was displaying REP and DEM at the same time. Yet there don’t seem to be reports of such behavior.

Fifth, Sequoia doesn’t characterize fully the cases where this problem might occur, so election officials don’t know, for example, which past elections might have been affected.

The bottom line is clear. An investigation is needed – an independent investigation, done by someone not chosen by Sequoia, not paid by Sequoia, and not reporting to Sequoia.

Evidence of New Jersey Election Discrepancies

Press reports on the recent New Jersey voting discrepancies have been a bit vague about the exact nature of the evidence that showed up on election day. What has the county clerks, and many citizens, so concerned? Today I want to show you some of the evidence.

The evidence is a “summary tape” printed by a Sequoia AVC Advantage voting machine in Hillside, New Jersey when the polls closed at the end of the presidential primary election. The tape is timestamped 8:02 PM, February 5, 2008.

The summary tape is printed by poll workers as part of the ordinary procedure for closing the polls. It is signed by several poll workers and sent to the county clerk along with other records of the election.

Let me show you closeups of two sections of the tape. (Here’s the full tape, in TIF format.)

Above you can see the vote totals on this machine for each candidate. On the Democratic side, the tally is Obama 182, Clinton 179. On the Republican side it’s Giuliani 1, Romney 13, McCain 40, Paul 3, Huckabee 4.

Above is the “Option Switch Totals” section, which shows the number of times each party’s ballot was activated: 362 Democratic and 60 Republican.

This doesn’t add up. The machine says the Republican ballot was activated 60 times; but it shows a total of 61 votes cast for Republican candidates. It says the Democratic ballot was activated 362 times; but it shows a total of 361 votes for Democratic candidates. (New Jersey has a closed primary, so voters can cast ballots only in their own registered party.)

What’s alarming here is not the size of the discrepancy but its nature. This is a single voting machine, disagreeing with itself about how many Republicans voted on it. Imagine your pocket calculator couldn’t make up its mind whether 1+13+40+3+4 was 60 or 61. You’d be pretty alarmed, and you wouldn’t trust your calculator until you were very sure it was fixed. Or you’d get a new calculator.

This wasn’t an isolated instance, either. In Union County alone, at least eight other AVC Advantage machines exhibited similar problems, as did dozens more machines in other counties.

Sequoia, the vendor, is trying to prevent any independent investigation of what happened.

Tomorrow: Sequoia’s story about how this happened, and why it’s inadequate.

UPDATE (March 20): We now have copies of nine anomalous tapes, including the one shown above. They’re on our New Jersey voting documents page.