Home page logo
/

pauldotcom logo PaulDotCom mailing list archives

Finding the common thread...
From: christopher.riley at r-it.at (christopher.riley at r-it.at)
Date: Tue, 16 Jun 2009 10:33:52 +0200

Hi,

Thanks for the reply Jim. I've run the sessionID's through some analysis 
using Burp suites build in tools. The result of this is what led me to my 
current search for further analysis into the way these SessionID's are 
formed. Although 5-10 characters seem short, it still offers a keyspace of 
almost 15,000,000,000

5 char keyspace : 9,765,625
6 char keyspace : 60,466,176
7 char keyspace : 282,475,249
8 char keyspace : 1,073,741,824
9 char keyspace : 3,486,784,401
10 char keyspace : 10,000,000,000

Total keyspace : 14,913,233,275

I've made some checks to see what speed the system can be brute-forced 
(although the keyspace is far to large), and I can check around 65,000 
SID's per hour.

I've looked further into the logs and database and found a couple of 
examples.

06/09 13:56:12.35 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
5218 Session 33A43090 created; session count 23734
06/09 13:56:12.35 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
5218 Session 33A3E480 created; session count 23735
06/09 13:56:12.35 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
5218 Session 33A3B270 created; session count 23736
06/09 13:56:12.72 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
7670 Session 33A43090 (751089885) login by analyst test.rly 
(cnt:23704900D2C3434EB7E0E88A49E9CF8C)
06/09 13:56:12.72 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
7670 Session 33A3E480 (1484604498) login by analyst test.rly 
(cnt:23704900D2C3434EB7E0E88A49E9CF8C)
06/09 13:56:12.72 xxxxxxxx web:local          3776 SIGNIFICANT  ses.c  
7670 Session 33A3B270 (1277527419) login by analyst test.rly 
(cnt:23704900D2C3434EB7E0E88A49E9CF8C)

.. and the session_log entried for the above examples.

SELECT     id, login_time, logout_time, session_id, contact, session_type, 
policy, status
FROM         dbo.session_log
WHERE     (session_id IN (751089885, 1484604498, 1277527419))

id              login_time      logout_time     session_id      contact  
type    policy  status
1277527419      1244548572      1244552172      1277527419      <Binary 
data>   1               0               0
751089885       1244548572      1244552172      751089885       <Binary 
data>   1               0               0
1484604498      1244548572      1244552172      1484604498      <Binary 
data>   1               0               0

This example unfortunately breaks my earlier theory that the session_id 
was based on timestamp (in some way) as the 3 examples above are all 
registered in the log with an identical unix timestamp value of 
1244548572. Still there is some new possible links looking at the HEX 
value noted in the log. Although it doesn't rise by a set amount each 
time, it seems to be a counter of some sort. Looks like it's back to the 
drawing board on this one. Time has run out for me to look further into it 
this week, but I'll have plenty of time next week on my flight to the 
FIRST conference. Guess I'll need another battery for my netbook afterall 
;)

Chris

pauldotcom-bounces at mail.pauldotcom.com () inet wrote on 15.06.2009 14:32:57:

Hi,
You might want to do some statistical analysis on the values for the 
session 
ID. One crude way is to plot session ID over time to see if the value 
always 
ascends and look for other patterns. WebScarab will do this for you 
while you 
run the crawler over a page that sets the session ID.


http://www.owasp.org/index.php/How_to_test_session_identifier_strength_with_WebScarab

5-10 characters does seem very short for a session ID and possible 
within the 
realms of brute-force attacks if you can reduce the keyspace you need to 

search. Can you give an example of what the session IDs looks like?

Regards,
Jim

2009/6/15 <christopher.riley at r-it.at>
As part of some research I'm doing I've started looking at the method 
used to 
create session keys within a custom coded program. As I don't have 
access to 
the source-code (and never likely will) I've been doing my best to 
figure out 
the process from the information I have to hand.

Due to the fact that the session ID's created can never repeat (all 
sessions 
are logged to a SQL database using the session ID as the Primary Key, 
duplicates therefore cause a database error) it seems very possible that 
the 
session ID's are created based on a mathematical formular using the 
timestamp 
as input. By mixing multiple inputs (such as username/password/system 
name 
etc...) the program runs the risk of creating a SessionID that already 
exists.

This is were my problem starts. In order to prove the theory, I need to 
find 
how the timestamp is manipulated to create the SessionID. I have access 
to the
logfile containing 35,000+ valid sessionID's and the timestamp of the 
logon. 
Given these two linked piece of information, what can be done (in a 
automated 
or semi-automated fashion) to find any common threads between these 
values ?

Additional Info .:

The timestamp is a standard unix timestamp. The web-application is C 
based 
(CGI), and the resulting SessionID's vary between 5 and 10 characters in 

length (there is no visual pattern between the length and the 
timestamp).

Any ideas ?

Chris
----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, 
DVR 
0486809, UID ATU 16351908

Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail 
dient 
ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen 
duerfen
ueber dieses Medium nicht ausgetauscht werden. 
Correspondence with above mentioned sender via e-mail is only for 
information 
purposes. This medium may not be used for exchange of legally-binding 
communications.
----------------------------------------


_______________________________________________
Pauldotcom mailing list
Pauldotcom at mail.pauldotcom.com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom at mail.pauldotcom.com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com

----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, DVR 0486809, UID ATU 16351908

Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail dient ausschliesslich Informationszwecken. 
Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden. 
Correspondence with above mentioned sender via e-mail is only for information purposes. This medium may not be used for 
exchange of legally-binding communications.
----------------------------------------



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]