[Insecure Bank] 하드코딩 취약점 & 개발자 백도어

안녕하세요! 오늘은 하드코딩 취약점 & 사용자 정보 목록 이슈화 취약점 두가지의 대하여 실습을 통해 알아보겠습니다!

 

[하드코딩 취약점 이란?]

> 하드코딩이란 , 객체를 사용하지 않고 코드를 재사용할 수 없도록 코드 안에 변수를 상수로 사용하거나 코드를 다시 컴파일하지 않고서는 바꿀 수 없는 형태로 코딩하는 것을 말합니다. 이렇게 상수값 그대로 코드에 적어버리면 여러 문제점들이 발생하는데 예를들어 관리자 패스워드나 중요정보 , 암호화키 등이 코드에 노출이 될 경우 디컴파일을 통해서 정보가 노출될 수 있습니다!

 

[개발자 백도어 란?]

 

> 백도어란 정상적인 프로그램에 자신만이 들어갈 수 있는 코드를 삽입하여 정당한 인증 절차를 거치지 않고 들어갈 수 있는 뒷문입니다. 개발자들이 보통 유지보수나 디버깅 시 시간단축을 위하여 만드는경우가 있는데 이때 이 부분이 공격자에게 발견되면 시스템에 큰 위험을 초래할 수 있습니다.

---

1. 취약점 진단

1.1 하드코딩 취약점

1. Jadx를 통해 인시큐어 뱅크 앱을 디컴파일링한 후 CryptoClass 소스코드를 확인하시게 되면 암호화 키값이 그대로 노출되어 있는것을 확인하실 수 있습니다. 이를통해 이전 취약점에서 얻은 암호화된 아이디&패스워드 값을 복호화 하는것에 성공하였기 때문에 이것이 얼마나 위험한지를 알 수 있습니다!

암호화키 노출

---

1.2 개발자 백도어

1. 인시큐어 뱅크 클래스중 DoLogin class 코드를 살펴보게 되면 로그인 과정중 devadmin이라는 값이 ID 값으로 들어왔을때와 일반적인 경우가 나뉘어서 인증이 되는것을 확인하실 수 있습니다. 이를 통해 devadmin 이라는 아이디값으로 로그인을 시도해볼 여지를 주게 됩니다.

 

---

2. 그러면 실제로 인시큐어 뱅크 어플에 devadmin 이라는 아이디값을 입력하고 패스워드는 비워둔채 로그인을 진행하여 보겠습니다.

---

3. 정말 로그인이 되었습니다. 이를 통해 이건 관리자가 개발도중 인증없이 들어오기 위하여 만들어놓은 백도어라는 것을 알아챌 수 있게 되는것입니다!

---

2. 대응방안

2.1 하드코딩 이슈

> 이 경우는 개발자의 실수로 인한 취약점이라고 보는게 맞습니다. 따라서 배포하기전 소스코드중 민감한 정보가 그대로 노출되어 있진 않나 체크해야합니다. 암호화키의 경우 , 절대 상수로 명시하면 안되며, 솔트를 사용하여 암호화의 안정성을 높이는 것이 중요합니다. 솔트를 사용할 경우에도 예측하기 어려운 난수를 사용해야 하며, 고정된 값이나 특정한 값을 재사용해서도 안됩니다!

 

2.2 개발자 백도어

> 개발과정에서 남아있던 백도어 계정이 노출되어서 문제가 되었던 것이였습니다. 따라서 로그인 인증로직을 devadmin 과 일반 인증으로 나누지말고 정상적인 로그인 로직만 남겨두면 대응이 가능합니다.

---

긴 글 읽어주셔서 감사합니다!