← 2016 Protocols Workshop Smartphone Forensics to Detect Distraction →

Hacking Lottery Machines

Interesting article about how a former security director of the US Multi-State Lottery Association hacked the random-number generator in lottery software so he could predict the winning numbers.

For several years, Eddie Tipton, the former security director of the US Multi-State Lottery Association, installed software code that allowed him to predict winning numbers on specific days of the year, investigators allege. The random-number generators had been erased, but new forensic evidence has revealed how the hack was apparently done.

[...]

The number generator had apparently been hacked to produce predictable numbers on three days of the year, after the machine had gone through a security audit.

Note that last bit. The software would only produce the non-random results after the software security audit was completed.

It's getting harder and harder to trust opaque and unaccountable algorithms. Anyone who thinks we should have electronic voting machines -- or worse, Internet voting -- needs to pay attention.

Tags: , , , ,

Posted on April 12, 2016 at 6:39 AM • 51 Comments

Comments

Alex • April 12, 2016 7:49 AM

Similar tactic about 20 years ago in Vegas where the programmer who worked for the Gaming Control Board who was responsible for checking the code on all the Keno machines slipped in his own code to bust the game.

Looks like he got greedy and collected too many longshots for it to be probable.

https://en.wikipedia.org/wiki/Ronald_Dale_Harris

Spaceman Spiff • April 12, 2016 8:02 AM

IMHO, if it isn't open-sourced, and verified unmodified, it cannot be trusted!

fajensen • April 12, 2016 8:04 AM

Neat! I always wanted to do a hack like that.

It's a bit hard(er) here because our lotteries use physical bouncing-ball-draws rather than digital random number generators. I like to think someone has already considered the possibility of cloning / copying winning tickets so that tickets are cryptographically signed using a code sequence that is generated up till the close of the draw.

One does wonder how "they" *really* got suspicious of the Eddie Tipton. Seeing that his own brother is involved, I'd guess that he was not very proficient in the money laundering part of the job. He should probably have retired at the USD 500 K and be *very* grateful that the police? didn't do an "asset forfeiture" on him.

curious • April 12, 2016 8:17 AM

As usual, why didn't he use a mule to buy that winning ticket? This is just retarded again

paul • April 12, 2016 8:31 AM

Isn't this the kind of job where you should always have multiple people involved in making software changes? This sounds like all the companies where the same person cuts the checks for expenses/vendors and then signs them.

Jenny Juno • April 12, 2016 8:38 AM

Even a mule would be problematic because it isn't just the purchase of the ticket but collecting the prize - hard to find someone you trust to collect the prize and not just keep it for themselves. Harder even to find multiple people like that who aren't obviously and publicly connected to you like family.

He should have sold the winning numbers to an organized crime group. I'm sure he would have had to take a much smaller percentage of the winnings, but he could have kept it up indefinitely.

BManske • April 12, 2016 8:45 AM

Being relatively close to this story it seems to me that Eddie fell down on the social engineering aspect of the ploy. The technical execution was fine up to the point where he got greedy. His alterations could have been undone and he could have extracted himself without detection somewhere along the way. I have to wonder about the possibility of an $11 Billion class action that questions the validity of every Multi-State Lottery drawing for the past decade. It is an interesting cautionary tale for the modern age.

R. B. Hayes • April 12, 2016 10:06 AM

Electronic voting machines are fine; it's electronic voting that isn't. An electronic machine that just printed physical ballots for submission would be better than any past or current system.

Bardi • April 12, 2016 10:28 AM

Agree totally with R.B. Hayes. The US needs a voting system that includes a physical audit capability.

Jordan • April 12, 2016 10:39 AM

The number generator had apparently been hacked to produce predictable numbers on three days of the year, after the machine had gone through a security audit.

That could be interpreted such that the scheme was triggered by a security audit. However, it seems more likely that the intended interpretation is that the hack was added after the security audit.

That is, interpreted as "The number generator had apparently been hacked [...] after the machine had gone through a security audit." rather than "[...] to produce predictable numbers on three days of the year, after the machine had gone through a security audit."

