최근 MS Edge 브라우저로 특정 사이트에 접속했다가 화면 우측 하단에 팝업 광고가 계속 발생하게 된 사례를 보았다. 백신 설치를 유도하는 알림이었는데, 그 알림을 눌렀을 때 가짜 백신 설치 및 결제를 요구하는 페이지로 넘어가게 되었다. 얼핏 보면 마치 윈도우 디펜더로 정상적인 탐지로 보였지만 사실은 속임수였다. 필자는 해당 방법으로 감염(?)이 된 사례를 처음 들어봤기에 조사 후 다른 사용자들도 이런 피해를 당하지 않았으면 하는 마음에 정리를 해보았다.

공격 흐름

1. 특정 웹 사이트 접속

2. 수 많은 리다이렉트 발생

3. 캡챠 등을 활용한 정상적인 페이지로 보이도록 위장(?) 위와 같이 알림 표시 기능을 허용할 것인지 물어본다. (허용하지 않으면 겁을 주는 알림이 발생하지 않는다)

4. 백신 사이트 같은 페이지로 이동(노턴 안티바이러스)

• 바이러스 검사를 진행하는 척 하면서 "바이러스가 감지되었습니다." 라며 사용자에게 겁을 주고 있다. 컴퓨터를 다루기 어려운 사용자는 겁을 먹을 수 밖에 없도록 만든다.

• 노턴 360 프리미엄의 결제를 유도하고 있는데 결제를 실제로 진행하는 사용자가 얼마나 있을지는 모르겠지만, 그리고 결제를 한다고 하여 정말 백신 프로그램을 얻을 수 있을지도 미지수다. URL 자체는 정상적인 노턴 안티바이러스 코리아로 확인이 된다. 백신이 안 팔리나...

3. Edge 브라우저 알림처럼 보이는 팝업이 화면 우측 하단에 등장

• 3번에서 알림 표시 기능을 허용하여 발생하는 알람으로, "바이러스가 감지되었다." 라는 등의 공포심을 주게 된다.

4. 알림 클릭 시 가짜 백신 결제 페이지로 이동

• 해당 알림을 클릭하여 접속 시 노턴 홈페이지로 다시 이동하게 된다. 그리고 이 알람은 초 단위로 계속 발생하게 하여 트레이 아이콘을 볼 수 없고, 사용자 작업 화면을 계속 가리게 되어 작업을 진행할 수 없게 만든다.

추측되는 주요 공격 기법

1. 스케어웨어(ScareWare)

• 말 그대로 PC가 감염되었습니다! 같은 경고를 띄워 공포심을 조장한다.
• 가짜 백신 설치를 유도하고, 이를 통해 결제를 요구한다.

2. 멀버타이징(Malvertising)

• 악성 광고 또는 스크립트가 웹사이트에 삽입되어 사용자 브라우저를 감염시키는 공격이다.
• 악성 광고처럼 보이기도 하고, 리다이렉트 스크립트가 작동하여 멀버타이징의 요소도 있다고 본다.

3. 피싱

• 전통적인 의미의 로그인을 유도하는 피싱은 아니다.
• 하지만 금전적 피해를 유도했다는 점에서 넓은 의미로 피싱으로 볼 수 있다.

대응 방법

• 의심스러운 사이트 방문 시 즉시 창 닫기
  • 갑자기 알 수 없는 주소의 여러 사이트로 이동된다거나 할 때 즉시 창을 닫아야 한다.
    
    
• 알 수 없는 알림 수신 차단하기 위 사진과 같이 edge://settings/content/notifications 에 접속하여 알 수 없는 알림이 허용되고 있는 항목을 제거한다.

마치며

결론적으로 이 사례는 스케어웨어 기반 피싱 + 멀버타이징 요소를 결합한 복합형 공격 으로 판단해야 할 것으로 보인다. 정확히 정해진 공격 유형이 없기 때문이다.

