Tải bản đầy đủ - 0 (trang)
6  Analyzing Session Randomness with WebScarab

6  Analyzing Session Randomness with WebScarab

Tải bản đầy đủ - 0trang

Figure 11-10. Finding Set-Cookie headers with WebScarab



Select the Summary pane in WebScarab and look in the Set-Cookie column. Figure 11-10 shows this summary pane. Request ID 9 is highlighted because it is one of

many that have cookies. We will use this request as our request to analyze.

Select WebScarab’s “SessionID Analysis” pane and look at the “Collection” tab within

that pane. Click the drop down next to “Previous Requests” and select the request that

will set the session ID. Figure 11-11 shows the list, with request 9 selected. Once you’ve

selected an appropriate request, press the Test button. This will bring up a message

indicating all the session IDs WebScarab was able to find automatically within that

request. Figure 11-12 shows the result of such a test. Two cookies are visible in this

Set-Cookie header: phpMyAdmin and pma_fontsize. The fact that the contents of phpMyAd

min are opaque strings like z316wV-lrq0w%2C-8lPF6-uvObKdf and the fact that the other

parameter’s name suggests that it controls font size leads us to focus on phpMyAdmin.

Once you’ve found an appropriate session ID to model, enter a sample size. We recommend at least 500 or more for a smooth graph. It’s better to do 1,000 or 2,000 if you

can. Then click the Fetch button to initiate the requests. Each will receive a different

session identifier.

To see the graph, you must first go to the Analysis tab and select the session identifier

you’d like to visualize. Figure 11-13 shows the Analysis tab, with our phpMyAdmin cookie

selected. Select that from the drop down options. There may be only one session identifier available; that’s fine. With your session identifier set, click on the Visualization

tab. If WebScarab is still fetching session identifiers, you’ll see them show up in real

time on this graph—a powerful demonstration in itself. Furthermore, there should be

no obvious pattern in the visualization graph. If there is, it’s likely the session identifiers

are easily predictable.

228 | Chapter 11: Manipulating Sessions



Figure 11-11. Selecting the request to test for session IDs



Figure 11-12. Testing a request for session IDs



Discussion

WebScarab’s analysis of session identifiers, while statistically weaker than Burp’s, provides a much more convincing diagram. Some patterns are readily apparent in the graph

of session identifiers over time. Figure 11-14 shows a real web server that has relatively

predictable identifiers. They’re not as bad as sequentially issued integers, but with some

effort a hacker could develop a program to predict them. This sort of graph can provide

the extra step you need to demonstrate predictability. A clearly visible pattern makes

a stronger impression than statistical confidence intervals.



11.6 Analyzing Session Randomness with WebScarab | 229



Figure 11-13. Choosing the session ID to plot



Figure 11-14. WebScarab visualization: relatively predictable



Consider the ten session IDs shown in Example 11-2. Visually inspecting them, you

might think they were pretty random. Aside from the LL6H at the beginning of each,

they are very long and they appear to have lots of randomness. They are from the same

site that produced the graph in Figure 11-14, however, which shows how a little visualization can go a long way towards making the pattern clear.

Example 11-2. Session IDs from WebScarab

LL6HZFzp1hpqSHWmC7Y81GLgtwBpx48QdhLT8syQ2fhmysyLcsGD

LL6H77rzbWlFLwwtnWhJgSxpZvkJvLWRy1lykQGvZh33VGJyvf9N

LL6H99QLLvB8STxLLbG9K7GQy1tncyYr6JSGYpCH4n29TTg1vcMZ

LL6HynM9MDj0WQGmTDhKPsvJnbGZhL2SSqBH78bYF2WxSs1kJ3nx

LL6HgMSCpHQH8LJjhbyfg47W5DN2y55SKSbSQM2GcTntSLmL1PHJ

LL6H1m8nLPpzyJylv0m21Znd8v7F1DNT2tDN2FZd0bXHVjVnhcB9

LL6LTMsy8lxfVyn86cZBp6qS3TLMDhfXB83x0Lx8cPCG6f0bzwGw

LL6H4n3G8QBQYWpvdzM8vsBzfyzdQPM6J4HMflZscvB4KDjlQGGT



230 | Chapter 11: Manipulating Sessions



LL6L4qPHk0PJ92svGQQtvGpd6BG12hqhmRnchLpTy31B08kMkflM

LL6L2TGwrW8XTp206r2CpQXS7LDh5KjkSs7yfW1wbv2GwD20TByG



