Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
PGN-ed excerpts from a wonderful parody toward the end of The Colbert [coal-bear] Report on Comedy Central on the evening of Election Day in the U.S.: Now, there have been reports of voting machine irregularities ... For instance in Jackson County, West Virginia, machines have actually changed votes, which would explain why `Candidate Page error 404' is now headed to the House of Representatives [with 93% of the vote]. Congratulations! Now, for more on this very disturbing story, let's go to where the polls are still open—Kalua, Hawaii. ... [with Colbert inside the voting machine, behind the touchscreen, with the camera able to see the voter!] Colbert: Hello voter! Voter: Hey, Steven Colbert is in my voting machine! Colbert: Shhh. Have you seen anything suspicious? Colbert does a lovely Alex Halderman imitation, flipping the voter's straight-party selections to the other party. http://www.colbertnation.com/the-colbert-report-videos/364228/november-02-2010/indecision-2010---gop-takes-house
Freedom to Tinker
... is your freedom to understand, discuss, repair, and modify the
technological devices you own.
J. Alex Halderman, Hacking the D.C. Internet Voting Pilot, 5 Oct 2010
The District of Columbia is conducting a pilot project
<http://www.dcboee.us/DVM/> to allow overseas and military voters to
download and return absentee ballots over the Internet. Before opening the
system to real voters, D.C. has been holding a test period in which they've
invited the public to evaluate the system's security and usability.
This is exactly the kind of open, public testing that many of us in the
e-voting security community—including me—have been encouraging vendors
and municipalities to conduct. So I was glad to participate, even though the
test was launched with only three days; notice. I assembled a team from the
University of Michigan, including my students, Eric Wustrow
<http://ericw.us/trow> and Scott Wolchok <http://scott.wolchok.org>, and
Dawn Isabel, a member of the University of Michigan technical staff.
Within 36 hours of the system going live, our team had found and
exploited a vulnerability that gave us almost total control of the
server software, including the ability to change votes and reveal
voters' secret ballots. In this post, I'll describe what we did, how we
did it, and what it means for Internet voting.
D.C.'s pilot system
The D.C. system is built around an open source server-side application
<http://github.com/trustthevote/DCdigitalVBM> developed in partnership with
the TrustTheVote project <http://www.trustthevote.org>. Under the hood, it
looks like a typical web application. It's written using the popular Ruby on
Rails framework and runs on top of the Apache web server and MySQL database.
Absentee overseas voters receive a physical letter in the mail instructing
them to visit a D.C. web site, http://www.dcboee.us/DVM/, and log in with a
unique 16-character PIN. The system gives voters two options: they can
download a PDF ballot and return it by mail, or they can download a PDF
ballot, fill it out electronically, and then upload the completed ballot as
a PDF file to the server. The server encrypts uploaded ballots and saves
them in encrypted form, and, after the election, officials transfer them to
a non-networked PC, where they decrypt and print them. The printed ballots
are counted using the same procedures used for mail-in paper ballots.
A small vulnerability, big consequences
We found a vulnerability in the way the system processes uploaded
ballots. We confirmed the problem using our own test installation of the
web application, and found that we could gain the same access privileges
as the server application program itself, including read and write
access to the encrypted ballots and database.
The problem, which geeks classify as a shell-injection vulnerability, has to
do with the ballot upload procedure
<http://github.com/trustthevote/DCdigitalVBM/blob/6020c7158f679e29b0b263d93c4529244498d5d3/lib/paperclip_processors/encrypt.rb#L42>.
When a voter follows the instructions and uploads a completed ballot as a
PDF file, the server saves it as a temporary file and encrypts it using a
command-line tool called GnuPG <http://www.gnupg.org/>. Internally, the
server executes the command gpg with the name of this temporary file as a
parameter: |gpg [] /tmp/stream,28957,0.pdf|.
We realized that although the server replaces the filename with an
automatically generated name (stream,28957,0) in this example), it keeps
whatever file /extension/ the voter provided. Instead of a file ending in
.pdf, we could upload a file with a name that ended in almost any string we
wanted, and this string would become part of the command the server
executed. By formatting the string in a particular way, we could cause the
server to execute commands on our behalf. For example, the filename
ballot.$(sleep 10)pdf would cause the server to pause for ten seconds
(executing the sleep 10 command) before responding. In effect, this
vulnerability allowed us to remotely log in to the server as a privileged
user.
Our demonstration attacks
D.C. launched the public testbed server on Tuesday, September 28. On
Wednesday afternoon, we began to exploit the problem we found to
demonstrate a number of attacks:
* We collected crucial secret data stored on the server, including
the database username and password as well as the public key used
to encrypt the ballots.
* We modified all the ballots that had already been cast to contain
write-in votes for candidates we selected
<http://www.cse.umich.edu/~jhalderm/pub/dc/evil_ballot.pdf>.
(Although the system encrypts voted ballots, we simply discarded
the encrypted files and replaced them with different ones that we
encrypted using the same key.) We also rigged the system to
replace future votes in the same way.
* We installed a back door that let us view any ballots that voters
cast after our attack. This modification recorded the votes, in
unencrypted form, together with the names of the voters who cast
them, violating ballot secrecy.
* To show that we had control of the server, we left a calling
card—on the system's confirmation screen, which voters see after
voting. After 15 seconds, the page plays the University of
Michigan fight song. Here's a demonstration
<http://www.cse.umich.edu/~jhalderm/pub/dc/thanks/>.
Stealthiness wasn't our main objective, and our demonstration had a much
greater footprint inside the system than a real attack would need.
Nevertheless, we did not immediately announce what we had done, because we
wanted to give the administrators an opportunity to exercise their intrusion
detection and recovery processes—an essential part of any online voting
system. Our attack remained active for two business days, until Friday
afternoon, when D.C. officials took down the testbed server after several
testers pointed out the fight song.
Based on this experience and other results from the public tests, the
D.C. Board of Elections and Ethics has announced that they will not
proceed with a live deployment of electronic ballot return at this time,
though they plan to continue to develop the system. Voters will still be
able to download and print ballots to return by mail, which seems a lot
less risky.
D.C. officials brought the testbed server back up today (Tuesday) with the
electronic ballot return mechanism disabled. The public test period will
continue until Friday, October 8.
What this means for Internet voting
The specific vulnerability that we exploited is simple to fix, but it will
be vastly more difficult to make the system secure. We've found a number of
other problems in the system, and everything we've seen suggests that the
design is /brittle/: one small mistake can completely compromise its
security. I described above how a small error in file-extension handling
left the system open to exploitation. If this particular problem had not
existed, I'm confident that we would have found another way to attack the
system.
None of this will come as a surprise to Internet security experts, who are
familiar with the many kinds of attacks that major web sites suffer from on
a daily basis. It may someday be possible to build a secure method for
submitting ballots over the Internet, but in the meantime, such systems
should be presumed to be vulnerable based on the limitations of today's
security technology.
We plan to write more about the problems we found and their implications
for Internet voting in a forthcoming paper.
Professor J. Alex Halderman <http://alexhalderman.com/> is a computer
scientist at the University of Michigan./
Freedom to Tinker is hosted by Princeton's Center for Information
Technology Policy <http://citp.princeton.edu/>, a research center that
studies digital technologies in public life. Here you'll find comment
and analysis from the digital frontier, written by the Center's faculty,
students, and friends.
I was shocked to find on the DCBOEE's website (<http://www.dcboee.us/DVM/default.asp>) that they had decided to proceed with the use of the voting system they obtained from OSDV to collect Internet ballots in the 2 Nov 2010 general election, despite it having been proven to be highly flawed in terms of both security and integrity. I have become increasingly concerned that the recent wave of "voting hack exhibitions" are having the reverse effect. I'm not saying that these experiments shouldn't continue, but by somehow validating that the systems have been subjected to "testing" (even when this testing exposes massive vulnerabilities), the vendors and election officials seem to feel that it is appropriate to go ahead with deployment of these products. "At least we know [some of] the problems" is no way to run elections. A lengthy 22 Oct posting by Gregory Miller at the OSDV's TrustTheVote Project blog (at <http://www.trustthevote.org/d-c-reality-check---the-opportunities-and-challenges-of-transparency/comment-page-1#comment-9463>) underscores this "head in the sand" attitude by lauding the fact that "the District owns 100% of the source code, which is fully transparent and open source" as somehow a good thing. Actually this "ownership" means that the DC Election Officials had the freedom to deploy it, and they apparently did do so, despite knowing that it was vulnerable to international attack. Does the DCBOEE really think that their website admonishment about the paltry $10,000 fine and possible imprisonment is going to stop anyone, especially foreign hackers (who may not be subject to US laws), from using proxy servers to avoid detection? Does the OSDV truly believe that the DCBOEE has the ability to detect tampering if it occurs? And if they discover that the system was hacked during the actual election, do they have a plan to allow the affected voters to recast their ballots in a secure way? Heck, when consumer electronics or automobiles are discovered to have systemic problems, they are RECALLED! Shouldn't the OSDV folks be ashamed of themselves for not including a clause in their distribution that IMMEDIATELY RECALLS THIS PRODUCT and ENSURES IT WOULD NOT BE USED IN ANY ACTUAL GOVERNMENT ELECTION, if any vulnerabilities test or subsequent data exposes it as insecure and/or unreliable? Even more disconcerting is the cavalier attitude by the DCBOEE, in deciding to go ahead with this moronic experiment, knowing that the system was so massively flawed. This proves EXACTLY WHAT I (and others, especially PGN) HAVE ALWAYS SAID ABOUT OPEN SOURCE VOTING—even if OSDV had been able to provide an update to remedy all of the KNOWN problems, there would be no time to adequately test it, and there would be no way for the voters to ensure that the CORRECTED version (and not a flawed or hacked one) is being used at the time of the election. Open source voting thus provides a false sense of security about electronic elections, which this sad experience has vividly demonstrated. As Ken Thompson said in 1984: "You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code." This is still true, whether the election community, seemingly well-intentioned developers, and security experts want to believe it or not. Transparency is NOT equivalent to Trust, especially in voting systems. Don't get me wrong, of course I believe that open source is a good thing for many types of applications—voting (especially over the Internet or in fully electronic systems) just is NOT one of these. Sure, all aspects of voting systems must be open to thorough review. But the voting problem CANNOT BE SOLVED using open source. (If this sounds like a contradiction, it is, as I described in my doctoral dissertation, downloadable at <www.notablesoftware.com/evote.html>, because there is an inherent conflict in the ability to create a trusted system that also provides full anonymity.) Our election integrity colleagues must ensure that these points are made whenever they demonstrate vulnerabilities. Anyone who allows voters, election officials, and members of the press to think otherwise is contributing to this outright fraud. Perhaps if the VENDORS are fined $10,000 and threatened with jail sentences, this charade will finally end.
Some voters in Las Vegas have noticed that Democratic Senator Harry Reid's name is checked by default on their electronic voting machines. By way of explanation, the Clark County Registrar says that when voters choose English instead of Spanish, Reid's Republican opponent, Sharron Angle, has her name checked by default. *Slashdot*, 26 Oct 2010 http://bit.ly/cBXWSj [Reid won re-election, perhaps because of the strong Latino vote. PGN]
[David McCandless plotted occurrences of "break up" and "broken up" from 10,000 facebook status updates. The highest peaks were around spring breaks (perhaps he counted items such as "I'm spending my break up in the mountains?" and "I'm all broken up over my bad grades.") and the first few weeks of December. Beware of Breaks-Bearing gifs. PGN] Very interesting that April Fool's day represents a [secondary] peak. I wonder how many of those were actual break-ups. [Source: http://www.dailymail.co.uk/sciencetech/article-1325915]
Neal Ungerleider, How Haystack Risked Exposing Iranian Dissidents, FastCompany.com, 20 Sep 2010 http://www.fastcompany.com/1690075/haystack-austin-heap-iran-fail In 2009, Iran was in turmoil, and the Islamic Republic was blocking and monitoring sites used by opposition groups—until a team led by American IT specialist Austin Heap built a program, Haystack, and touted it as a secure and anonymous Web portal for Iranians. *The Guardian* lauded it, and U.S. Secretary of State Hillary Clinton personally praised Heap. The U.S. government even gave him rare permission to export his cryptological software to Iran. Among an elite group of beta testers—and many more unauthorized users—Haystack was a godsend. Then in Sept. 2010, security experts discovered a problem: Iranian authorities, the very ones Haystack was supposed to circumvent and shield against, were exploiting massive holes in the encryption scheme to snoop on dissidents. [Beware of anonymity-bearing gifts. As we have noted here before, ALWAYS look a gift (trojan) horse in the mouth. PGN]
We see a lot of depressing news reported in RISKS, so I thought I'd share something a bit more upbeat. I monitor some basic statistics about the impact of spam on my personal email server. In particular, I capture the number of spam messages that bogofilter successfully blocks and allows through, and the number of bogus SMTP connections successfully blocked each day by way of the Spamhaus ZEN blocklist on my primary and secondary SMTP servers. For those who are curious, I post graphs of these statistics, updated on a daily basis, at <http://stuff.mit.edu/~jik/#spam>. In the last few months, I've noticed a dramatic decrease in the number of bogus SMTP connections. Today I finally took a few minutes to run the numbers. When looking at a 30-day running average, the number of bogus connections has dropped an astounding 51% since May 14, from 29,184 per day to 14,287! I've posted a graph showing the decline at <http://stuff.mit.edu/~jik/spam.html#20101002>. I surmise that some very significant zombie botnets must have been shut down in the past few months. To whoever is responsible for this: kudos and keep up the good work! There has also been a reduction in the spam that gets through the blocklist, from an average of 168 per day to 132, i.e., a 21% drop. That's significant, but not nearly as dramatic as the decrease in blocked SMTP connections.
The trend in telecommunication to replace traditional phone switches with software-based VoIP systems means that there is a growing market for scanning the Internet for systems on port 5060, breaking in and re-selling phone services through them. An unsuspecting company that recently installed a new VoIP based switch, often with poor default security, suddenly receives a hefty phone bill for calls to (often expensive) numbers. The perpetrators make money by offering these services on the cheap, while their costs are virtually zero. See the ZDnet article for a rise in abuse in Australia: http://www.zdnet.com.au/thousands-lost-in-rising-voip-attacks-339306478.htm There are a number of things to ponder over here: * The vendors possibly ship these systems with a default password, or allow anonymous VoIP registration, so it works 'out of the box'. * The people who install these systems may be coming from a different branch than the system administrators who have had to deal with protecting their servers against the big bad Internet for years.
Spencer E. Ante, *Wall Street Journal*, 5 Nov 2010 A number of top financial companies and banks such as Wells Fargo & Co., Bank of America Corp. and USAA are rushing out updates to fix security flaws in wireless banking applications that could allow a computer criminal to obtain sensitive data like usernames, passwords and financial information. The central problem is that the apps, which run on Apple Inc.'s iPhone and Android-based devices from Google Inc., are storing a user's information in the memory of a cellphone, a basic lapse that the security researcher who found the flaws said could allow a cybercriminal to access a person's financial accounts. The data could be gleaned if a criminal got physical access to the phone. It could also be obtained remotely if an attacker were able to con a user into visiting a malicious website, according to Andrew Hoog, chief investigative officer of viaForensics, a Chicago computer and mobile security firm that discovered the flaws. ... http://online.wsj.com/article/SB10001424052748703805704575594581203248658.html
The iPhone / iPod Touch OS has a "clock" application that can act as a stopwatch, countdown timer, multi-timezone world clock, and daily alarm. (This alarm is distinct from the appointment reminders you can set up with the calendar app.) I have an alarm set to go off at 07:00 on week days. On Sunday when the clocks went back, my iPhone's time display correctly followed the change, and the alarm continued to show the 07:00 setting. However this morning the alarm went off at 08:00. (This wasn't actually a problem since our four-year-old son woke us at about half past six...)
NPR's Planet Money 5 Nov 2010 details a bug on the U.S. Freddie Mac website which refuses to accept an "appreciation rate" for housing which is a negative number. At some point in the last several years, hundreds of trillions of dollars (face value) in derivatives were outstanding based on this same bug, and Ben Bernanke has put the U.S. dollar printing presses into overdrive trying to get the nominal value of home prices up so that people will feel richer & start to spend again. Of course, Ben is p*ssing into the winds of a category V hurricane, but he deserves a Nobel for trying. http://www.npr.org/blogs/money/2010/11/05/131105373/the-friday-podcast-finally-an-apology#more
Interesting piece I heard about on NPR On The Media the other day
(http://www.onthemedia.org/transcripts/2010/10/08/02). A British company is
setting up closed circuit TVs in stores, and then inviting people to sign up
to watch the cameras in real time (four cameras at a time). If you see
something bad (i.e., someone shoplifting), you notify the shopowner via
their site. There's obviously tremendous opportunity for people causing
mischief (i.e., by tagging customers based on appearance), but they seem to
have given consideration to privacy and reliability concerns.
Several interesting things:
- They have a rating system for watchers - if you cause too many false
alarms, you're kicked out.
- Watchers are unpaid (+), although they can get some rewards. They
believe that because people want to reduce crime they'll volunteer
their time. Voyeurism, anyone?
- Watchers can't choose what cameras they see, and are assigned stores
far from where they live (*).
- Shopowners pay about 100 pounds/month for the service (don't know if
that's for one camera or many).
Lots of opportunities for mischief here (e.g., can the cameras be re-aimed,
will shopowners point the cameras at dressing rooms). I can't imagine that
it would be interesting for very long, but perhaps if you're really
bored.... After all, this is what minimum wage rent-a-cops do in shopping
malls.
This is a great example of the risks of technology (Internet & cameras),
combined with people's wanting to help their communities, tempered with a
healthy dose of voyeurism.
http://interneteyes.co.uk/
(+) In fact, they *pay* to register! "Payment of the membership fee
helps prevent misuse of the system and acts as a barrier to entry to
stop voyeurism."
(*) Presuming the watcher gives an accurate home address, one presumes.
The following was just sent to all faculty and staff at the institution where I am teaching (some information removed to protect the guilty): > Student Password Extension > What will happen > All students who were created in [...] before 2006 had > a 6-digit password. For security reasons, we intend to extend all those > students' passwords to 8-digits. After this change is implemented, > those students with 6-digit passwords will have their passwords extended > by two letters—qz. The number of affected students is estimated to be > 2130. (Bear in mind this is not the total number of changes, it is just > the number of students who enrolled this year who have a 6-digit > password.) > Notification > 1. Affected students will be emailed about this change; > 2. A notice will be put on the Student Campus life page; > 3. A notice will be put on the YYY home page; > 4. A notice will be put on the computer logon screens; Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ The "M" in XML stands for *markup*. If you don't have anything outside the angle brackets, you probably shouldn't be using XML.
The BBC web site reports (http://www.bbc.co.uk/news/technology-11654139) that a UK company has "produced software which it said can analyse the pitch, tone and intonation of noises [captured by public CCTV cameras] and work out if they pose a threat". A company spokesman commented: "A certain number of false positives are beneficial so long as you have the security bandwidth to cope with them because you'd rather know about things that you think were an incident than just miss things you failed to be alerted to." It's not made clear in the article whether the firm in question is familiar with Bayes' theorem, or has considered the risk of false positives in jurisdictions where an armed response is likely (or false negatives, in cases where people are being assaulted but calling for help in the wrong tone of voice).
A woman died and and her husband was hospitalized after someone in the house accidentally pressed the "remote-start" button for her car in their garage in Raleigh VA. http://www.wral.com/news/news_briefs/story/8586538/
The life of 20-year-old Emine, and her 24-year-old husband Ramazan Calcoban [with a Turkish equivalent of a cedilla under each c] was pretty much the normal life of any couple in a separation process. After deciding to split up, the two kept having bitter arguments over the cellphone, sending text messages to each other until one day Ramazan wrote [or at least intended to write] "you change the topic every time you run out of arguments." The lack of a single dot over a letter [i]—product of a faulty localization of the cellphone's typing system --caused a chain of events that ended in a violent blood bath. (Warning: offensive language ahead.) http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail The opening picture and caption is horridly insensitive as well. It is a fixed image. [The confusion resulted from the absence of a Turkish character (the "closed i"), which is missing in many Turkish cell phones. The exact misinterpretation was dramatic, and is noted in the cited article. It clearly resulted in serious offense being mistakenly taken by Emine's family, and it proved fatal. PGN]
We all know that walking and texting is a tough combination—but a Staten Island teen learned the hard way when she fell into an uncovered sewer manhole while trying to send a message. Now, the family of Alexa Longueira, 15, intends to sue. The girl suffered a fright and some scrapes on her arms back after she dropped into the hole on Victory Boulevard. http://www.nbcnewyork.com/news/local-beat/Teen-Drops-Into-Sewer-While-Walking-Texting.html
Surgical "wrong site" errors are an old problem. Prior to knee surgery 20 years ago a nurse handed me a marker and asked me to draw an X on the spot. I drew a very large, bold serif X fit for a pirate treasure map. Just to be safe, I wrote "no!" all over the other knee. Most patients choose general anesthesia but I chose a spinal block. I will never forget how the surgical team all laughed when they saw my knees. And there is this: http://www.sciencedaily.com/releases/2008/10/081021185211.htm
Gene Wirchenko forwarded an article from InfoWorld about the problems a Duke University experiment caused by sending BGP advertisements with a valid but unrecognized attribute, triggering a bug in Cisco router code that caused a "partial Internet blackout". I used to work at a company that did network monitoring software. We mainly used SNMP to query devices for their state. We'd regularly run into bugs in SNMP implementations. Some affect only us - e.g., returning ill-formed packets, or properly-formed packets with garbage data. But others did varying degrees of damage, from routers that implemented some queries so inefficiently that if you made them, the routers would become unusable due to the resource requirements of trying to answer you, all the way up to legitimate requests that would cause routers to reset or crash. In many cases, when we investigated we'd find that the bugs were known and had long been fixed by the vendors - but the customer was still running old, unpatched code. Some customers would patch; others viewed this as a "it's working, we're not touching it" situation. Division of responsibility between the group that was monitoring the network and the group that "owned" the devices also factored into this. The device "owners" blamed our software for crashing their devices! We ended up having to avoid some analyses because of the hazards of the queries they required. These routers were typically embedded in enterprise networks, not out on "the greater Internet" - but that's a fluid boundary, since some of them were internal to providers of Internet interconnect services. You as a user couldn't see those devices - but your data flowed through them nonetheless. There's been little published work on the vulnerabilities of Internet infrastructure protocols *as actually implemented on real devices*. I'm sure there are plenty of vulnerabilities to be found. BGP, the particular protocol in question here, is known to have instabilities, and has been implicated in various accidental (or perhaps not?) misconfigurations that have caused wide-spread, problems in recent years. The mentioned article ends with the scary quote: "The days of academics playing with a live network are kind of gone now...." This is a recipe for stagnation - and for hiding, not fixing, significant problems.
Please report problems with the web pages to the maintainer