요즘 많은 사람이 흔히 말하는 구글링을 통해 많은 정보를 알아보고는 한다. 해외의 많은 정보들이 있고 좀 더 폭넓은 검색이 가능하기에 쉽게 이용하지만, 나도 모르게 이런 공격에 노출이 될 수 있다.

평소에 백신 프로그램을 사용하는 습관을 들이고, 의심스러운 사이트는 방문하지 않는 것이 가장 중요하다. 그리고 알림을 허용하느니 이런 의심스러운 메시지가 생길 경우 무턱대고 누르지 말고 한 번 더 생각해 보고, 알아보고 누르는 습관을 들이는 게 좋다.

PC에 직접 감염되는 멀웨어가 아닌 단순한 광고성 페이지로 착각할 수 있지만, 어쩌면 금전적 피해로도 이어질 수 있기 때문에 주의가 필요하다는 말을 전하고 싶었다.

eval(), Response.Write() 메소드가 포함된 HTTP Request를 로그에서 확인하였다. 일반적인 요청에선 해당 메소드를 이용하여 요청하지 않으며, 웹 취약점 점검의 목적으로 요청한 것이 아닌 URL이라면 의심해 볼 여지가 있다.

이번 포스팅에선 이 요청이 어떤 의도를 가진 공격인지 정리해보려고 한다.

페이로드 구조

GET /search.asp?searchword={if:eval(action)}99&action=Response.Write(Hex(504286))

- eval(action)

• 해당 구문은 문자열을 코드로 가정하여 실행하는 동작을 하며, 보통 특정 코드 문자열을 받아 실행하게 되어 보안상 위험한 함수로 간주된다. action 파라미터에 특정 코드를 담아 실행시키기를 유도하고 있다.

- Response.Write(Hex(504286))

• 해당 구문은 504286 라는 숫자를 16진수로 변환해서 출력하라는 의미이다.
• 504286 → 7B9BE (16진수)

공격 판단

1. eval()은 실 서비스에선 솔직히 쓸 일이 없음(개발자들도 안씀)
   • 정상적인 웹 사용자가 URL 파라미터에 eval() 같은 함수를 넣는 경우는 거의 없다.
2. 자동화된 공격도구의 전형적인 패턴
   • eval(), exec(), Response.Write() 등은 공격자들이 코드 실행이 가능한 지 탐지하기 위해 자동화 도구에서 자주 사용되는 패턴이다.
3. 확인된 웹 취약점 점검 일정이 없기도 하고, 외부에서 요청한 IP에 대해서도 업무 연관성이 존재하지 않았다.

마치며

해당 공격은 서버가 외부 입력을 eval 함수로 실행할 수 있는지 테스트하려는 원격 코드 실행(RCE) 공격 페이로드로 보인다. 실행 결과로 7B9BE가 반환된다면 해당 서버는 취약한 상태라고 파악할 수 있는 것이다.

이러한 경우에 "이건 점검 목적이겠지" 라고 먼저 가정하는 건 보안 상 매우 위험한 판단이다. 실 서비스에 대한 무단 스캐닝은 그 자체로 공격 행위이며, 탐지 시 절차에 따라 대응해야한다.

DB 내 개인정보 및 민감정보 보호를 위한 암호화 방식은 보안성과 운영 편의성, 시스템 구조에 따라 다양하게 구분된다.

컬럼 암호화 방식 - Plug-In, API, Hybrid(Plug-In + API) 블록 암호화 방식 - TDE

본 포스팅에서는 암호화 적용 범위에 따라 크게 컬럼 암호화 방식, 블록 암호화 방식 두 방식으로 나누어 설명하며, 위와 같이 세부적인 방식들의 개념과 동작 원리를 이해해 볼 것이다.

컬럼 암호화

컬럼 암호화 방식이란 특정 열(Column) 단위로 암호화를 적용하는 방식

ex) 주민등록번호, 카드번호, 계좌번호와 같은 민감 데이터 컬럼만 암호화