Clear lines or shapes within the graph indicate poor randomization. When testing an

application, it’s easy to get pseudorandom results and not see an obvious pattern. Laying out the results in such a graph reveals some (but not all) patterns immediately. Truly

comprehensive analysis requires statistical analysis, such as the methods used by Burp.

Note that WebScarab will find all sorts of identifiers inside cookies, not just session

identifiers. It may also find non-random identifiers that record visitor details. Not every

cookie value needs to be random. Don’t be alarmed if one of the identifiers you select

for visualization is a flat, completely predictable line. It may just be a non-unique token,

rather than a session identifier.

That said, some applications will implement multiple session identifiers to track different behaviors. If you do find an alternate pseudosession identifier, such as “visitor

number,” go ahead and examine the predictability. It may be that by tampering with

some other identifier, one is able to trick the application into doing something nonsession related, but still just as problematic.

Figure 11-15 shows an example of a session identifier that does not appear, visually, to

be predictable. Remember that your application can fail this test, but cannot pass it.

That is, just because your session IDs are not obviously predictable from visual inspection doesn’t mean they’re random. If you are very concerned about them, perform

statistical analysis such as we discuss in Recipe 11.5.



Figure 11-15. WebScarab visualization: unpredictable



11.6 Analyzing Session Randomness with WebScarab | 231



Figure 11-16. Deleting cookies



11.7 Changing Sessions to Evade Restrictions

Problem

As discussed in Recipes 9.8 and 9.10, some applications will prevent attackers from

frequently accessing a form or page. One of the ways to bypass these protections is to

frequently request new session identifiers so that the attacker appears as many new

users rather than a single malicious user.



Solution

This recipe only applies if your application prevents an attacker from attempting to

guess or sequentially attempt passwords, identifiers, or credentials. Determine whether

or not your application meets these criteria via Recipe 9.8.

Once you’ve identified an area where your application restricts multiple requests, go

ahead and initiate as many requests as you can. Once you’re finished, you should now

be locked out or otherwise prevented from trying again. At this point, open up Edit

Cookies, filter by your current domain, select at least one cookie for your domain, and

click the Delete button. Edit Cookies, by default, will ask you if you’d like to Delete or

Cancel—but notice that there’s another option there, the Delete All option. Figure 11-16 shows the delete options. Click the Delete All option to erase all cookies, and

hopefully all sessions, for your domain.



232 | Chapter 11: Manipulating Sessions



With the sessions gone, you should now be able to attempt the previously blocked

actions again. If you repeat them enough and get blocked again, simply delete the

cookies again to continue.



Discussion

This ability to bypass detection and restrictions this way poses a difficult problem—

how can one prevent repeated attempts? It turns out this is a very difficult problem.

Tracking malicious attackers by IP address is a start—except that some users share IP

addresses (think public wireless access points) and some attackers have access to many

IP addresses (via a botnet). Server-side sessions aren’t safe, as cookies can be deleted

at any time. Client-side sessions aren’t safe, as the client is completely controlled by

the attacker anyway. Unfortunately, it appears that one can’t stop an attacker from

trying, one can only slow them down. On the plus side, done well, one can slow an

attacker down enough that cracking a password or credential should take a few years!



11.8 Impersonating Another User

Problem

If at this point you’re wondering what tests to apply when your application doesn’t use

a session identifier, but instead relies on keeping the username in cookies, then this is

the recipe for you. If your cookies contain any information about usernames and passwords, access permissions, or other authentication and authorization details, this can

lead to trouble.



Solution

Via Edit Cookies, identify the authentication or authorization details being stored in

cookies. You may need to decode these details, using techniques found in Chapter 4.

We’ll go through the ramifications of each type of stored detail one by one:

Username only

If once the user logs in, only the username is stored in order to identify which user

is which, then any user may impersonate any other user. To do so, you would open

up Edit Cookies and modify the username cookie to contain another user’s username. The next time you browse to the application, the application will mis-identify you, allowing you to impersonate the other user.

Username and password

When the username and password are stored and checked together, an attacker

can brute-force passwords at a rapid speed. To break into an account, the attacker

sets up the cookies to contain the username and then rapidly iterates through new

password cookies. Using some of the Perl techniques described in Chapter 8, an



11.8 Impersonating Another User | 233



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

6  Analyzing Session Randomness with WebScarab

Tải bản đầy đủ ngay(0 tr)

×