Re: swc / ActivCard

[Ross Thompson <ross () WHATSIS COM>]

Doh!  I can't believe I did that.  Anyway, if anyone cares,
the fix is available in the 1.2 release of SWC.

--

Standard disclaimer: this material contains my personal
oppinions and
beliefs ONLY. It has nothing to do with my employer /
company. I am
writing it as a private person. It doesn't have to be
upright, nor doesn't
even pretend to provide objective / useful information. All
statements
should be verified before claiming they are true. I can't
and will not
take any responsibility for any use / misuse of this
information, nor any
kind of damage / loss caused by any interpretation of it.

--

First of all, something light:

   Simple Web Counter, quite popular cgi application
(distributed eg. on
   Linuxberg ftp) written by Ross Thompson, is vulnerable to
stack buffer
   overflow when parsing ctr= parameter. Considered
exploitable, exposes
   some ISP servers.

Then, something more juicy:

   Some time ago, we performed brief, comparative analysis
of one-time
   passphrases returned by different tokens (SecurID and
ActivCard,
   mainly) in short time periods (collecting successive
one-time
   passwords returned by token).

   In ActivCard's case, we discovered something at least
alarming.
   Before continuing, please note - although we tried to
collect
   the most accurate and representative data and provide
objective
   and realible informations, there's a chance we've made
some mistakes.

   -- IMPORTANT STATEMENT --

   Thus, please threat this message as an attempt to start
futher, more
   complete analysis *ONLY*. You shouldn't trust these
statements
   before making sure they're true - and we can't take *ANY*
kind of
   responsibility they are.

   -- END OF IMPORTANT STATEMENT --

   Theoretically, default ActivCard 8-digit display can
handle up to
   100,000,000 combinations.

   First, while analysing output returned by different
tokens kindly
   provided to us, we thought ActivCard uses alarmingly
small (within
   around 1-2% of possible number space), but random
positive increments in
   random length sequences. For example:

                                            .
   05314080                                 .
   06401172     < increment around 1.1M     : --- sequence
of increments
   07332504     < increment around 0.9M     |
   08957912     < increment around 1.6M     |
   09134516     < increment around 0.2M    /
   00104910     < large decrement
   ...                                     \
                                            :
                                            .

   But that was only the first impression. We visualised
output presented
   by tokens, and found it isn't looking really random:

   By calculating first derivate of collected values (over
100 samples),
   we discovered these increments are determined by simple
functions,
   that looks pretty deterministic and periodic. For
example, one of them
   (partially responsible for that huge decrements) has
simple cycle of
   10). You can see it on graphics generated by our sample
program (see
   below) as green peaks below X axis.

   To make sure we're not studying some rare set of
conditions, we checked
   some other tokens, with different PIN codes. I guess all
of them were
   previously synchronized to same server (most of them lost
   synchronisation in the meantime), that's why I'm asking
other people to
   collect some information and try to verify these
observatios.

   I included simple code to visualise one of our sample
data portions. It
   should work on Linux/BSD box with svgalib installed:

   # gcc -lvga -lm vis.c -o vis
   # ./vis <DATA.in

   Actually, I guess you can use any other program, like
gnuplot,
   Derive, Mathematica and so on to perform visualisation.

   Dark blue lines are discrete measurement points. White
line connects
   values in these points, while green line shows delta
(increments
   between previous and current value).

   Consequences?

   It make us think that it's quite easy to predict, at
least in short
   term. It means, attacker, by intercepting short sequence
of one-time
   passwords, can easily (at least with reasonable
probability)
   predict next password, and enter it to obtain access to
protected
   systems.

   Predictability of passwords is definetely against idea of
such tokens.
   Of course, very often ability to sniff password means
ability to
   intercept session, but by making such assumption in order
to justify
   predictable output, we have to ask if we need such tokens
at all,
   instead of static passwords?;)

   Even basing on our rough estimations and basic analysis,
we were able
   to guess next number with about 35% chance within 100
attempts -
   while, if returned values meant to be indeterministic,
this chance
   should be equal to 0.00001%. I guess in-depth analysis
might
   expose more details about ActivCard algorithm - or prove
we've made
   a mistake.

_______________________________________________________
Michal Zalewski <A
HREF="mailto:[lcamtuf () tpi pl">[lcamtuf () tpi pl</A>]
[tp.internet/security]
[<A TARGET=nonlocal
HREF="/external/http://lcamtuf.na.export.pl]";>http://lcamtuf.na.export.pl]</A>
<=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

09572551
00104240
01514414
02196882
03131096
04438710
05314080
06401172
07332504
08957912
09134516
00104910
11410212
12320094
13451015
14815068
15957120
16331853
17315753
28059137
29150065
20144503
21418313
22541446
33154128
34152593
35234321
36420570
37068752
38222590
39125420
30906813
31443251
32383152
33452316
34311091
35375911
46144311
47539023
48603305
49230054
40643056
41343033
42843384
43341525
44004457
45404344
56915133
57352943
58240383
59541235
50608121
51110865
52311423
53186372
54510387
55320433
56050071
57634824
58517427
69459494
60693981
61512431
62335722
63051065
64313656
65145052
66496579
67099691
68422994
69138453
60524092
61734109
72512202
73230336
74852712
75106735
76353115
77224433
78541384
79479019
70373140
71120125
72061434
83180539
84252526
85400628
86448142
97511746
98474588
99331497
90220911
91467041
92013270
93260185
94325202
95843330
96908704
97805154
98740079
09559630
00856478
01569205
02350566
03130803

// gcc -lvga -lm ...
// (C) 2000 Michal Zalewski <<A
HREF="mailto:lcamtuf () tpi pl">lcamtuf () tpi pl</A>>

// ./a.out <DATA.in

#include <vga.h>
#include <math.h>

int dupa[100];
int cnt,i;
double lx,ly;

int scale;

int ZOOM=100000000;
char buf[1000];
char* x;
int SCALE;

main(int argc,char* argv[]) {
  if (argc==2) ZOOM=atoi(argv[1]);
  while (gets(buf)) {
    x=buf;
    while (*x=='0') x++;
    sscanf(x,"%d",&dupa[cnt++]);
  }
  SCALE=640/cnt;
  if (!SCALE) SCALE=1;
  vga_setmode(G640x480x16);
  vga_clear();
  vga_setcolor(13);
  vga_drawline(0,240,640,240);
  vga_setcolor(1);
  for (i=0;i<cnt*SCALE;i+=SCALE) {
    vga_drawline(i,0,i,480);
  }
  vga_setcolor(15);
  for (i=0;i<cnt;i++) {
   if (i)
vga_drawline(lx,ly,SCALE*i,240-(int)(((double)dupa[i])*240.0/ZOOM));  
   lx=SCALE*i;
   ly=240-(int)(((double)dupa[i])*240.0/ZOOM);
  }

  for (i=cnt;i>1;--i) dupa[i]=dupa[i]-dupa[i-1];
  vga_setcolor(10);

  for (i=0;i<cnt;i++) {
   if (i)
vga_drawline(lx,ly,SCALE*i,240-(int)(((double)dupa[i])*240.0/ZOOM));  
   lx=SCALE*i;
   ly=240-(int)(((double)dupa[i])*240.0/ZOOM);
  }


  sleep(1000);
  vga_setmode(TEXT);
}