I watched the airplane land, through my window.

keiner • April 12, 2016 11:04 AM

Electronic voting is political desirable not despite but BECAUSE you can hack it so easily. ;-)

Think about that for an hour and read what they do to move
electoral boundaries to get majorities or to marginalize minorities. There is a pattern.

tim • April 12, 2016 11:58 AM

IMHO, if it isn't open-sourced, and verified unmodified, it cannot be trusted!

There is no evidence that software that is "open-sourced" is more or less "secure" than software that is "closed-sourced".

tim • April 12, 2016 12:10 PM

Electronic voting machines are fine; it's electronic voting that isn't. An electronic machine that just printed physical ballots for submission would be better than any past or current system.

The issue isn't digital machines printing physical ballots. Its that elections are relatively rare events. A digital machine is complicated, they break down, and they don't alway store well for long periods of time when they aren't in use. And the people setting them up are generally older. Elections can't be repeated if something doesn't work or breaks down.

Voting should be done via the simplest methods possible. Paper and pencil with an automatic tabulator.

Bruce Thompson • April 12, 2016 12:48 PM

I'm a big fan of paper and pencil voting myself. I was a Scrutineer (poll watcher for a candidate to put it in US terms) for a Canadian Federal Election in the 80s. We used paper ballots with pencil marks, and the votes were tallied by hand. The ballots were then sealed and taken to the Returning Officer's office, to be kept in the event of a challenge.

To my mind, this is the only way to conduct elections. As soon as you introduce a computer into the process, Ken Thompson's Turing Award Speech leaps into mind. If you haven't read it, you should. The short summary is: Just because the source code has been inspected and audited doesn't mean that the compiler isn't compromised...

Jon Marcus • April 12, 2016 12:48 PM

@Tim, you're correct re claims about "open-source" vs "closed-source" software in general.

But intuitively, I find it hard to believe that a high-value (like a lottery or election) system is better on proprietary software maintained by a single entity. Just as a thought experiment, how would you pull this off if the software was open sourced? Hope for obscurity?

MrC • April 12, 2016 1:19 PM

@ Tim:
That's positively idiotic. Of course "[t]here is no evidence that software that is 'open-sourced' is more or less 'secure' than software that is 'closed-sourced'" -- because there is no evidence whatsoever respecting the closed-source software that one could use to make a comparison. The point is that closed-source software is inherently untrustworthy because you have no idea what devilry it may contain. Does this automatically make all open-source software secure and wonderful? No. It may still be poorly designed and/or buggy. Rather open-source software "wins by default" because closed-source software is inherently untrustworthy, while open-source software at least has the *potential* to be trustworthy. Put another way, being open-source is a *necessary but not sufficient condition* for software to be trustworthy.

Jeremy • April 12, 2016 1:27 PM

@Tim, @Jon Marcus

It seems like you are focused on the risk of someone finding an unintentional vulnerability in the software that allows them to manipulate the outcome. Reasonable people could argue about whether open- or closed-source code is likely to be more vulnerable to that sort of risk.

