개발자 생활을 10년 넘게 하다 보니, 가끔은 우리가 일상적으로 사용하는 평범한 도구들이 전혀 예상치 못한 방식으로 악용될 때 큰 충격을 받곤 합니다. 보안 이슈라고 하면 보통 복잡한 암호화 알고리즘이 뚫리거나 서버의 백도어를 상상하기 쉽지만, 실제 현장에서는 훨씬 더 창의적이고 기발한 우회로가 발견되기도 하죠. 오늘은 커피 한 잔 하면서, 최근 보안 커뮤니티에서 흥미롭게 회자되었던 '데이팅 앱 Hinge를 해킹의 지휘소(C2 서버)로 사용하는 방법'에 대해 이야기해 볼까 합니다. 물론 이걸 따라 하라는 게 아니라, 우리 개발자들이 어떤 관점에서 시스템을 방어해야 하는지 함께 고민해 보자는 취지입니다.
먼저 C2(Command and Control) 서버가 무엇인지 간단히 짚고 넘어갑시다. 해커가 감염된 좀비 PC들에게 "공격해" 또는 "정보를 보내"라고 명령을 내리는 중앙 서버를 말합니다. 보통 기업의 방화벽은 수상한 서버로 향하는 트래픽을 차단합니다. 하지만 만약 그 트래픽이 우리가 흔히 쓰는 데이팅 앱인 'Hinge'로 향한다면 어떨까요? 대부분의 보안 장비는 이를 정상적인 사용자의 데이트 활동으로 간주하고 통과시킬 겁니다. 바로 이 점을 노려, 데이팅 앱을 악성코드 배포와 명령 전달의 숙주로 삼는 아이디어입니다.
이 공격 시나리오의 첫 단계는 생각보다 아날로그적입니다. 앱 계정을 만들기 위해 실제 전화번호가 필요하기 때문이죠. 예전에는 Google Voice 같은 가상 번호를 썼지만, 요즘은 다 막혀 있습니다. 연구자는 Mint Mobile 같은 선불 유심을 현금으로 구매해 추적을 피하는, 다소 영화 같은 방식을 제안합니다. 개발자인 우리는 보통 API 키나 인증 토큰만 신경 쓰지만, 공격자는 물리적인 신원 세탁부터 고민한다는 점이 인상적이면서도 섬뜩한 부분입니다.
그다음은 데이터를 숨기는 기술, 즉 스테가노그래피(Steganography)가 등장합니다. 해커는 실행 파일(Payload)을 평범한 이미지 파일인 것처럼 픽셀 데이터로 변환합니다. numpy나 PIL 같은 파이썬 라이브러리를 이용해 바이너리 데이터를 이미지의 색상 정보 속에 교묘하게 숨기는 것이죠. 사용자가 프로필 사진을 업로드하면 Hinge 서버는 이를 압축하고 변환하지만, 정교하게 인코딩된 데이터는 이 과정을 살아남습니다. 겉보기엔 그저 웃고 있는 프로필 사진이지만, 실제로는 해독하면 "Hello World"를 출력하거나 악성 행위를 수행하는 코드가 숨겨져 있는 셈입니다.
여기서 우리가 주목해야 할 기술적 포인트는 '네트워크 트래픽을 어떻게 가로채는가'입니다. 앱이 서버와 통신하는 내용을 분석하려면 MITM(Man-In-The-Middle) 공격을 수행해야 하는데, Hinge는 기본적으로 SSL 인증서 고정(Certificate Pinning)을 강하게 적용하지 않았다는 허점이 있었습니다. 연구자는 루팅된 폰 대신, adb를 이용해 APK 파일을 추출하고 네트워크 보안 설정을 조작하는 방식을 택했습니다.
구체적으로는 network-security-config라는 XML 파일을 수정하여 사용자가 설치한 사설 인증서를 앱이 신뢰하도록 강제했습니다. 저도 주니어 시절, 디버깅을 위해 이 설정을 건드려본 적이 있는데, 상용 앱이 이토록 간단하게 트래픽을 허용한다는 건 보안적으로 뼈아픈 실책입니다. 공격자는 이 틈을 타 Hinge의 비공개 API 구조를 파악하고, 특정 사용자 ID(User ID)만 알면 인증 없이도 해당 사용자의 프로필 사진(즉, 숨겨진 악성코드)을 다운로드할 수 있는 경로를 찾아냈습니다.
이 사례가 우리에게 던지는 메시지는 명확합니다. "기능이 동작한다"는 것과 "안전하다"는 것은 완전히 별개의 문제입니다. 우리는 프로필 사진 업로드 기능을 구현할 때, 단순히 이미지가 잘 올라가고 보이는지에만 집중합니다. 하지만 누군가는 그 이미지 업로드 기능을 파일 저장소로, 텍스트 필드를 명령 전달 코드로 악용할 수 있습니다. 특히 curl 명령 몇 줄로 인증 토큰 없이 다른 사용자의 데이터를 긁어올 수 있는 API 취약점은, 백엔드 개발자라면 누구나 한 번쯤 저지를 수 있는 실수이기에 더욱 경각심을 줍니다.
결국 보안은 창과 방패의 싸움이지만, 때로는 방패의 틈새가 아주 사소한 곳에서 벌어집니다. 우리가 만드는 서비스가 해커들의 놀이터가 되지 않으려면, 기능 명세서에 적힌 로직 너머를 볼 수 있는 시야가 필요합니다. "설마 데이팅 앱으로 해킹을 하겠어?"라는 안일함이 가장 큰 보안 구멍일지도 모릅니다. 오늘 동료들과 코드 리뷰를 하신다면, 우리 API가 의도치 않게 너무 친절하지는 않은지, 혹은 검증되지 않은 데이터를 너무 쉽게 믿고 있지는 않은지 한 번쯤 되돌아보는 건 어떨까요?
