Missions 소개: 개발자 중심 보안 교육의 다음 단계

2015년부터 저희는 전 세계 개발자들과 함께 보안에 대한 능동적이고 긍정적인 접근 방식을 공유해 왔습니다. 개발자들이 코드를 안전하게 보호하고, 재작업 및 수정 비용을 절감하며, 보안 팀을 단순히 '규제하는 사람들'이 아닌 협력자로 인식할 수 있도록 돕고 있습니다.

저희는 개발자들이 전 우주적인 규모로 코드를 안전하게 보호할 수 있도록 변함없이 곁을 지킬 것입니다. 이제는 한 단계 더 나아가, 실전 경험을 갖춘 보안 의식 높은 개발자들을 위해 새로운 변화를 시도할 때입니다.

Secure Code Warrior 플랫폼의 새로운 기능인 '미션(Missions)'을 소개하게 되어 매우 기쁩니다. 이 완전히 새로운 챌린지 카테고리는 개발자 중심 보안 교육의 다음 단계로, 사용자가 보안 지식을 단순히 기억하는 수준을 넘어 실제 시뮬레이션 환경에서 직접 적용해 볼 수 있도록 합니다. 이러한 단계별 마이크로러닝 방식은 업무와 직결된 강력한 보안 코딩 기술을 길러주며, 업무 시간 틈틈이 지루한 교육 영상을 시청하는 것보다 훨씬 흥미롭습니다.

저희가 처음으로 공개하는 플레이 가능한 미션은 GitHub 유니코드 취약점 시뮬레이션입니다. 겉보기엔 간단해 보일 수 있지만, 분석해 보면 매우 영리하고 재미있는 취약점입니다. 보안 연구원 0xsha는 포괄적인 사례 연구를 통해 이 동일한 버그가 어떻게 Django에서 대소문자 변환을 통해 악용될 수 있는지, 그리고 프로그래밍 언어에 따라 취약점의 동작이 어떻게 달라질 수 있는지 밝혔습니다. 이 보안 문제에 대해 알아볼 점은 매우 많으며, 저희 미션은 이를 시작하기에 아주 좋은 출발점입니다.

GitHub의 정면충돌(대소문자 매핑 충돌)

2019년 11월 28일 보안 연구 그룹 Wisdom이 작성한 블로그 게시물에서 그들이 GitHub에서 발견한 보안 버그에 대해 보고했습니다. 그들은 유니코드의 대소문자 매핑 충돌(Case Mapping Collision)을 활용하여 비밀번호 재설정 이메일을 잘못된 이메일 주소(공격자의 관점에서는 공격자가 선택한 이메일 주소)로 발송하게 만드는 방법을 설명했습니다.

보안 취약점은 결코 반가운 소식이 아니지만, 화이트햇 보안 연구원들은 잠재적으로 악용 가능한 오류를 발견하여 재앙을 막을 기회를 제공합니다. 그들의 블로그와 보고서는 읽을 가치가 충분하며, 새로운 취약점과 그 작동 원리를 배우는 것은 매우 흥미로운 일입니다.

보안 코딩 역량을 한 단계 더 높이기 위해서는 일반적인 취약점을 찾는 것뿐만 아니라(특히 흥미로운 신규 취약점은 악의적인 공격자들이 데이터를 탈취하기 위해 가장 먼저 노리는 표적이 됩니다), 이를 안전하게 직접 실습하며 악용 원리를 이해할 수 있는 환경을 갖추는 것이 매우 중요합니다.

자, 이제 바로 시작해 봅시다. 대소문자 매핑 충돌이 어떻게 악용될 수 있는지, 실시간으로 어떤 모습인지, 그리고 보안 연구원의 관점에서 직접 시도해 보는 방법을 계속해서 확인해 보세요.

지금 바로 대소문자 매핑 충돌을 실습해 볼 준비가 되셨나요? 시작해 봅시다:

유니코드: 복잡하고 무한히 확장 가능하며, 단순한 이모지 그 이상

'유니코드'라는 용어가 일반인들에게는 생소할지 모르지만, 대부분의 사람들은 매일 어떤 형태로든 이를 사용하고 있습니다. 웹 브라우저나 Microsoft 소프트웨어를 사용하거나 이모지를 보낸 적이 있다면, 이미 유니코드를 밀접하게 접하고 있는 셈입니다. 유니코드는 전 세계 대부분의 문자 체계를 일관되게 인코딩하고 처리하기 위한 표준으로, 누구나 단일 문자 집합을 사용하여 디지털 환경에서 자신을 표현할 수 있도록 합니다. 현재 143,000개 이상의 문자가 포함되어 있어 아이슬란드어, 터키어의 점 없는 i 등 어떤 언어를 사용하든 문제없습니다.