But Spaceman Spiff, and the original article, seem to be concerned about the possibility that the programmers who wrote software in the first place may have corrupted it intentionally from day 1. It seems difficult to argue that opening the source code to public scrutiny could possibly increase the risk of this sort of attack. (Although it's possible that accepting open submissions of source code could do so.)

Thunderbird • April 12, 2016 2:11 PM

I always wondered why people working for lotteries WOULDN'T cheat in this kind of way. Since we've seen a few cases, I think we can assume there are a bunch more where no one got caught.

According to the voluminous Wikipedia article (I can't make link embedding work on this site anymore so you'll have to look it up), this guy did everything possible to expose himself, including at least four attempts to collect the money (all denied by the lottery officials). Which also makes me wonder how many legitimate winners never get to claim their prizes.... After all, the lottery has the same incentive as an insurance company to avoid paying anything.

John Macdonald • April 12, 2016 2:41 PM

@Jordan

I'd parse it differently as saying that the code was written to only use the unrandom number generator on three dates - fixed in the code when he wrote it and that he chose dates that would be after the normal release audit would have finished. That meant that he was taking his chances that there wouldn't be a unscheduled audit on one of those days. I doubt that there was any attempt to detect an audit and use that as a trigger (which sounds like a complicated choice to implement since the code is going to be deployed on many machines and most of them would never go through an audit, and besides a dynamic check and change is harder to implement than a static change so that would be more likely to cause a coding error that exposes the fraud).

Volkswagen! • April 12, 2016 2:44 PM

@Jordan

"The number generator had apparently been hacked [...] after the machine had gone through a security audit."

Not necessarily. It depends on how the security audit is done. Does the security audit examine every line of the source code? Or just treat the system like a black box and test it from the outside? How do you know which one? If the latter, the hack itself could easily have happened BEFORE the security audit... and was just designed to produce proper randomness during the audit, then later on, on certain days, produce the non-randomness... Can anyone say "Vokswagen"? It could have been designed this way from day 1.

And THIS is why closed source cannot be trusted. Simply being open source doesn't automatically make things trustworthy either of course, it's just one link in a chain that makes it POSSIBLE to become so... as I think has already been mentioned... Other links include verifiability that the source code you see openly is what's actually running (proper full verifiability takes into account any compiler/interpreter too, of course) Another link is the hardware... how do you know the hardware itself hasn't been modified to skew the results somehow? Same principles of openness and verifiability must apply there too...

So yeah, it turns out it's far easier to be open and verifiable with a far more simple process (like a manual paper/pencil one) than a complex one (like a computerized one)... whoda thunkit?

albert • April 12, 2016 2:53 PM

ANY system can be hacked, by one means(extremely sophisticated) or another(dipshitsimple). Using technology to mitigate the abuse of technology is a fools errand.

It seems to me that Internet voting might be desirable for the Elite, because it would be cheaper to rig an election electronically, rather than to spend hundreds of millions on propaganda and campaign contributions, not to mention obvious actions like gerrymandering, discriminatory voter 'registration' laws and procedural rules, etc..

At the risk of stating the obvious, if folks stopped buying lottery tickets, lotteries would disappear, and if folks stopped gambling, legal gambling houses would disappear. Estimates vary, but the cost of gambling addiction in the US might be as high as $30 to $50 billion a year. Social 'costs' are wide ranging, and very difficult to quantify. (see casinowatch.org)

If folks stopped voting....well, the world would see what we think of our 'electoral system'.
. .. . .. --- ....

Volkswagen! • April 12, 2016 3:13 PM

I'd just like to mention that being "open and verifiable" STILL isn't enough to be fully trustworthy... there's another step... actually having enough eyeballs independently looking at it and performing verification... This is one step that most open source software falls flat on its face over, even critical software like OpenSSL... (probably because it's such a mess nobody wants to deal with it, let alone donate money to it) :)

There are also processes of putting things together that are inherently full of checks and balances, and thus are more secure to use than a more random messy "anything goes" process. This is another step that almost all open source software utterly fails at. Most closed source isn't any better, just that we can openly see that open source fails. But it's not because it's open or closed, it's because they're not following good secure processes.

I'm sure there are more steps I can't think of right now... :)

steven • April 12, 2016 5:40 PM

open source software and *reproducible builds*!

(or else, how do you know a compiled program matches what was audited)

Clive Robinson • April 12, 2016 6:07 PM

Other more technical pieces indicate it was not the main source of the application that he modified but a standard OS type dynamic linked library...

Thus even if the main code had been double or triple audited and the application signed the exploit would still have worked.

It might also account for why it took so long to find...

It begs the question as to how deep down such code can be buried...

Can anyone say "Pentium Bug" and not think below "microcode" or "RTL"?

Dan • April 12, 2016 6:58 PM

@Volkswagen,
If any writer of the software won the Underhanded C contest, you should look at the code closer. The Underhanded C contest is really worth looking through if you want to either design a backdoor or search for backdoors in software.

Ergo Sum • April 12, 2016 7:57 PM

@Bruce

