Newsgroup: it.comp.lang.visual-basic
Titolo: Urgent VB question related to protecting elections - time sensitive

Folks,
On Sept. 12th I will be an official elections monitor in a county that
runs Diebold voting products.  The Diebold central tabulator is a box
running Win2k and with a central database of votes in MS-Access I kid
you not.  Diebold's "GEMS" application hits the MS-JET database engine
and then on to the database...which is of course laughably easy to hack
because those idiots put all of the username/password security out in
"GEMS" (Global Election Management Software).
So if you get to the database via a copy of MS-Access 2000 or greater,
all security evaporates.  You can edit the audit log, hack votes, flip
candidate ID numbers, do whatever you want.
Making sure MS-Access ain't on there is easy.  Making sure no automated
Visual Basic attack scripts are present is a lot tougher but I've got
to at least try.
I'm pretty geeky but no code jockey.  I do know that Diebold doesn't
ship any VB scripts themselves so if there's ANY it's suspect and we
can take a closer look.
Bad news one: the extension doesn't necessarily have to be .VBS, as I
suspect y'all know.
Bad news two: in looking over a dozen different VB script files of
random sorts I can't readily identify a text string that I could do a
global search for that would expose all VB script files present on the
system.  Some languages you can, but apparantly not VB unless I'm
missing something?
So that leaves one possibility I can see: identify some unique text
string that would be needed to get to an Access database - something
specific in VB that would make calls to Jet or otherwise touch a
database.  If there's any such thing.  Worst case if there's two or
three possibilities, it's manageable, more than that and we're screwed,
no time available to let half a dozen disk searches run.
And yeah, I know that leaves compiled code or something merged with an
OS component.  Dammit.  I'll have to assume the attacker isn't that
smart...bad assumption, I know, except that the most likely assailant
is somebody in the county government and y'all know government
employees :).  Problem is, the test labs supposed to be checking these
turkeys out didn't provide hashes or checksums for the "Commercial Off
The Shelf" operating system components.  Can you say "rookit!"?
(The other main threat is people within Diebold but damned if I know
what can be done there.  Let's not even start with the five convicted
felons in their management history...)
Any help with a way to identify rogue uncompiled VB script text
welcome.  If you're in the USofA, your butt is on the line here too.
(Hell, you want honest elections in the US no matter WHERE you
live...some panicky Iranian is prolly gonna respond to this <grin!>.)
(Yes, we're going to try to hand-count some ballots to establish
baselines and such, but where the absentee vote is concerned (50% of
the total or so) that won't work.  See, Diebold's absentee ballot
scanners don't independently record what votes were cast through it -
they just dump the data up to GEMS across a serial port.  And since the
absentee ballots aren't sorted by precinct, just thrown into a giant
pile, no comparison between the paper record and the GEMS database is
possible without counting ALL of it - and the new AZ handcount law is
limited to a few percent of the total.  So the ballots you'd think
would be safest, the absentees with hard copy by the voter, are in fact
the most vulnerable because they can be tampered with in
MS-Access/VB/etc and not get checked.  Siiigh.)
Jim March - jmarch at prodigy dot net
Member of the Board of Directors,
http://blackboxvoting.org

 wrote in message
news:1157233189.2...@e3g2000cwe.googlegroups.com...


