OTG-SESS-001 (세션 관리 스키마 우회 테스트)


개요

각각의 웹 페이지 또는 서비스에 계속적인 인증을 피하기 위해, 웹 어플리케이션은 정의된 시간 범위 동안 자격 증명을 저장하고 유효하게 하기 위해 다양한 메카니즘을 구현합니다.

쿠키 메카니즘은 세션 관리로 알려져있는데, 해당 메카니즘은 애플리케이션 사용자 편의성과 사용의 용이성을 증가시키기 위해선 중요하지만, 침투 테스터에게 정확한 인증 정보를 제공할 필요없이 사용자 계정 액세스에 이용 될 수 있습니다. 해당 테스트에서, 테스터는 쿠키와 다른 세션 토큰이 보안과 예측할 수 없는 방법으로 생성되었는 지 확인하길 원합니다.

취약한 쿠키를 예측하고 위조할 수 있는 공격자는 합법 사용자 세션을 쉽게 하이재킹할 수 있습니다. 쿠키는 세션 관리를 구현하기위해 사용되고 RFC 2965에 자세하게 설명되어 있습니다.

In a nutshell, when a user accesses an application which needs to keep track of the actions and identity of that user across multiple requests, a cookie (or cookies) is generated by the server and sent to the client.

The client will then send the cookie back to the server in all following connections until the cookie expires or is destroyed. The data stored in the cookie can provide to the server a large spectrum of information about who the user is, what actions he has performed so far, what his preferences are, etc. therefore providing a state to a stateless protocol like HTTP. A typical example is provided by an online shopping cart. Throughout the session of a user, the application must keep track of his identity, his profile, the products that he has chosen to buy, the quantity, the individual prices, the discounts, etc. Cookies are an efficient way to store and pass this information back and forth (other methods are URL parameters and hidden fields). Due to the importance of the data that they store, cookies are there fore vital in the overall security of the application. Being able to tamper with cookies may result in hijacking the sessions of legitimate users, gaining higher privileges in an active session, and in general influencing the operations of the application in an unauthorized way. In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. The overall goal is to be able to forge a cookie that will be considered valid by the application and that will provide some kind of unauthorized access (session hijacking, privilege escalation, ...). Usually the main steps of the attack pattern are the following:

  • cookie collection: collection of a sufficient number of cookie samples;
  • cookie reverse engineering: analysis of the cookie generation algorithm;
  • cookie manipulation: forging of a valid cookie in order to perform the attack.

This last step might require a large number of attempts, depending on how the cookie is created (cookie brute-force attack). Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application and possibly injecting (and remotely executing) malicious code.


테스트 방법

Black Box Testing and Examples

클라이언트와 어플리케이션 사이의 모든 상호 작용은 적어도 다음의 기준에 따라 테스트되어야 합니다.

  • 모든 Set-Cookie가 Secure와 같이 태그된 지시어 입니까?
  • 모든 쿠키 작업은 암호화되지 않은 전송을 통해 이루어집니까?
  • 쿠키는 강제로 암호화되지 않은 전송을 할 수 있습니까?
  • 그렇다면, 어떻게 어플리케이션이 보안을 유지합니까?
  • 모든 쿠키가 영구적입니까?
  • Expires= times이 영구적인 쿠키로 사용됩니까? 그 이유가 있습니까?
  • 일시적으로 설정되어 있는 것으로 예상되는 쿠키 입니까?
  • HTTP/1.1 Cache-Control 설정이 쿠키를 보호하기 위해 사용되는 것은 무엇입니까?
  • HTTP/1.0 Cache-Control 설정이 쿠키를 보호하기 위해 사용되는 것은 무엇입니까?

쿠키 수집

쿠키 조작을 해야하는 첫번째 단계는 어플리케이션이 쿠키를 생성하고 관리하는 방법을 이해해야 합니다. 이 작업을 위해, 테스터는 다음 질문에 대답해야 합니다.

  • 어플리케이션에서 얼마나 많은 쿠키가 사용됩니까?

어플리케이션 서핑. 쿠키가 생성될 때 기록. 수신한 쿠키, 쿠키들이 설정된 페이지, 쿠키가 유효한 도메인, 쿠키값, 쿠키 특징 리스트 작성 - 어플리케이션의 어떤 부분이 쿠키가 생성되는지 수정되는지? 어플리케이션 서핑, 쿠키가 계속 남아있는 것과 수정되는 것을 찾기. - 어플리케이션의 어떤 부분이 접근 및 활용하기 위해 쿠키로 필요한지? 어플리케이션의 어떤 부분이 쿠키가 필요한지 찾습니다. 페이지에 접근하고, 쿠키없이 다시 접근해보거나 그 값을 수정하여 접근해봅니다. 여기서 사용되는 쿠키를 매핑해야 합니다. 해당 어플리케이션 부분과 연관 정보에 각 쿠키를 매핑하는 스프레드 시트는 과정의 중요한 출력을 할 수 있습니다.


