Bugtraq mailing list archives
Re: swc / ActivCard
From: Ross Thompson <ross () WHATSIS COM>
Date: Tue, 22 Aug 2000 16:08:46 -0000
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); }
Current thread:
- Re: swc / ActivCard, (continued)
- Re: swc / ActivCard Alan DeKok (Aug 18)
- Re: swc / ActivCard John Fulmer (Aug 21)
- Re: swc / ActivCard Alan DeKok (Aug 21)
- Re: swc / ActivCard Michal Zalewski (Aug 21)
- Re: swc / ActivCard Vin McLellan (Aug 23)
- Re: swc / ActivCard Michal Zalewski (Aug 23)
- Re: swc / ActivCard Alan DeKok (Aug 25)
- Re: swc / ActivCard Michal Zalewski (Aug 25)
- Re: swc / ActivCard Michal Zalewski (Aug 25)
- Re: swc / ActivCard Alan DeKok (Aug 18)
- Re: swc / ActivCard Steve VanDevender (Aug 25)