[TroubleShooting] 메모리 중요정보 노출 취약점 개선방안

목차

1. 개요
2. 취약점 파악
3. 개선방안
4. 결론

1. 개요

안드로이드 업무에서 보안점검을 받던 중, 앱에서 중요정보가 메모리에 남는다는 취약점이 발견되었다.

 

중요 정보는 `신분증 이미지`였는데, 서버로 데이터를 전달하고 사용하지 않기 때문에, 가비지 컬렉션의 대상으로 GC가 일어나면 사라질 정보였었다.

 

하지만, GC가 언제 일어 날지 모를뿐더러, 이런 민감정보(신분증 이미지 뿐만 아니라 계좌정보나 고객의 연락처 등 개인정보)를 사용함에 있어서 주의가 항상 필요했다.

 

내가 맡은 애플리케이션은 금융앱이라 난독화나 여러가지 보안 솔루션이 있지만, 안심해서는 안된다.

 

이런 중요 정보들은 사용하지 않는다면, 메모리에 남아 있지 않도록 보호하는 것이 중요하다.

어떤 문제점이 있었고 해결은 어떻게 했는지 작성해보려고 한다.

2. 취약점 파악

`실제 운영하는 앱이 아닌 가상의 프로젝트를 만들어서 테스트를 진행 하였다.`

 

메모리에 평문으로 저장된 민감한 정보는 보안상 취약하다고 판단한다.

메모리 덤프 도구 중 하나인 Frida를 이용하였고 Fridump를 이용해 Memory Dump를 분석했다.

 

설치 가이드가 필요하다면 아래 링크를 통해 살펴보자.

• https://secuhh.tistory.com/5

2-1. Fridump 실행

python fridump3.py -U -s -o [덤프저장경로][App패키지명]

fridump 루트로 가서 위 명령어를 치면 아래 그림과 같이 메모리 덤프가 실행된다.

2-2. 메모리 덤프 결과 확인

결과를 보면 dump폴더가 만들어지며 데이터와 strings.txt파일이 생성 되는 것을 볼 수 있다.

2-3. 취약점 확인

strings.txt 파일을 열면 아래와 같이 민감한 개인정보가 남는 취약점을 확인 할 수 있다.

3. 개선방안 논의

이런 개인정보들이 메모리에 남는다면 보안상 많은 문제를 일으킬 수 있다. 해커가 기기를 탈취해서 앱을 실행하고 덤프를 뜬다면 쉽게 탈취가 가능해진다.

그래서, 협업과 같이 다음 3가지 개선방안을 논의 하였다.

3-1. 데이터 암호화

객체를 메모리에 로드하기 전에 데이터를 암호화하면, 메모리에서 직접적인 데이터 접근이 이루어지더라도 데이터는 보호된다. 암호화된 데이터를 사용하면 다음과 같은 장점이 있다.

장점

• 보안 강화: 민감한 데이터(예: 비밀번호, 개인 정보)가 메모리에 저장될 때, 암호화된 형태로 저장되므로 메모리 덤프 공격 등으로부터 데이터를 보호할 수 있다.
• 접근 제어: 암호화 키를 소유한 사용자나 시스템만 데이터에 접근할 수 있어, 불필요한 접근을 제한할 수 있다.

단점

• 성능 저하: 암호화 및 복호화 과정으로 인해, 데이터 처리 속도가 느려질 수 있다.
• 키 관리의 어려움: 암호화 키의 보관 및 관리가 어려울 수 있으며, 키가 유출될 경우 데이터의 보안이 취약해질 수 있게 된다.
• 복잡성 증가: 시스템에 암호화 로직을 추가하면, 개발 및 유지 관리의 복잡성이 증가하게 된다.

3-2. 보안 솔루션 도입

보안 솔루션을 도입하는 것은 메모리 관리와 보안성을 크게 향상시킬 수 있다.

장점

• 데이터 유출 방지: 메모리나 디스크에 저장된 데이터를 모니터링하고, 불법적인 접근이나 유출을 방지할 수 있다.
• 애플리케이션 보안: 코드 내에서 취약점을 자동으로 탐지하고 수정할 수 있는 도구들이 있다. 이를 통해 보안성을 높일 수 있게 된다.

단점

• 비용 증가: 상용 보안 솔루션을 도입하는 경우, 초기 도입 및 유지 관리 비용이 높을 수 있다.
• 관리 복잡성: 보안 솔루션을 효과적으로 운영하기 위해서는 전문적인 지식과 관리 노력이 필요하다.

3-3. 가비지 컬렉션 대상 설정

객체를 사용하고 더 이상 필요하지 않는다면 해당 객체를 Null로 설정하는 방법이다.

 

앞으로도 이런 보안점검을 통과하기 위해, 위와 같은 여러 논의가 와갔지만, 이 방법이 제일 간단하고 예상치 못한 비용을 절감할 수 있는 방법이라고 생각했다.

 

내 프로젝트 코드의 경우 `String` 을 이용해 신분증 이미지를 전달했는데, 이것은 Null로 바꾼다고 해결이 되지 않았다.

 

이유는 다음과 같다.

 

바로 String은 불변객체이기 때문이다.

 

위 그림처럼 String의 경우 객체지만 String constant pool 안에서 관리하는 특별한 친구이기 때문에, sensitiveData의 값을 바꾸거나 Null로 바꿔도 메모리에 남게되는 문제가 발생하는 것이다. 이 점을 꼭 유의해야한다.

 

그래서, 나는 민감한 데이터를 처리할 때는 `String` 대신 `char[]`배열을 사용하였다. char[] 배열은 변경 가능하고 사용 후 데이터를 명시적으로 지울수 있다.

4. 결론

이번 논의를 통해, 메모리 상에 남아 있는 민감한 데이터가 보안상 심각한 위협이 될 수 있음을 확인했다.

 

특히, `String`객체와 같이 불변객체로 처리된 데이터는 Null로 설정하는 것만으로는 완전한 보안 조치가 되지 않음을 알 수 있었다.

 

따라서, 민감한 정보를 안전하게 처리하기 위해서는 단순한 참조 제거 이상의 보안 대책이 필요하다. 데이터 암호화와 같은 방법은 보안을 강화할 수 있지만 키 관리의 어려움을 동반하며, 보안 솔루션 도입은 예상치 못한 비용발생이 수반한다.

 

이 모든 점을 고려할 때, 우리 팀은 특정상황에 적합한 방법을 선택하는 것인 중요하다고 결론 지었다. 예를 들어, 신분증 이미지와 같은 민감한 데이터를 처리할 때는`String` 대신 `char[]`와 같은 가변 객체를 사용하여 처리 후 명시적으로 메모리에서 지우는 것이 좋다.

 

결국, 보안 요구 사항과 시스템의 성능 요구 사이에서 적절한 균형을 찾는 것이 중요하며, 향후 프로젝트에서도 이러한 접근 방식을 적용해 나가는 것이 바람직하다고 생각했다.