Race Condition

Race Condition 이란?

상황 하나를 가정해보자. num이라는 하나의 메모리에 5를 넣고, Process1은 해당 메모리에 1 더하기, Process2는 1 빼기를 진행 한다. 만일 두 프로세스가 동시에 num 메모리에 접근한다면 결과가 어떻게 될까? 5라는 값을 1더하고 1빼면 결과적으로 그대로 일 것 같다.

 

IMG1 _ Race Condition

 

하지만 IMG1의 아래쪽을 보면 알 수 있듯이, num이 항상 5라고 확정지을 수는 없다. 위 상황을 Race Condition이라 한다. Race Conditon은 둘 이상의 프로세스가 공통 자원에 동시에 접근할때 발생하는 현상이다. 'race'의 의미대로 한정된 자원을 두고 서로 사용하려고 경쟁하는 상황이다. 공유 메모리를 쓰는 프로세스끼리는 이러한 Race Condition이 발생할 수 있는데, 적절한 조치를 취해주지 않는다면 비정상적인 결과를 초래할 수 있다.

 

 

공격 예시 (Limit Overrun)

가장 잘 알려진 Race Condition을 이용한 공격은 의도된 제한 사항을 초과하는 공격(Limit Overrun)이다. 처음 만나봤던 상황과 더불어, 기프트 카드 중복 입력, anti-brute-force 시스템 우회 그리고 CAPTCHA 우회와 같은 다양한 공격이 포함된다. 

 

IMG2 _ timing the requests _ 출처:portswigger.net/web-security/race-conditions

 

Limit Overrun Race Condition 공격에서 가장 중요한 것은 타이밍이다. 충돌이 발생할 수 있는 구간을 "race window"라고 하는데, 최소 둘 이상 동시에 맞춰주어야 한다. race window의 발생 시간은 보통 밀리세컨드나 그 이하 단위 수준으로, 정말 순식간이다. 아무리 requests들을 동시에 보내더라도 IMG2와 같이 예측불가능한 외부적인 요인들로 인해 타이밍을 맞추기는 어렵다. 그리하여 'single-packet attack'기술을 통하여 최대한의 타이밍을 맞춰줄 것이다.

 

IMG3 _ single-packet attack _ 출처:portswigger.net/research/smashing-the-state-machine

 

PortSwigger의 Burp Suite툴을 이용하면 쉽게 맞출 수 있게 된다. 상세한 원리는 따로 정리한 포스트를 참고하자. 이제 PortSwigger에서 제공하는 공격 실습 환경을 통해 직접 Race Condition 공격을 해볼 차례다.

 

IMG4 _ Attack Point

 

우리가 공격할 부분은 쿠폰 입력 시스템이다. 프로모션 코드를 입력 후 Apply 버튼을 누르면 웹 Request가 발생하는 데 구성은 아래와 같다.

POST /cart/coupon HTTP/2
Host: ~~~~~~~~.web-security-academy.net
Cookie: session=~~~~~~~~

...

csrf=~~~~~~&coupon=PROMO20

 

Request 전달 후 서버 내에서 "이미 등록된 쿠폰인가?", "올바른 쿠폰 코드인가?"와 같은 검증을 거친 후 결과를 반환하게 된다. 우리의 목표는 여러개의 쿠폰을 등록시키는 것이다. Repeater를 통해 동일한 패킷을 동시에 여러개 보내보도록 하자.

 

IMG5 _ Repeater의 single-packet attack

 

IMG5와 같이 동일한 20개의 패킷 요청 그룹을 'single-packet attack' 방식으로 동시에 보내보면 결과적으로 쿠폰이 여러개 입력되는 것을 알 수 있을 것이다. 결과는 IMG6와 같다.

 

IMG6 _ Coupon Applied Succesfully

 

 

보안

Race Condition인 경우 위와 같은 비정상적인 상태가 발행하는데, 이러한 문제를 예방하는 것은 정말 중요하다. OS는 다른 프로세스의 의도치 않은 간섭으로부터 각 프로세스의 데이터 및 물리적인 자원을 보호해햐 한다. 또한 프로세스가 수행하는 내용과 결과는 서로 독립적으로 이루어 져야 한다. 구체적으로 두 가지의 예방책을 꺼내볼 수 있다. Semaphore와 Mutex.

 

IMG7 _ Semaphore

 

Semaphore는 공유 자원에 대해 여러 개의 프로세스를 조정하거나 동기화 시키는 기술이다. 자원 소유가 불가능 하며 시스템 범위에 걸쳐 있고 파일 시스템 상의 파일로 존재한다.

 

IMG8 _ Mutex

 

Mutex는 공유 자원에 대한 여러 개의 프로세스의 Running Time이 서로 겹치지 않게하는 기술이다. locking과 unlocking을 통해 접근을 조율 하고, 이 때문에 두 스레드가 동시에 사용할 수 없게 된다. Mutex는 프로세스의 범위를 가지며 프로세스가 종료될 때 자동으로 Clean Up 된다.

 

참고

https://zero-zae.tistory.com/107

https://portswigger.net/web-security/race-conditions

https://portswigger.net/research/smashing-the-state-machine

https://cyberw1ng.medium.com/limit-overrun-race-conditions-in-web-app-penetration-testing-2023-41576b6f5898