Password 관련 취약점 분석

이번에 이야기할 취약점은 패스워드와 관련된 취약점입니다. 

특히 개인정보보호법 등에서 패스워드에 대한 내용이 언급이 되고 있어 컴플라이언스 및 정책적인 측면에서 확인을 해줘야 하기 때문에 패스워드 관련 취약점은 생각보다 다양한 케이스가 존재합니다. 

패스워드와 관련된 다양한 케이스는 아래와 같습니다.

01. 패스워드 정책 검증

02. 2차 패스워드 정책 검증

03. 패스워드 대/소문자 구분부재

04. 패스워드 초기화 정책 미흡

05. 잘못 입력한 패스워드 출력

06. 응답값 내 패스워드 노출

07. 패스워드 저장 시 암호화

08. 패스워드 로그기록

이 밖에도 다양한 케이스들이 존재할 수 있습니다.

01. 패스워드 정책 검증

---

보통 공격자는 자주 사용하는 계정명 또는 응답값에 노출된 계정명에 대해 Fuzzing 프로그램을 활용하여 패스워드를 탈취합니다. 때문에 로그인 인증 횟수를 제한하는데요, 여기서 패스워드가 매우 간단하다면, 횟수와 상관없이 운이 안좋을 경우 바로 탈취도 가능하게 됩니다. 때문에 패스워드는 영문 대문자, 영문 소문자, 숫자, 특수기호를 결합하여 복잡도에 따라 최소길이를 제한해야 합니다.

- 2종류 이상 사용 시 최소길이 : 10자리 이상

- 3종류 이상 사용 시 최소길이 : 8자리 이상

여기서 주의해야 할 내용은 패스워드 정책의 검증을 스크립트에서만 해서는 안됩니다. URL을 직접입력하거나 응답값을 변조할 경우 스크립트 검증은 우회가 가능하므로 반드시 패스워드가 저장되는 최종단계의 서버측 코드에서 검증을 진행해야 합니다. 

02. 2차 패스워드 정책 검증

---

XSS 공격이 가능한 페이지에서 쿠키값을 탈취할 수 없을 경우, CSRF 공격을 시도하는 경우가 있습니다. 이때 CSRF 공격을 방어하기 위해서는 물론 XSS가 안되도록 하는 것이지만, 특정한 경우 어쩔 수 없는 경우가 있죠. 때문에 중요기능을 제공하기 전 2차 패스워드를 검증해줘야 합니다. 

여기서 2차 패스워드 검증을 할 때 중요기능을 제공하는 페이지에서 2차 패스워드를 검증했는지 여부를 검증하지 않거나, 파라미터 변조 등을 통해 2차 패스워드 검증로직 자체를 우회를 할 수 있는 케이스 등이 존재합니다. 

중요기능을 제공하기 직전 서버측 코드에서 2차 패스워드를 검증받았는지 여부를 검증해야 하고, 검증여부를 세션에 저장할 경우 한시적으로만 사용하도록 로직을 구현해야 할 것입니다. 

- URL 직접입력을 통해 2차 패스워드 페이지 우회

- 2차 패스워드 검증 여부를 파라미터로 전달하는 경우

- 중요기능(회원정보 보기 등) 페이지 접근 시 로그오프까지 1회만 2차 패스워드 검증 등

03. 패스워드 대/소문자 구분부재

---

가끔 개발자의 실수 또는 클라이언트의 요청에 따라 계정명 및 패스워드에 대/소문자를 구분하지 않는 경우가 있습니다. 예를들어 서비스 이용 대상자가 고령의 노인 분들인 경우, 대/소문자를 구분하는 것에 따른 많은 CS가 발생할 경우 어쩔 수 없이 대/소문자를 구분하지 않는 경우가 있겠네요. 

하지만 당연하게도 이는 보안적인 측면에서 반드시 조치해야 하는 내용입니다. 때문에 패스워드를 검증하는 로직에서는 대/소문자를 구분하지 하여 사용자가 정확히 입력했을 경우만 로그인에 성공이 되도록 로직을 구성해야 할 것입니다.

만약 대/소문자를 구분하지 않으려면 리스크 측면에서 패스워드가 노출되어도 큰 이슈가 없을 정도의 서비스이거나, 패스워드의 최소길이(최소 60자리)를 매우 길게 해야 하지 않을까 싶네요. 

04. 패스워드 초기화 정책 

---