기본적으로 컬럼 암호화 방식에서의 암호 알고리즘은 모두 SHA-256/384/512 및 키 길이 128bit 이상의 AES, 3DES, SEED, ARIA 등을 지원한다.

컬럼 암호화 방식에는 아래와 같이 총 3가지가 존재한다.

1. Plug-In 방식

• 암·복호화 모듈을 DB 서버 내·외부에 설치하고, 이 곳에서 암·복호화를 수행하는 구조

• 애플리케이션 코드를 수정할 필요가 없음

  동작 구조 : Application → SQL 실행 → Plug-in 모듈이 암·복호화 → DBMS

보통 가이드들에선 플러그인을 DB 서버 내부에 설치하여 진행한다고 되어있는데 현업에선 내·외부 모두 설치하여 이용할 수 있다고 한다.

WAS에 Plug-In이 설치되어 있다고 가정했을 때 WAS는 사용자 요청을 처리하기 위해 DB에 접근해서 데이터를 조회하거나 저장하거나 하는데, 이때 WAS가 DB에 접속할 수 있도록 하기 위해 DB 계정과 비밀번호 정보를 가지고 있어야 한다.

WAS의 설정 파일에 DB 접속 정보가 하드코딩 돼있거나 환경변수로 지정되어 있을 때, 이 DB 계정 정보가 유출이 된다면 공격자는 평문을 얻을 수 있는 상황이 된다.

실제로도 위와 같은 이유로 DBMS 내부에 설치하여 암·복호화를 수행하는 방식을 많이 이용한다고 한다. 그래서 가이드에서도 애초에 보안적인 측면에서 위험도가 있는 방법을 아예 삭제시킨 게 아닐까 하는 생각이 든다.

장점

• 애플리케이션 수정이 거의 없음
  • 암복호화가 SQL 처리 과정 중 Plug-in에 의해 자동으로 이루어짐
  • 예외 처리, 데이터 타입 등 일부 보완을 위해 약간의 수정은 존재할 수 있음

단점

• Plug-In 이 어디 설치되느냐에 따라 보안성이 달라짐
  • 클라이언트에 설치되면 공격자가 복호화 가능

2. API 방식

• 애플리케이션에서 직접 암·복호화 API를 호출하여 데이터를 처리하는 방법

• ex) encrypt(value), decrypt(value) 같은 함수 호출

  동작 구조 : Application → 암·복호화 API 호출 → 암호화된 데이터 DB 저장

API 방식에서의 암·복호화는 애플리케이션 코드 안에서 직접 수행된다. 암·복호화 로직이 코드로 직접 구현되거나, 암호화 모듈을 호출하는 방식이다.

예를 들어, 사용자가 주민등록번호를 입력하고 전송했을 때 애플리케이션 코드에서 암호화가 진행되고 출력된 암호문을 DB에 저장시킨다. 조회 시 애플리케이션에서 암호문을 불러와 복호화하는 방식이다.

위 내용을 봤을 때 한 가지 의문이 들었었는데 클라이언트가 개인정보를 전송했을 때 입력 값이 WEB을 거쳐 WAS에 도달할 때까지 평문 상태로 이동하게 되는 문제이다. 이 문제는 따로 HTTPS(SSL)나 VPN 등으로 구간 암호화를 진행하면 되겠다고 생각이 들었다. 꼬리에 꼬리를 무는 보안...

장점

• 암호화 대상과 범위를 개발자가 완전히 통제 가능
• 데이터 처리 전 암호화되므로 가장 강력한 보안성 제공

단점

• 애플리케이션 코드 대폭 수정 필요
• 운영 중인 서비스엔 적용 난이도가 높음
  • 차세대 시스템 개발 등에 기존 어플리케이션에 대한 전면적인 수정이 가능한 경우 적용

3. Hybrid 방식

