Archive

Archive for August, 2007

Voting Machine Logs + e-Government Laws = No Secrets When Voting

August 23rd, 2007 Comments off

Researchers in the state of Ohio in the United States have discovered that by analyzing the logs produced (by law) from e-voting machines used in certain counties, they can determine the vote(s) each voter made.  Further, the logs, by law, must be produced on demand, as part of our open elections process.


I haven’t read the in-depth reports and analysis.  It appears to me that the manufacturers of the voting machine anticipated the risk of vote correlation with voters and tried to mitigate it by separating the vote log from the voter log.  However they mitigated this very poorly as (1) only one voter can apparently use the machine at a time and (2) every thing the machine does is logged and (3) every log entry is timestamped.  So simply separating the “Voter X logged on” records into one log, and the “Vote cast for candidate Y” records into another log seems to be a pretty naive solution.


I normally try to stay away from politics and commentary on my blog, because I don’t want to alienate anyone.  But this is not a political issue.  Here in the United States we have problems with elections.  It doesn’t matter which party you are in, there are things to be unhappy about.  The machines we have built to make elections easier seem to have made things much harder- from the “hanging chads” we had in the 2000 elections to the current pain we’re having with voting machine certification.


The audit trail problem with voting machines is daunting.  How do you simultaneously accomplish the goals of (1) allowing only authorized individuals to vote (2) exactly once per election, regardless of location (4) the votes cannot be tampered with after being cast (or at least tampering is evident), (5) the votes can be tallied quickly (in a matter of only a few hours, (6) all of these steps can be accomplished in such a way that even if he voter wishes it, the vote cannot be correlated with the voter, and (5) a recount can reproduce all the same results with these same election characteristics (maybe we can relax the time window) without the voters physically being present.


Punch card and optical scan systems opt for auditing the voter before handing them the ballot, and the ballots themselves are the audit trail of the votes (and are not numerically linked with the voter).  These systems would seem to be pretty foolproof but there are systemic problems with both: the hanging chads and butterfly ballot problems were with punch card systems, and optical scan systems in general have a fairly high error rate, and all of these problems are largely due to users who fail to follow instructions which are critical to accurate operation of the machines which tally the votes.


Coupled with the fact that many e-voting systems are getting poor reviews from security researchers, I would be much more comfortable as a voter slowing down on e-voting until we work out the kinks.

Categories: News, Rants Tags:

AT&T Team Up With Apple to Create Large-Scale Log Forwarding System Using Paper & US Postal Service

August 12th, 2007 Comments off
Categories: News, SEM Tags:

Help! Someone has deleted events from my Windows event log!

August 11th, 2007 Comments off

From time to time I hear this, and it usually turns out not to be the case.


I’ll begin with a little background.

First, The eventlog service does not have (and never did have) any public or private API to delete individual events- there is a log clear API but nothing else.  The eventlog team thought about implementing selective delete for Vista (there were some internal groups asking for it) but a lot of us security types yelled at them and nothing came of it.  Logs are logs, not databases- if you want selective delete, export the events you want to a database and have at it.


Second, there is no getting around the 10 Immutable Laws of Security, particularly law #6 (a computer is only as secure as the administrator is trustworthy) and law #2 (if a bad guy can alter the operating system on your computer, it’s not your computer anymore).


What this means is that, no matter if we implemented the most advanced, coolest, 1337est event-signing/real-time-exporting/writing-to-optical-media-and-a-line-printer-too event system, IT DOESN’T MATTER IF THE ATTACKER IS THE ADMINISTRATOR- all we do is reduce the window of time that that person has to do his dirty work.  Now I will admit there is value in those features, but if such an evil person were to use his powers of debugging to open the services.exe process (where eventlog lives) and inject a thread which alters the eventlog data structures in memory in real time, prior to commit to disk, then none of that stuff would help us.  As a matter of fact such tools exist, they are not theoretical.  I haven’t seen the Vista versions yet but there’s no technical reason why such a tool could not be built for Vista.


However, the cases I’ve seen of apparent gaps in event logs have a much more mundane explanation: the “Retain X days” event retention policy.  This is an evil setting; if people truly understood it they wouldn’t use it.  Prepare to truly understand it.


<puts on lab coat>


Imagine you have a finite space S to store resources of type R.  You get a constant incoming stream of R’s, and put each of them into S.  Now imagine that S is full and a new R arrives.  You have two choices:
 
1.       Throw the new R away.
2.       Remove one or more of the old R’s from S (enough so that the new R can fit into S) and put the new R into S.
 
When selecting which old R’s to discard, the generally accepted best practice is that you should throw away the oldest R first- in other words freshness is a priority.  Of course if you wanted to optimize for space you could just pick the smallest old R equal to or larger than the new R, but that would cause ordering problems if you wanted to maintain sequential access.  You could even pick one or more old R’s at random but that would be too arbitrary for most structured purposes like logging.
 
Now imagine that you had an additional constraint: you can throw away old R’s, but only if they’re more than X days old.
 
Now your choices are:
 
1.       Throw the new R away, or
2.       Throw away one or more of the old R’s, if and only if there are enough R’s that are older than X.


If there are no R’s older than X, you may not discard any old R’s and since you have a fixed size buffer S and there is no room for the new R, you MUST choose option 1- throw away the new R.  You have no other choices.
 
This is the situation with event log.  “Retain X days” actually CAUSES event loss (as does “Overwrite as needed“).  However, Overwrite as needed causes predictable event loss (oldest events gone).  Retain X days causes unpredictable event loss (if the log is full and there are no events older than X days, then NEW events are thrown away until there are some events older than X days).

Detecting gaps in your log


Can we detect if someone has deleted events out of your log?


At the end of the day, the event log is an ordered list of data structures (called event records), with each having a pointer to the next.  There is also a unique, monotonically increasing sequence number associated with each event record.


A clever attacker will have disabled the instrumentation that causes the event to be raised; eventlog will never have been involved so there will be no gap (but no event).


A less clever or less resourceful attacker who deletes an event from the log, probably will not go fix up the sequence numbers for the rest of the log (in fact the attacker might not even fix up the pointers, causing the eventlog service to crash or hang).


We can use this priciple to our advantage.  By examining each event and looking at its sequence number, we can look for gaps in the stream and, although we can never be sure that there was no tampering, we can often tell when there was tampering.


Here’s a VBScript that demonstrates this concept.  I don’t provide VBScript support; you’re on your own on this one.



‘EventLogGapDetector.vbs


‘ (c) 2007 Microsoft Corporation, All Rights Reserved



strComputer = “.”


Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\CIMV2”)