Anyone who thinks we should have electronic voting machines -- or worse, Internet voting -- needs to pay attention.

Does it really matter in the US, if the election is rigged via electronic voting machines? The US has morphed in to oligarchy by now, that's what the research on the subject tells us anyway:

http://www.commondreams.org/views/2014/04/14/us-oligarchy-not-democracy-says-scientific-study

Elections have been rigged for awhile by now, just look at the current election year. Utilizing electronic voting system will just provide total control for the oligarchs. You can certainly bet that it'll make rigging the votes a lot easier...

Nick P • April 12, 2016 8:13 PM

@ steven

re reproducible builds

Careful to watch out for fads in INFOSEC. Anytime it's compilers, people online say one of these things: Thompson's Attack, Wheelers countering it, or reproducible builds. This is such bad information that I dedicated posts to countering it. Here's the one I use on Hacker News with links that will help you understand the issues. If anything is unclear, tell me as I will factor that into the next one:

"re need reproducible builds claim to "verify" (lol) source-to-object translation

None of them have verifiable builds. There are some doing reproducible builds with untrustworthy compilers and source. Verifiable builds are a larger problem they're ignoring because it's not a fad yet. Lots of prior work in CompSci and even industry on that, though. Links below on subversion and build-related stuff.

My description of subversion-resistant build:

https://news.ycombinator.com/item?id=10182282

Subversion-resistance in systems and builds in general:

https://news.ycombinator.com/item?id=10478742

Original Source: https://news.ycombinator.com/item?id=11362470"

Wael • April 12, 2016 9:00 PM

@Nick P,

My description of subversion-resistant build:

Good read. We had similar discussions here with you over the past three or so years. Subversion was always on your mind since our early discussions. I have a challenge for you:

Suppose everything you build your system has a more than zero probability of being subverted. Let's say it's highly likely for some components, and less likely for other components and you don't have a way to quantify the likelihood (because the "subverteur"[1] is way smarter than us.) Is there any possible technical solution to secure such a system? Getting older chips isn't an option, either.

[1] Ryhmes with provocateur.

Drone • April 12, 2016 10:11 PM

The best solution is to ban Lotteries. Government-run gambling is a horrible thing. It redistributes income from the poorest in society to the Government who then (very inefficiently) redistribute the money back to the poor as entitlements in exchange for their votes. It is a vicious cycle.

MrTroy • April 13, 2016 12:05 AM

For something like this, I'm not sure how much it matters whether the source is open or closed. If you enter the lottery, you are trusting the software that is on the machine running the draw to be doing the right thing. Unless someone is willing to show you the machine code that was executed at the time of the draw, no amount of audit or availability of source or machine code at any other time can really prove that trust.

Random audits of the code on the machine by a competent regulatory body seems required, but not sufficient... not to mention extremely unlikely.

Clive Robinson • April 13, 2016 2:41 AM

@ Wael,

Is there any possible technical solution to secure such a system?

You already know the answer to this...

And hoe do I know, well to quote you,

We had similar discussions here with you over the past three or so years.

And to misquote you,

    Subversion has always been on my mind since befor our early discussions.

Oh also did you see the three links @Dan posted? You will see why I think about microcode RTL and below CPU level attacks almost obsessively along with state machines as hypervisors, and "garden path" security, having done something similar a long time ago.

Clive Robinson • April 13, 2016 3:03 AM

@ Dan,

When I read these I thought they were awesome

It's the same sort of thing that I have done in the past, using real Option ROMs and modified NetROM code in old ISA bus PC's back around the time the PCI bus was being talked about.

If you hunt back in this blog, you will also find I talk about microcode and RTL attacks, and "bubbling up" attacks from even further down the computing stack.

If you also hunt back you will see in BadBIOS discusions, that there were a lot of doubters, who did not know what they were talking about. So I did a working proof of concept of an acoustic channel with Option ROMs.

It's us "Old but not Dead Hands" that should scare people more than the self publicizing "White Hats" of today to misquote Louis Armstrong in his 1971 "Wonderful World",

    I see the whitehats, I watch them grow, they'll learn much less than I got to know, and I think to my self what a breakable world... Yes I think to myself what a breakable world.

