거래소를 인수하면서 이전 팀이 남긴 보안 점검 목록을 하나씩 확인하게 됐는데 읽어 보니 대부분 되어 있다는 답이었다. 코드를 안 열고 답한 것이라 실제로 검사해 보니 결과가 달랐다.
Table of contents
Open Table of contents
증상 — 읽기만 한 점검 결과
질의를 문자열로 조립하지 않는다고 답한 항목이 있었는데 grep -rn '" + ' src/ 로 찾아보니 "WHERE member_no = " + memberNo 같은 자리가 열여덟 곳이었다. OWASP Top 10 2017 의 A1 Injection 공식 문서가 예시로 든 바로 그 형태였다. 안 한다는 답과 실제 코드가 어긋나 있었다.
읽고 답하는 방식은 그 시점의 기억을 확인하는 것이지 코드를 확인하는 것이 아니다. 항목마다 무엇을 돌려서 확인할지가 없으면 결과가 답하는 사람에 따라 달라진다.
조치 — 확인 방법과 통과 기준
두 가지 방법이 있었다. 목록을 다시 돌리며 항목마다 담당자 서명을 받는 것과, 각 항목에 확인 명령과 통과 기준을 함께 적는 것이다. 뒤쪽을 골랐다. 이유는 서명은 다음 점검 때 또 기억을 묻는 것이라서다. 대신 명령으로 못 재는 항목은 목록에서 따로 갈라 두어야 하는 것을 감수했다.
질의 조립은 위 grep 과 0건이라는 기준을, 관리 화면 노출은 외부에서 curl -I 했을 때 403 이라는 응답 코드를 기준으로 적었다. 방법이 적혀 있으면 다음 사람이 돌려도 같은 결과가 나온다. 점검 결과가 사람이 아니라 명령에 달리게 만드는 것이 이 작업의 목적이었다.
밖에서 봐야 하는 것
항목을 안에서 확인할 것과 밖에서 확인할 것으로 갈랐다. 코드와 설정과 권한은 안에서 보면 되지만 포트 노출과 화면 접근과 인증서는 밖에서 봐야 한다.
실제로 외부 회선에서 nmap -p- 로 훑어보니 열려 있으면 안 되는 것이 셋 열려 있었다. ActiveMQ 관리 콘솔 8161 과 브로커 61616 과 MariaDB 의 3306 이었고, 안에서는 FortiGate 정책만 보고 막혔다고 판단하고 있었다.
검증 — 0건이 아무것도 안 한 것일 수 있다
검사 하나가 0건으로 나왔을 때 그것이 통과인지 확인이 필요했다. 걸려야 하는 문자열을 일부러 넣고 돌려 보니 그 검사가 아무것도 못 잡았고 정규식이 틀려 있었다.
0건은 위반이 없다는 뜻일 수도 있고 검사가 아무것도 측정하지 않았다는 뜻일 수도 있다. 그래서 통과가 나온 항목마다 잡혀야 하는 입력으로 한 번씩 대조군을 돌렸다.
재발 방지 — 다른 형태와 자동화
열여덟 곳을 PreparedStatement 로 고치고 다시 돌리니 0이 됐지만 String.format 으로 조립하는 다른 형태가 남아 있었다. 검사 패턴을 늘리니 넷이 더 나왔고 한 형태로만 찾으면 다른 형태가 그대로 산다.
확인하지 못한 항목은 침투 시험과 키 관리와 로그 마스킹 셋이었고 언제 할지를 함께 적었다. 마지막으로 검사들을 security-check.sh 로 묶어 Jenkins 빌드에 붙였는데 한 번 고치고 끝내면 같은 것이 다시 들어오기 때문이다.
정리
- 점검 목록은 읽는 것이 아니라 돌려 보는 것이다
- 읽고 답하면 결과가 답하는 사람에 따라 달라진다
- 항목마다 확인 명령과 통과 기준을 함께 적는다
- 밖에서 확인할 것은 실제로 밖에서
nmap으로 한다 - 0건은 검사가 아무것도 측정하지 않은 것일 수 있다
- 통과가 나오면 잡혀야 하는 입력으로 대조군을 돌린다
" +한 형태로만 찾으면String.format형태가 남는다- 못 한 항목을 언제 할지와 함께 적는다
- 검사는
Jenkins빌드에 붙여 다시 들어오는 것을 막는다