Set colItems = objWMIService.ExecQuery( _


    “SELECT * FROM Win32_NTLogEvent “,,48)


 


iPrev = 0


first = true


gapdetected = false


newgapdetected = false


currlogfile = “”


oldlogfile = “”


 


For Each objItem in colItems


    iCurrent =  CInt(objItem.RecordNumber)


    currlogfile = objItem.Logfile


    if ((iCurrent <> (iPrev-1)) and (not (first)) and currlogfile=oldlogfile) then newgapdetected = true


    if (newgapdetected) then Wscript.Echo “Gap detected, log file = ” & currlogfile & “, last record = ” & iPrev & “, current record = ” & objItem.RecordNumber


    if (newgapdetected) then gapdetected = true


    iPrev = CInt(objItem.RecordNumber)


    first = false


    newgapdetected = false


    oldlogfile = currlogfile


Next


 


if not (gapdetected) then Wscript.Echo “No gaps detected.”


 Eric


The information provided in this post is provided “AS-IS” with no warranty, and confers no rights.

Categories: Tips, Tools Tags:

EZ-Pass Logs Used in Divorce Cases

August 11th, 2007 Comments off
Categories: News, privacy Tags:

Enabling debug logging for Claims Aware Applications

August 10th, 2007 No comments

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:adfslogs” />


         </listeners>


      </trace>


    </system.diagnostics>

Enabling debug logging for Claims Aware Applications

August 10th, 2007 No comments

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:\adfs\logs\” />


         </listeners>


      </trace>


    </system.diagnostics>

Enabling debug logging for Claims Aware Applications

August 10th, 2007 No comments

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:\adfs\logs\” />


         </listeners>


      </trace>


    </system.diagnostics>

Enabling debug logging for Claims Aware Applications

August 10th, 2007 No comments

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:\adfs\logs\” />


         </listeners>


      </trace>


    </system.diagnostics>

Enabling debug logging for Claims Aware Applications

August 10th, 2007 Comments off

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:\adfs\logs\” />


         </listeners>


      </trace>


    </system.diagnostics>

Enabling debug logging for Claims Aware Applications

August 10th, 2007 No comments

 


Place the following in your applications web.config file.  Place this after the </system.net> section of the file.


 


 


<system.diagnostics>


      <switches>


        <add name=”WebSsoDebugLevel” value=”15″ />


      </switches>


      <trace autoflush=”true” indentsize=”3″>


         <listeners>


            <add name=”ADFSLogListener” type=”System.Web.Security.SingleSignOn.BoundedSizeLogFileTraceListener, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null” initializeData=”c:adfslogs” />


         </listeners>


      </trace>


    </system.diagnostics>