And I guess those "elephant" men in the TAO will now be humming the tune all day.

Wael • April 13, 2016 3:06 AM

@Clive Robinson, @Nick P, @Dan,

You already know the answer to this...

I just wanted to get "subversion" classified. What does subversion aim to do? Exfiltrate data, or manipulate calculations, or weaken crypto algorithms through various means, is it a class of a "back-door instance", RNG manipulation, command and control vector,... Then we can map each "instance" of the subversion mechanism to the overarching class and see if there is a way to mitigate the class. I don't know if all instances of subversions fall under the same class. In short, I really haven't thought about the answer except that I was alluding to... C-v-P and the prison architecture, since it deals with the assumption that everything (or most things) are subverted. It's apt he reason I chose to use the word "probability", which maps nicely to "probabilistic security". Seems you, unlike me, are adept at reading between the lines.

And to misquote you,

Affirmative! You have misquoted me! It was @Nick P who raised the issue of subversion back in 2012 with me. He had earlier discussions with you on the topic.

Oh also did you see the three links @Dan posted?

I did. Chose not to reply because you had already covered the topic and I had nothing meaningful to add. I also saw his "light detector" mechanism, and didn't reply for the same reason. But since you called me out, I'll post the links I intended to post;

See slide 15. Or this.

active and passive shielding. Check mesh FIB images on page 14.

This is a typical, but not complete, listing of some protection mechanisms on a particular chip. Manufacturers almost never reveal all the mechanisms:

The ATAES132A device contains physical security features to prevent an attacker from determining the internal secrets. ATAES132A includes tamper detectors for voltage, temperature, frequency, and light, as well as an active metal shield over the circuitry, internal memory encryption, and other various features. The ATAES132A physical design and cryptographic protocol are designed to prevent or significantly complicate most algorithmic, timing, and side-channel attacks. [1]

Some manufacturers use over 50 mechanisms of protection.


[1]

Petter • April 13, 2016 3:35 AM

@keiner

My thought as well.
I guess there are far more behind this than we are told and I we will prolly never really get the whole story.

Wael • April 13, 2016 5:10 AM

@Clive Robinson, @Dan,

If you also hunt back you will see in BadBIOS discusions...

Here are the links related to BadBIOS[1]: badBIOS, BIOS Hacking. There was an honorary mention of BadBIOS here as well.

[1] Not plural of "Biography" (Bios) -- for BadBios, you'll need to look elsewhere. Just in case ;)

James • April 13, 2016 6:08 AM

Quoth @RBHayes:

Electronic voting machines are fine; it's electronic voting that isn't.

Ah, Little America syndrome again: "we can't do it, so it can't be done." Ask the Estonians, because they seem to have no problem at all with making it work.

Anselm Lingnau • April 13, 2016 6:34 AM

The Estonians have something that they use for electronic voting. Who knows for sure whether that is actually secure (and meets all the other desirable properties of a voting system).

This is not an issue that tends to make the news since, on the whole, people are much more concerned about who governs the USA than they are about who governs Estonia.

