<목차>
- Access control 이란?
- Vertical privilege escalation
- Horizontal privilege escalation
- Horizontal to Vertical privilege escalation
-Access control 이란?
Access control 이란 어떤 개체에게 '작업을 수행하거나 자원에대한 접근하는것'에 대한 권한이 허가되는지에 대한 제한을 적용하는 것입니다.
웹 어플리케이션 문맥에선 , Access control 은 인증(authentication)과 session management에 의존합니다.
- Authentication : 유저가 주장하는 사람이 맞는지 확인하는 절차
- Session management : 이후 오는 HTTP 요청이 같은 유저에게서 만들어지는건지 식별하는것.
- Access control : 유저가 시도하는 행위를 허락할지 말지를 결정하는것.
Broken Access control 은 종종 치명적인 보안 취약점이 됩니다. Access control 을 설계 및 관리하는것은 비즈니스나 조직 및 법적 제약의 기술적 구현에 있어서 매우 복잡하고 동적인 문제입니다.
Access control 설계는 인간에 의해서만 행해져야 하며 이로인해 잠재적 에러가 날 확률이 매우 높습니다.
-Vertical privilege escalation (일반유저권한 -> 상위유저권한 )
만약 어떤 유저가 허가되지도 않은 기능에 접근한다면 , 이것은 Vertical privilege escalation 입니다.
예를 들어 어드민도 아닌 유저가 어드민 페이지에 접속하여 다른 유저의 계정을 삭제한다면 이것은
Vertical privilege escalation 가 되는 것이겠지요.
-Unprotected functionality
가장 기본적인 Vertical privilege escalation 은 어플리케이션이 sensitive functionality 에 대하여 보호를 하지 않을 때 발생합니다. 예를들어서 https://insecure-website.com/admin 를 통해 admin 홈페이지로 들어갈수 있거나
https://insecure-website.com/robots.txt 로 접속을 하여 admin 홈페이지의 위치를 알아낼수도 있습니다.
아니면 이런 민간함 기능의 위치를 찾기위해 워드리스트를 사용하여 브루트 포스 공격을 시도할수도 있습니다.
※robots.txt 가 뭔데?
검색엔진에 특정 웹사이트의 경로를 크롤하지 않도록 하는 특정 크롤링 규칙을 설정하는데 쓰입니다.
User-agent: *
Disallow: /administrator-panel
이런 포맷을 가지며 저기서 *는 모든 검색엔진 이라는 뜻입니다.
대표적으로 User-agent에 들어가는 값들입니다:
구글 : Googlebot
네이버:Yeti
다음:Daum
빙:Bingbot
Disallow 는 검색크롤링을 허용하지 않는다는 뜻이고 , administrator-panel 이라는 어드민 페이지의 경로를 확인할 수 있습니다. 일반유저가 저 경로로 들어가게 되는 경우를 막아야 하는겁니다.
-Unprotected functionality (Continued)
더 나아가 좀더 찾기 어렵게 URL 을 구성할수 있는데 이것을 " security by obscurity" 라고 합니다.
https://insecure-website.com/administrator-panel-yb556 이런식으로 구성하게 되면 그냥 administrator-panel 이라고 했을때보다 조금 더 추측하기 어려워 지겠죠? 그러나 이런 URL 또한 javascript 를 통해 유출 될수 있습니다.
딱 봐도 Admin 이라는 부분에 setAttribute 라는 명령어로 특정경로(/admin-evtx45) 를 지정해 주고있습니다.
이를 통해 어드민 페이지가 <https://웹사이트주소/admin-evtx45> 라는것을 추측할 수 있습니다.
-Parameter-based access control methods
어떤 어플리케이션들은 로그인 시에 유저의 권한과 역할에 대한 정보를 유저가 컨트롤 할수있는 위치에 저장해놓습니다.
대표적으로:
- A hidden field
- A cookie
- A present query string parameter
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1
이런식으로 쿼리문의 파라미터 값만 admin = true 이나 ,1 로 바꾸면 어드민의 권한을 가질수 있게되는 경우가 있습니다.
↓
이런식으로 cookie 에 Admin 을 식별하는것에 대한 정보가 남아있는데 이것을 true 로 바꾸면 어드민 페이지가 접속해지는 방식으로 예를 들어볼수 있을것 같습니다.
-Horizontal privilege escalation
Horizontal privilege escalation 은 같은 수준의 권한의 다른유저의 정보에 접근하는 것을 말합니다.
이것은 사실 Vertical privilege escalation 과 꽤 비슷한 방식을 가집니다.
어떤 유저의 계정 주소가 https://insecure-website.com/myaccount?id=123라는 링크를 가진다면 , 공격자는 id=123 부분을 바꿔서 다른 유저의 계정페이지로 이동할 수 있게됩니다.
<이것은 insecure direct object reference(IDOR) 취약점의 일종인데 , 이것은 유저가 컨트롤 할수있는 값이 정보에
접근하는데 직접적으로 사용될때 일어나는 취약점 입니다.>
그래서 어느 어플리케이션은 이런 파라미터 값들을 추측하기 힘든 값으로 바꿔놓기도 합니다.예를들어 위에처럼 id=123 식으로 그냥 숫자를 쓰는것보단 , globally unique idntifiers (GUIDs) 를 사용합니다.그러나 이런 GUIDs 는 메세지나 리뷰같이 유저가 참조되는곳에서 노출될 수 있습니다.
<실습>
이 사진은 carlos 란 사람이 쓴 리뷰인데 , 여기서 carlos 의 정보에 하이퍼링크가 걸려있습니다.
carlos 라는 이름을 누르면 어디로 이동되나 소스코드를 보니 ID = df54ae43-0889-4283-86cc-c66f0365eade 라는 부분을 볼수 있었습니다.
제 계정 주소의 링크를 잘보시면 id=ac357e8f-a376-4730-bca7-7616af371479 라는 형태의 주소가 있는것을 확인할 수 있고 이를 통해 저 부분을 carlos 소스코드에서 얻은 id=df54ae43-0889-4283-86cc-c66f0365eade로 바꾸면 뭔가 벌어지겠구나 라는것을 추측해 볼수 있습니다.
예상대로 carlos 의 계정페이지가 나오게 되었고 , API key 를 얻을수 있었습니다.
즉 이를통해 같은 수준의 권한을 가진 carlos 의 계정페이지를 알아볼 수 있었습니다.
-Horizontal to vertical privilege escalation
사실 지금 보시면서 생각하셨을 수도 있지만 방금 carlos 가 아닌 admin이 대상이였다면 admin 의 계정페이지를 알수 있었을텐데요, 그래서 주로 Horizontal 은 Vertical 로 이어지기도 합니다.
'웹해킹' 카테고리의 다른 글
| SQL Injection(SQLi) (0) | 2024.05.27 |
|---|---|
| File upload vulnerabilities (0) | 2024.01.30 |
| SSRF(Server-side request forgery) (0) | 2024.01.29 |
| Authentication vulnerabilities (1) | 2024.01.26 |
| Path traversal (1) | 2024.01.24 |