• 암·복호화는 기본적으로 Plug-In 방식으로 처리되지만, 복잡한 경우나 일부 민감 컬럼은 API 방식으로 우회처리하는 방식

일반 SQL은 Plug-In이 처리하고 특정 중요 컬럼은 애플리케이션이 직접 API 호출로 암호화하는 흐름이다.

Hybrid 방식 예시(Java + JDBC)(완전한 코드 아님!)

// 주민번호는 API 방식으로 직접 암호화
String rrnPlain = "000101-1234567";
String encryptedRRN = Encryptor.encrypt(rrnPlain); // 직접 암호화 수행

// 전화번호는 Plug-in 방식으로 처리되므로, 그냥 평문으로 넣음
String name = "뭉치치";
String phone = "010-1234-5678";

// SQL 구성 (Plug-in이 개입할 수 있도록 일반 SQL 그대로 사용)
String query = "INSERT INTO 고객 (이름, 전화번호, 주민번호) VALUES (?, ?, ?)";

try (Connection conn = dataSource.getConnection();
     PreparedStatement pstmt = conn.prepareStatement(query)) {

    pstmt.setString(1, name);               // 평문
    pstmt.setString(2, phone);              // 평문 (Plug-in이 암호화)
    pstmt.setString(3, encryptedRRN);       // 암호문 (API 직접 암호화)

    pstmt.executeQuery();
}

위와 같이 고객이라는 테이블에 이름, 전화번호, 주민번호를 삽입하는 SQL 쿼리를 예를 들었는데, 개인정보보호법에 따르면 이름, 전화번호는 반드시 암호화해야 하는 정보가 아니다.

그러나 다른 정보와 결합하여 개인을 식별할 수 있다면 그것은 개인정보가 되기도 하고, 기본적으로 개인정보처리자는 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 해야 한다.

모든 개인정보를 암호화하는 경우 보호 수준은 높아질 수 있으나 개인정보 처리자의 부담은 커지므로 전화번호 정도는 Plug-In 방식으로 암호화를 진행 후 DB에 저장하고, 주민등록번호는 따로 내부적으로 정한 암호화 API로 암호화하여 암호문을 바인딩 해서 DB에 저장하는 방식으로 필자는 Hybrid 방식에 대해 예를 들었다.

(잘못된 예시인 경우 댓글로 지적해주시면 감사하겠습니다😅😂)

장점

• 애플리케이션 수정을 최소화하면서 민감 정보는 더 강하게 보호
• 유연성과 보안성을 동시에 고려할 때 사용

단점

• 구조가 복잡해지고, 관리 포인트가 증가
• Plug-In과 API 모두 관리해야 하기에 운영에 대한 이슈가 발생할 가능성 존재

블록 암호화

블록 암호화 방식이란 데이터를 저장소에 저장할 때 저장단위(블록 or 파일)를 기준으로 암호화하는 방식

블록 암호화 방식 중에선 TDE 라는 방식을 이해해 볼 것이다.

TDE 방식에서 암호 알고리즘은 SHA-256/384/512 및 키 길이 128bit 이상의 AES, 3DES 등을 지원한다.

1. TDE 방식

• DB에서 데이터를 디스크에 저장될 때 자동으로 암호화하고, 읽을 때 자동으로 복호화하는 방식

암호화 대상

TDE는 보통 아래와 같은 저장 단위(Block)에 적용된다.

동작 흐름

 1. 애플리케이션이 평문 데이터를 SQL로 전송
 2. DBMS가 데이터를 디스크에 쓸 때 자동으로 암호화
 3. 디스크에선 암호문 형태로 저장
 4. SELECT로 데이터를 읽으면 DBMS가 자동 복호화 후 평문 전달

위 동작 흐름을 보면 개발자는 암호화된 줄도 모를 정도로 무관심하게 사용할 수 있다. 근데 저 흐름을 봤을 때 한가지 의문점이 든다.