세션 분석

세션 토큰(쿠키, 세션ID, 숨겨진 필드) 자체가 보안의 관점에서 품질을 보장하기 위해 검사해야 합니다. 세션은 랜덤성, 고유성, 통계 및 암호 분석 및 정보 유출에 대한 정항과 같은 기준에 대응하여 테스트 해야합니다.

  • 토큰 구조 및 정보 유출

첫번째 스테이지는 어플리케이션에서 제공하는 세션 ID 내용과 구조를 검사하는 것입니다. 일반적인 실수는 일반적인 값을 발행하고 서버측에 있는 실제 데이터를 참조하는 것 대신에 토큰에 특정 데이터를 포함하는 것입니다. 만약 Session ID가 평문이라면, 구조와 관련 데이터는 다음과 같을 수 있습니다.

http://foo.bar/showImage?img=img00011

일부 또는 전체 토큰이 암호화 또는 해싱되었다면, 확실하게 난독화되었는지 확인하기 위한 다양한 기술을 비교합니다. 예를 들어 문자 "192.168.100.1:owaspuser:password:15:58"을 Hex, Base64, MD5 해쉬로 표현하면 아래와 같습니다.

Hex         3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64      MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5         01c2fc4f0a817afd8366689bd29dd40a

난독화 유형을 식별하는 경우, 원본 데이터를 디코딩하는 것이 가능할 수 있습니다. 그러나 대부분의 경우는 어렵습니다.

그럼에도 불구하고, 메시지의 포맷 대신에 인코딩을 리스트화 하는 것이 더 유용 할 수 있습니다. 또한, 기술 형태와 난독화 둘다 추론할 수 있기 때문에, 자동 무차별 대입 공격을 할 수 있을 것입니다. 하이브리드 토큰은 다음과 같이 인코딩된 부분과 함께 IP 주소 또는 사용자 ID 등의 정보를 포함 할 수 있습니다.

owaspuser:192.168.100.1:
a7656fafe94dae72b1e1487670148412

단일 세션 토큰을 분석하는 데, 대표적인 샘플을 검사해야 합니다. 토큰의 간단한 분석은 즉시 명백한 패턴을 공개합니다. 예를 들어, 32 비트 토큰은 정적 데이터 16 비트와 가변 데이터의 16 비트를 포함 할 수 있습니다. 이는 처음 16 비트가 사용자의 고정된 속성을 표시하는 것을 나타낼 수있다

– 예제. 사용자명 또는 IP 주소

If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples. If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token. The following areas should be addressed during the single and multiple Session ID structure testing:

  • Session ID의 어떤 부분이 정적입니까?
  • Session ID의 어떤 평문 기밀 정보가 저장되어 있습니까? (예제. usernames/UID, IP 주소)
  • 쉽게 디코드되는 기밀 정보는 어떻게 저장되어 있습니까?
  • Session ID의 구조로 부터 추론할 수 있는 정보가 무엇입니까?
  • Session ID의 어떤 부분이 조건에서 동일한 로그로 정적입니까?
  • 전체 또는 개인 부분으로 Session ID에 표현되는 명백한 패턴이 무엇입니까?

Session ID 예측 가능성과 랜덤성

Session ID의 변수 부분의 분석은 모든 패턴 인식 또는 예측 존재를 확인하기 위해 수행되어어야 합니다.

이러한 분석은 수동으로 뿐만 아니라 Session ID의 내용에 모든 패턴 추론을 위한 맞춤형 또는 OTS 통계 또는 암호 해독 툴로 수행될 수있다.

Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed. Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable. In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.

  • Are the Session IDs provably random in nature? Can the resulting values be reproduced?
  • Do the same input conditions produce the same ID on a subsequent run?
  • Are the Session IDs provably resistant to statistical or cryptanalysis?
  • What elements of the Session IDs are time-linked?
  • What portions of the Session IDs are predictable?
  • Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?

Brute Force Attacks

Brute force attacks inevitably lead on from questions relating to predictability and randomness. The variance within the Session IDs must be considered together with application session duration and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher. A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.

  • How long would a brute-force attack on all possible Session IDs

take? - Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span? - Do delays between connection attempts with different Session IDs mitigate the risk of this attack?


Gray Box testing and example

만약 테스터가 세션 관리 스키마 구현에 접근된다면, 다음을 확인할 수 있습니다.

  • Random Session Token

The Session ID or Cookie issued to the client should not be easily pre dictable (don’t use linear algorithms based on predictable variables such as the client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).

  • Token length

Session ID will be at least 50 characters length.

  • Session Time-out

Session token should have a defined time-out (it depends on the criticality of the application managed data)

  • Cookie configuration:
  • non-persistent: only RAM memory
  • secure (set only on HTTPS channel):

Set Cookie: cookie=data; path=/; domain=.aaa.it; secure

  • HTTPOnly (not readable by a script):

Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly More information here: Testing for cookies attributes


Tools


References

Whitepapers