It is actually worse than that. If the database file (.mdb) isn't
specifically encrypted (a database password merely locks the data file to
other MSAccess) any file open/read or editor program can 'massage' an .mdb
file.
If an attacker knows even part of the DDL or the layout of a few interesting
tables, they wouldn't have to mess with a script, any newbie can write file
i/o in a host of languages. (Its in chapter 3 of every beginner's book
written. <g>)
As for unique "embedded strings" I wouldn't count on it. Everyone now days
knows to store data (eg, file, column, field names) encrypted and provide a
decryption routine for runtime. (most are not very sophisticated, often just
simple substitution, they don't have to be).
Frankly from what you described, if anyone is seriously interested in
mucking with the data - you're screwed.
Good Luck.
-ralph

 wrote in message
news:1157233189.2...@e3g2000cwe.googlegroups.com...
[SNIP]
All databases are vulnerable unless you encrypt the data on input then
decrypt on retrieval. Even then, some smart-aleck can still pull the pin on
the database formatting. Assymetric encryption is also vulnerable to anyone
with access to government cracking software (Especially UK, Israel, probably
Australia, maybe the USA).
In any case, your only security option is to keep people out of your
hardware.
If the voting is done by terminal, then remove all access to data inputs at
these terminals such as USB ports, CD/DVD drives, floppy disks and restrict
the software at these terminals to bare bones OS, no internet access, and
the posting program. Have the software post by shielded cable to a server
controlled and monitored at all times throughout the election. This server
then forwards the votes down a shielded cable to a storage server that has
no other connectivity. The cable could be shielded USB, shileded serial, or
shielded parallel with transfer software, and the storage server should be
housed in a faraday cage. Lining the room with chicken wire (Floor, ceiling,
and all four walls, doors and windows), will generally keep the
electromagnetic hackers at bay.
The key to security is first closing the gaps in your hardware terrain, then
controlling the narrowest gaps in your software terrain - enough to close
out the system...
I hope this helps...
-- 
Timothy Casey GPEMC! >> 11950 is the 
num...@fieldcraft.biz
 2email
          Terms & conditions apply.  See 
www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ 
www.fieldcraft.biz

All of the replies so far have been depressing but likely accurate.
Sigh.
On election day votes are taking at precincts on standalone machines
that write to memory cards, either PCMCIA on the Diebold touchscreens
or at the optical scanner stations a weird "ancestor to the PCMCIA"
card that very few companies still use.  At the end of the day these
things modem results in to the central tabulator via a hacked up MS
Remote Access Diebold brewed up.  SIGH!  So anybody who knows the
incoming phone number (Diebold techs in some cases, not in others) can
jack in to the central tabulator during the two to three hour window
after the polls close when the incoming modem bank is turned on.
Grrrrr.
OK.
The biggest single threat still involves some jerk with insider access
to the central tabulator station doing a VB script or similar.  If we
assume a VERY low expertise level on the part of the hacker, as in
"borderline incompetent", can we at least look for evidence of VB
scripting language floating around in text files with extensions other
than "VBS"?

 extensions other than "VBS"?
Well, if you can scan the machine's files you can do a couple of things.
I would compile a list of keywords used in VBS, and remove from the list most of the common English words like "for", "if" and "then". I would add to this list of tokens the math and comparison symbols like / + = and so on. Unfortunately one of the good things about Basic is that it uses English-like terms and syntax, but there's still enough to make it stand out from plain text.
I would first score each file to see if it's text. Our Stamina library has a function that does this by counting all the characters in either the entire file, or the first 4K, and computing the percentage that are 'printable'. A score below 95 almost guarantees that it is not a text file. This is fairly simple to do in pure VB as well.
If a file passes this test, I would scan it for anything from the list of tokens above, with the list in order of most unlikely first. Anything with a high score or lots of symbols would be a candidate for further inspection. A little history would allow you to refine the list of tokens and get you very close to an automated solution.
-- 
    Jim Mack
    MicroDexterity Inc
 
www.microdexterity.com

     
www.microdexterity.com
Sounds like great advice, BUT: I can't load any new code onto the
central tabulator.  All of the tools available to me have to be what's
in a stock copy of Windows 2000.  So I can't add in a "function from
your stamina library" (SIGH).  I can write a batch file, in fact that's
the one "programming type" I was pretty damn good at "back in the day",
but...I can't see how to parse this from a DOS command line with just
the stock OS components.
Well...wait.  MAYBE in this one county...I can get some custom code
done to scan.  This county which I won't name yet has hired a computer
science professor adviser already, who at first was firmly on the side
of using this crap but has been swinging around our way.
So...maybe, MAYBE I can get him to write up a routine that looks for
VBSish stuff and certify under oath that the code he wrote is "clean".
It would still be *illegal* to load it on that box but I think under
the circumstances everybody might look the other way.  Maybe.
Jim March