사용자 로그인 서비스 제공 시 특정횟수 이상 실패하게 될 경우, 더 이상 로그인이 되지 않도록 잠금처리를 해줘야 합니다. 이 때 다양한 방법을 사용하여 정상 사용자 여부를 인증하면 패스워드를 초기화 해주게 되죠. 이때 초기화 정책이 잘못되어 있을 경우, 또 다른 취약점이 발생할 수 있습니다.

패스워드를 초기화 할 때는 패스워드 정책이 적용된 임의의 랜덤한 임시 패스워드를 생성하여, 사용자 회원정보에 저장된 연락처(SMS/EMail 등)를 통해 전달해야 하며, 사용자는 임시 패스워드를 사용하여 로그인한 경우 반드시 패스워드 변경페이지로 이동하여 사용자가 직접 패스워드를 변경하도록 유도해줘야 합니다.

이런 패스워드 초기화 과정에서 정책에 위배가 되는 일부 케이스가 존재할 것입니다. 때문에 진단자는 이러한 정책이 제대로 이뤄지는지 확인을 해주면 될 것입니다.

- 초기화 패스워드를 관리자가 직접 입력하여 전달

- 고정된 임시 패스워드가 발급

- 패스워드 정책이 적용되지 않거나 미흡하게 적용된 패스워드를 발급

- 임시 패스워드를 계속 사용할 수 있는 경우

- 임시 패스워드로 로그인 시 패스워드 변경 페이지로 이동하지 않는 경우 등

05. 잘못 입력한 패스워드 출력

---

가끔 관리자 페이지에서 사용자가 로그인 시 실패한 이력 및 로그를 출력하는 경우가 있는데, 이때 사용자가 입력한 패스워드를 출력한 경우가 있습니다. 아무리 잘못된 패스워드라 하더라도, 상당히 큰 정보가 될 수 있습니다. 대체로 일반 사용자들은 실수로 잘못 타이핑하는 경우가 대다수이기 때문에 잘못 입력한 패스워드라 할지라도 절대 노출되지 않도록 해야 합니다. 이는 관리자 뿐만 아니라 일반 사용자 페이지 등에서도 로그인 실패시 응답값 등을 통해 절대 노출되지 않도록 해야 합니다.

관리자 페이지에서 실패 이력 출력 예시

No	User ID	State	Time	IP
...	...	...	...	...
11	userid****	Login Failed (4 of 5)	2019.03.09 12:23:19	192.168.0.***
12	userid****	Login Failed (5 of 5)	2019.03.09 12:24:52	192.168.0.***

06. 응답값 내 패스워드 노출

---

로그인을 성공하거나 실패할 때 어떠한 경우에도 패스워드를 노출해서는 안됩니다. 또한 관리자 페이지 및 사용자정보 페이지에서도 패스워드를 노출하지 않아야 합니다. 또한 패스워드를 DB에 저장 시 일방향 암호화를 하는데 이때 암호화 된 패스워드라 하더라도 응답값에는 노출되지 않도록 해야 합니다. 앞서 이야기 했던 실패한 내용이라도 악의적인 사용자에게 정보가 될 수 있고, 암호화 된 패스워드라도 다른 취약점과 연계될 수 있기 때문에 절대로 노출되지 않도록 해야 합니다.

07. 패스워드 저장 시 암호화

---

회원정보를 관리할 때 패스워드를 데이터베이스에 저장해줘야 합니다. 이때 패스워드는 개인정보보호법 등에 의거하여 안전한 일방향 암호화 기법을 사용하여 데이터베이스에 저장해줘야 하며 이때 128비트 이상의 키를 사용하는 SHA-256과 같이 안전한 일방향 암호화를 사용해야 합니다. 

- 패스워드를 양방향 암호화로 저장

- 패스워드를 안전하지 않은 암호화로 저장

- 패스워드를 평문으로 저장 등

08. 패스워드 로그 기록

---

서비스 제공 및 관리를 위해 다양한 내용으 로그로 기록 및 관리하게 됩니다. 이때 사용자의 패스워드를 로그로 기록을 하는 경우가 있는데요, 이런 경우 로그파일이 탈취될 경우 사용자의 패스워드 정보도 함께 탈취가 되기 때문에, 패스워드를 로그에 기록하면 안됩니다. 만약 반드시 로그로 기록을 해야 한다면, 여러 정보를 결합하여 암호화 하여 기록하고, 복호화 후에만 정보가 노출되도록 로직을 구현해야 할 것입니다. 당연히 이런 경우 암호화 키는 안전하게 보관 및 관리되어야 할 것입니다.

Fin