(Disclaimer: I've been to Estonia and it is a wonderful place with very nice people.)

R. B. Hayes • April 13, 2016 1:17 PM

@albert, @Drone:

Despite the (many) negative social effects of lotteries, they are on balance a social good. It's not because the revenues or payouts are a social good, of course; those are among the negative effects. Rather, it's because legitimate lotteries are able to displace the old Mafia lotteries ("the policy") that were both a huge source of revenue and a huge source of influence on the retail sector. There's a reason why every state lottery has a "Cash 3" game that works exactly the way that the policy did. Starving organized crime of its revenues is a good thing.

Nick P • April 13, 2016 1:23 PM

@ Dan

The solutions are simple for peripheral or I/O HW security issues: HW you trust because you fab it from source; regular HW w/ IO/MMU + plus other mediation; PIO instead of DMA; dedicated, embedded device doing any of that passing I/O onto host in trustworthy way.

@ Wael

"Suppose everything you build your system has a more than zero probability of being subverted. "

That requires gathering sand on a beach, knowledge of solid state physics, reinventing measuring equipment, retesting everything in textbooks... it's too large a project for a discussion here. You might have to narrow the scope with what you trust.

"I just wanted to get "subversion" classified."

In my links I posted the definitive work on the subject. You might want to start with it.

Subversion: The neglected aspect of computer security 1980 Philip A. Myers

http://csrc.nist.gov/publications/history/myer80.pdf

"This thesis distinguishes three methods of attacking internal protection mechanisms of computers: inadvertant disclosure, penetration, and subversion... Subversion is characterized by three phases of operations: the insertion of trap doors and Trojan horses, the excersising of them, and the retrieval of the resultant unauthorized informaiton. Insertion occurs over the entire life cycle of the system from the system design phase to the production phase."

So, that's the start. One way of looking at it is it's the insertion of malicious, stealthy functionality into a system at any phase of the lifecycle that's activated with a trigger to compromise system security. Also, we typically define subversion as something in and of itself to be applied to other aspects of systems instead of putting it in some other category. It really deserves its own cross-cutting category.

"C-v-P and the prison architecture, since it deals with the assumption that everything (or most things) are subverted."

It really doesn't. I addressed that in my critique. Both that model and my model require you to trust the design that mediates and HW lifecycle. There's no getting out of that without doing a totally different model where you're not really trusting anything. As in, his little hypervisors couldn't be trusted any more than my CPU extensions or separation kernels. You'd go to some other model where you have untrustworthy stuff interacting in ways where you hope the result is trustworthy. Some people are trying to model this kind of thing.

Drone • April 13, 2016 1:49 PM

@R. B. Hayes,

"Starving organized crime of its revenues is a good thing."

WRONG...

Government-run Lotteries as a remedy to outright Criminal activity is a epic failure of a Society which is (supposedly) bound by Rule-of-Law! Stopping the "Mafia" via Law-Enforcement is the Right thing to do. Competing with the Mafia in an attempt to stop them is the Wrong thing to do.

Wael • April 13, 2016 3:17 PM

@Nick P,

You might have to narrow the scope with what you trust.

Okay, makes sense. What do you trust?

Nick P • April 13, 2016 3:34 PM

@ Wael

No, the question is what do YOU trust. That is in terms of primitive components, measurement gear/techniques, fabrication plants, assembly plants, materials providers for breadboards or wgatever, and so on. From there, you build up your model of how to counter subversion of remaining pieces of the problem.

Note: This is covering stuff you directly trust rather than techniques to confuse malicious components. Just to keep it focused.

Wael • April 13, 2016 4:11 PM

@Nick P,

I trust what's under my exclusive control. That assumes I trust myself ;)

Nick P • April 13, 2016 4:25 PM

@ Wael

You trust Intel and ARM SOC's that don't come with remote management? Well, there you go. Problem solved.

AJWM • April 13, 2016 7:06 PM

Not necessarily. It depends on how the security audit is done. Does the security audit examine every line of the source code? Or just treat the system like a black box and test it from the outside?

Back when I worked for an indepenant testing company that audited voting systems (about five years ago now), it was both. We did line-by-line examination of the source, we did compile and compare against the vendor-supplied binaries, and we did user testing. We also did a number of physical tests for RF leakage and EM sensitivity (both directions), physical locking mechanisms, etc.

Never got the chance to work on lotto systems, though.

And no, I wouldn't trust electronic voting systems beyond the kind that produce an auditable printed record (relating to another story here).

(Somehow unsurprisingly, our main client was bought out by their competitor Diebold who shortly after cancelled our contract.)

Anon • April 14, 2016 6:56 AM

Open source or closed source - it doesn't matter. What matters is that the code is audited, and that a chain of trust exists from source code to final machine usage.

At each step, multiple people must be involved, to reduce the possibility of corruption. e.g. Code audit using a shared screen in a large room, so everyone is looking at exactly the same thing, then proceed from there.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

← 2016 Protocols Workshop Smartphone Forensics to Detect Distraction →

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.