유니코드에 포함된 방대한 문자 수 때문에, 문자를 다른 '동등한' 문자로 변환해야 하는 경우가 많습니다. 예를 들어, 점 없는 i가 포함된 유니코드 문자열을 ASCII로 변환하면 단순히 "i"로 바뀌어야 하는 것이 당연해 보이지 않나요?

방대한 문자 인코딩에는 재앙의 씨앗이 숨어 있습니다

유니코드의 대소문자 매핑 충돌은 비즈니스 로직 결함이며, 근본적으로 2단계 인증(2FA)이 설정되지 않은 계정의 탈취로 이어질 수 있습니다. 이 취약점을 설명하기 위해 실제 코드 조각을 예로 들어보겠습니다:

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

로직은 대략 다음과 같습니다:

1. 사용자가 제공한 이메일 주소를 받아 일관성을 위해 대문자로 변환합니다.
2. 데이터베이스에 해당 이메일 주소가 존재하는지 확인합니다.
3. 존재할 경우 임시 비밀번호를 설정합니다(참고로 이는 모범 사례가 아닙니다. 대신 토큰이 포함된 링크를 사용하여 비밀번호를 재설정하도록 해야 합니다).
4. 1단계에서 가져온 주소로 임시 비밀번호가 포함된 이메일을 발송합니다(이는 여러 가지 이유로 매우 좋지 않은 방식입니다. 위험합니다).

원문 블로그 게시물에 제공된 예시에서 어떤 일이 일어나는지 살펴보겠습니다. 사용자가 John@GıtHub.com(터키어 점 없는 i에 유의)이라는 이메일로 비밀번호 재설정을 요청하는 경우입니다.

1. 로직은 John@Gıthub.com을 JOHN@GITHUB.COM으로 변환합니다.
2. 데이터베이스에서 이를 조회하여 사용자 JOHN@GITHUB.COM을 찾습니다.
3. 새 비밀번호를 생성하여 John@Gıthub.com으로 전송합니다.

이 과정에서 매우 민감한 이메일이 잘못된 주소로 전송된다는 점에 유의하세요. 이런!

이 유니코드 악마를 퇴치하는 방법

이 특정 취약점의 흥미로운 점은 여러 요인이 복합적으로 작용하여 취약성을 만든다는 것입니다.

1. 실제 유니코드 변환 동작
2. 데이터베이스에 이미 존재하는 이메일 주소가 아닌, 사용자가 제공한 이메일 주소를 사용하도록 결정하는 로직입니다.

이론적으로 Wisdom의 블로그 게시물에서 확인된 바와 같이, 이 특정 문제를 해결하는 방법은 두 가지가 있습니다.

1. 이메일을 퓨니코드(Punycode) 변환
2. 을 통해 ASCII로 변환하거나, 사용자가 제공한 주소 대신 데이터베이스에 저장된 이메일 주소를 사용하세요.

소프트웨어 보안을 강화할 때는 요행을 바라지 말고 가능한 한 많은 방어 계층을 구축하는 것이 좋습니다. 우리가 아직 알지 못하는 다른 인코딩 공격 방식이 존재할지도 모릅니다. 위험을 줄이고 공격자에게 열려 있을 수 있는 틈을 차단하기 위해 할 수 있는 모든 조치는 가치가 있습니다.

직접 시도해 볼 준비가 되셨나요?

대부분의 개발자는 데이터 유출이 비즈니스에 치명적이라는 사실을 알고 있습니다. 하지만 보안 의식을 갖춘 엔지니어는 증가하는 취약점, 침해 사고, 사이버 보안 문제에 대한 강력한 해독제입니다.

이제 보안 코딩과 인식 능력을 한 단계 더 끌어올릴 때입니다. 몰입형 안전 시뮬레이션에서 이 GitHub 취약점을 직접 경험하며 프론트엔드와 백엔드 환경 모두에서 잘못된 코드가 미치는 영향을 확인해 보세요. 공격자들은 이미 우위를 점하고 있습니다. 이제 화이트햇의 반격으로 실질적인 기술을 적용하여 공정한 경쟁의 장을 만들어 봅시다.