WAS ↔ DB 구간의 데이터는 평문 노출 가능성이 생기는 것이다.

따로 저 구간도 암호화를 하면 되겠지만 위에서 배운 내용을 기반으로 좋은 방식이 하나 떠올랐다.

바로 TDE + API 를 조합하는 방식이다. 민감한 데이터에 대해 WAS→DB 전송 전에 API 방식으로 애플리케이션 레벨에서 암호화하고, TDE 방식으로 암호화하여 디스크에 저장하면 해당 구간에서의 평문 노출은 없을 것이다.

이 방식은 실무에서도 많이 쓰이고, 금융권이나 공공기관에선 필수적인 보안 절차로 간주된다고 한다.

물론 쿼리 구조 자체가 노출이 된다거나, 암호화 하지 않은 일반 컬럼들이 노출이 될 가능성이 존재하여 네트워크 구간을 따로 암호화를 적용하는 경우가 많다.

장점

• 기존 시스템 수정이 거의 필요 없어서 설치/적용이 간단
• 운영/유지보수가 편함

단점

• 중요한 컬럼만 따로 암호화하는 것은 불가
• DB 계정이 탈취되면 평문의 노출 위험이 존재

마치며

사실 DB 암호화에 대해 깊이 생각해 본 적은 없었다.

그저 DB에는 정보가 있으니 암호화가 중요하다는 정도는 알고 있었고, 어떤 방식이 있는지, 어떻게 적용이 되는지에 대해 구체적으로 고민한 적은 없었다.

회사 업무를 진행하다가 얼떨결에 공부하게 되었는데, 이렇게 깊은 내용들이 있었고, 이 내용들이 하나씩 이해가 되기 시작하면서 DB 암호화의 중요성을 더욱 느끼게 되었다.

DB 암호화 방식에 여러 가지가 있다는 것을 알게 되었고, 단일 방식만 사용했을 때 발생하는 문제점들이 무엇이 있을까에 대해 생각해 보았고, 그 문제점들을 해결하기 위해 어떤 방식을 하이브리드로 조합해야 할 지도 생각해 볼 수 있는 좋은 기회가 되었다.

이 블로그에선 정보보안에 관련된 내용을 주로 담을 예정이다. 내가 이 분야를 사랑하기 때문이고, 현재 내가 일하고 있는 분야이기 때문이다.

< 처음은 뭐든지 쉽지 않다. 그래서 더욱 의미 있는 것 >

나는 차를 좋아한다. 그리고 내 재능을 기부하는 것을 좋아한다.

자동차 동호회 카페에 내가 아는 지식들을 공유하면서, 점점 쌓여가는 포스팅이 나만의 자산이 되기도 할 것이다. 회원들이 내 포스팅을 읽고 도움을 받아 고맙다고 인사해 줄 때, 나는 큰 보람을 느낀다.

원래 내 삶의 방식도 ‘아낌없이 주는 나무’처럼, 내가 희생되더라도 타인이 도움을 얻고 기뻐하는 모습을 보며 뿌듯함을 느껴 왔다. 상당히 이타적인 삶이라고 볼 수 있는데, 물론 장점도 있지만 단점도 있을 것이다.

그러나 단점을 이기는 장점이 있다고 느꼈기에, 앞으로도 나의 삶은 이러한 방식으로 흘러갈 것이다.

비록 시작에 불과하지만, 이 블로그가 나의 영양분이 되기를 바라며 앞으로 적든 많든 불특정 다수에게 도움이 되기를 희망한다.

“늦었다고 생각할 때가 가장 빠른 때”이고, “미래에 후회할 현재를 만들지 말자”는 나의 철학, 그리고 “하면 된다”라는 우리 집의 가훈을 새기며 블로그를 운영해 보려고 한다.

빠르게 달려갈 욕심은 없지만, 느리게 달려갈 생각도 없다.

천천히, 그러나 꾸준히 달릴 것이다.

-by. 뭉치치