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. ----------------------------------------
Current thread:
- Cool things to inject via XSS Adrian Crenshaw (May 28)
- Cool things to inject via XSS Michael McGrew (May 28)
- Cool things to inject via XSS Jim Halfpenny (May 28)
- Cool things to inject via XSS christopher.riley at r-it.at (May 29)
- Cool things to inject via XSS Michael Douglas (May 29)
- Cool things to inject via XSS packetjack (May 29)
- Cool things to inject via XSS Adrian Crenshaw (May 29)
- Cool things to inject via XSS Robin Wood (May 30)
- Finding the common thread... christopher.riley at r-it.at (Jun 15)
- Finding the common thread... Jim Halfpenny (Jun 15)
- Finding the common thread... christopher.riley at r-it.at (Jun 16)
- Cool things to inject via XSS Michael Douglas (May 29)