해킹 당해 본 적 있니? feat (파라미터 변조 해킹)
- 2023-08-09
과거 현업에서 운영 했었던 시스템 관련해서 삼성 SDS 보안점검으로 해킹 당하고 보안 대책을 세웠던 후기를 공유하려 합니다
MES 분야에서 일 한지 4~5년차,,, 스마트팩토리가 가장 잘 구축되어 있는 반도체 분야 시스템을 운영하면서,
규모 측면에서는 누구도 쉽게 접해보지 못할 만큼 방대한 로직과, 레거시 소스로 가득한 시스템을 운영하고 있다고 자부합니다.
시스템 반도체 공정 로직과 더불어 각 공정과 모듈, ST(Standard Time) 그룹에 해당하는 각 반도체 설비의 생산성 지표를 뽑아내기 위해 Batch 프로그램을 돌려서 DB 테이블을 적재하고, 고객에게 각 화면에 대해 집계된 테이블을 기준정보 테이블과 조인해서 Grid 와 Chart 형태로 데이터를 보여주는 시스템을 운영 했었습니다.
20년 넘게 지속되어 온 시스템으로, 레거시도 상당한 편이라, 코어 단 소스를 바꾸는 것이 여간 힘든 일이 아니었습니다. SSO(Single Sign On) 인증 체계에서 AD(Active Directory) 인증 체계로 바꾸고, 이번에 해킹을 당하면서, 보안 로직을 새로 추가했지만, 여러 다른 모듈과 간섭이 없이 정상적으로 동작하게 개발 했었던 스트레스가, 개인적으로 'Clean Code' 와 'Design Pattern' 에 대해서 관심을 가지게 된 계기가 되기도 했었는데요..
각설하고 해당 시스템에서 일하면서 작년 삼성 SDS 로부터 보안점검을 받은적이 있었고, 그 중 파라미터 변조(Parameter Modulation) 해킹을 통해서 발견된 2가치 취약점과 극복 과정을 공유하려고 합니다.
(* 나름 시스템 담당자로서 반도체에서 보안 이슈는 심각한 문제였고, 해당 계기로 보안 관련 공부를 몇 달간 한적이 있었는데 이부분은 나중에 따로 포스팅 하려 합니다.)
1. 자가 결재 권한 상승
해당 시스템에서 사용자가 권한이 없는 화면에 대해서 이용할 수 있게 '사용자 권한 신청' 이라는 화면이 있습니다.
화면의 입력 폼을 보면 '신청 사유', '담당업무', '신청화면', '결재자' 를 입력하는 부분이 있고, 이 중 '결재자'의 경우 사용자 이름을 검색하면 사용자 리스트 추가 팝업 창이 나타나 결재자를 선택하는 형태입니다.
이때 사용자가 결재자를 입력해서 서버로 요청 콜을 보내면, 해당 이름에 해당하는 유저의 여러 정보를 XML 형태로 받아오는데 ( XML 사용하는 것도 오래된 기술의 방증... ) 여러 정보 중에 UniqueID 값을 신청자의 UniqueID 로 중간에 가로채서 변조 후 받아오면, 화면 상에는 결재자 이름이 보여도 결과적으로 자기 자신의 UniqueID 로 결재되어 메일로 전자 결재시에 '결재자', '합의자' 없이 본인만 지정되어 바로 결재가 가능하게 됩니다.
|
사용자 권한 신청 화면 (정상 Case) 결재자 조회 과정
서버에서 받아온 결재 목록 중 A 유저 UniqueId 변조
변조한 UniqueID 로 자가 결재 진행
파라미터 변조 해킹 방지 로직
|
- 사실 이 부분은 해당 화면 개발자와 상의 하면서 이렇게 조치하면 되겠다! 라는 감이 잡힌 편이었지만 아래 2번째 권한 우회는 사실 많은 시행착오가 있었습니다
2. 권한 우회
해당 시스템은 화면만 100 여개가 넘고 그 중, 사용자 권한에 따라 접근이 불가능 한 화면도 있습니다.
동작 과정으로 C/S 프로그램으로 처음 AD(Active Directory) 로그인을 통해서 파라미터를 받아오면 그걸 Client 쪽 메모리에 계속 들고 있도록 하고 있는데요, 바로 그 Response 파라미터를 서버에서 받기 전, 중간에서 높은 우선 순위를 가진 파라미터로 변조하여 메모리에 담아 상위 권한 화면도 접속할 수 있게 하는 해킹이었습니다.
기존에는 상위 권한 메뉴 접근이 없는 사용자가 화면에 접근하려 하면 ("메뉴 접근 권한이 없습니다") 라는 팝업창으로 막았지만 역시 파라미터 변조 에서 뚫릴 수 밖에 없는 구조 였습니다.
보안 팀의 가이드로는 아래와 같았습니다.
사실 이번에 해킹을 당하면서, 저도 보안 관련해서 나름 공부를 했었습니다. 파라미터 변조 해킹을 막는 정석은 "Client -> Server" 나 "Server -> Client" 로 API 나 WCF 요청콜을 보낼 때마다 파라미터에 암호화를 걸어서 하는 방법입니다. 하지만 Web 과 달리 C/S 시스템은 Client 쪽 소스가 사용자 PC 에 저장된다는 이슈가 있습니다. 저희 시스템은 Client 쪽 소스를 배포 할 때 해당 소스를 모두 난독화 시켜버려서 배포하지만, 해커 입장에서는 해당 소스를 다시 복호화 할 수 있다는 답변을 들었고, 그렇기 때문에 해커는 어떤 암호화 방식을 사용했는지 알고, 암호화에 사용한 Private key 가 노출되기에 암호화 방식을 이용한 보안 로직으로는 해당 이슈를 해결할 수 없었습니다. (* 1번 자가 결재 상승 방식도 다른 방식으로 보완 처리) |
보안 팀 가이드에 대한 제 답변.
|
해당 가이드에
대해서, C/S 프로그램은 Web 처럼
세션관리를 하고 있지 않습니다. ( * Web 은 Stateless 하기 때문에 사용자를 특정하기 위해 Session 을 사용하지만, C/S 는 Stateful 하기 때문에 Session 을 사용하지 않습니다) AD 나 SSO 로그인 과정에서, 해당 security(UI_GRT) 를 특정할 파라미터가 있다면 세션처럼 검증하는 로직을 넣을 수 있어 보이나, 해당 파라미터는 TPSS 내부에서 관리하는 파라미터로 해당 조치가 어려워 보입니다. 참고로 저희 시스템은 (WPF - WCF - Oracle) 의 3 Tier 구조의 시스템으로 운용 됩니다.
[XBAP and browser cookies (not working) - MSDN]
[AD 로그인 과정 로직]
web 처럼 시스템을 구현 했엇다면, 서버에서 보내는 Cookie, Token 을 통해 권한을 체크 후, 응답 값으로 Client 에게 권한(Parameter) 정보를 보내는 것이 아닌, 컨트롤러 단에서 화면 라우팅 제어나, 데이터를 뿌려주도록 할 것 같은데요.
WPF 특성상 .exe 파일 실행 시, 각 화면에 해당하는 dll 을 전부 Client PC 로 다운받아 놓은 상태에서, 서버에서 받아온 응답(권한)값(UI_GRT) 에 따라 화면을 Open 할 수 있도록 이전 개발자가 만들어서 운용 중입니다. (사실 왜 이렇게 했는지 의아합니다.)
만약 조치대로 하더라도, 5번 과정에서 (쿠키 or Token) 을 Header 에 담아서, 요청 파라미터와 같이 보낸 후, 서버단에서 본인 인증 과정을 거칠 때, 본인이 아닌 것으로 판명되어 특정 값을(에러값) 7번 과정에서 서버 -> 클라이언트로 주더라도 파라미터 변조로 중간에서, 응답값을 정상인 것처럼 바꾸면 별 수 없는것 아닌가요? 즉 쿠키를 이용한다 한들, 받아오는 응답값도 또한 암호화 해야하지 않은가? * 하지만 난독화된 client 소스를 분석 툴로 까볼 수 있다면, 대칭키든, 비대칭 키 암호화 방식을 사용하던 간에, secret key, 비밀키가 노출되어 버리지 않는가? |
결과 처리
- 1. 사용자 시스템 접속 시, 권한에 따른 .dll 파일만 다운되도록 수정합니다.
- 2. 1번 조치를 우회해서 어떻게든 권한이 없는 특정 화면을 접속 했다고 가정 했을때 화면의 Search 버튼 클릭 시마다 AD 인증 (JWT) 에서 확인한 토큰의 파라미터와 비교하여, 차이점 확인시 에러 조치
마무리
결과적으로 위에 표기한 방법처럼 처리하여 다사다난 했었던 해킹 방어 로직을 구축할 수 있었습니다.
해당 계기로 비대칭, 대칭키 암호화 방식 부터, Cookie, Session, Token 의 개념.. 파라미터 변조 해킹 방식 등등 몇 주간 힘들게 매달리면서 보안 관련 지식을 많이 쌓을 수 있었고 코어단 소스를 건드리면서 Clean Code, Design Pattern 에도 관심을 가지게 되었습니다.