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

2015년부터 전 세계 개발자들에게 보안에 대한 적극적이고 긍정적인 접근 방식을 통해 코드를 보호하고, 재작업 과 수정을 줄이며, 보안 팀을 재미있는 경찰이 아닌 다른 것으로 볼 수 있도록 돕고 있습니다.

우리는 여전히 은하계 전역에서 코드를 확보함에 따라 개발자와 나란히 서기 위해 최선을 다하고 있지만, 전투를 강화하고 보안 인식 개발자를 다음 단계로 끌어 올릴 때입니다.

새로운 기능 출시를 발표하게 되어 기쁩니다. Secure Code Warrior 플랫폼: Missions . 이 새로운 챌린지 범주는 개발자가 정한 보안 교육의 다음 단계로, 사용자를 보안 지식 의 리콜에서 실제 시뮬레이션 환경에 적용하는 것으로 이동합니다. 이 비계, 마이크로 러닝 접근 방식은 작업 과 관련된 강력한 안전한 코딩 기술을 구축, 훨씬 더 재미있는보다 (수직적으로) 근무의 배경에 끝없는 교육 비디오를보고.

우리의 첫 번째 플레이, 공공 임무는 GitHub 유니코드 위반의 시뮬레이션입니다. 그것은 현혹 간단 보일 수 있습니다., 하지만 그것은 해부 하는 재미 정말 영리한 취약점. 보안 연구원 0xsha는 이 동일한 버그가 사례 변환을 통해 장고를 악용하는 데 어떻게 사용될 수 있는지에 대한 포괄적인 사례 연구를 하는 동시에 프로그래밍 언어 간에 취약점 동작이 어떻게 변할 수 있는지를 밝혔습니다. 이 보안 문제에 대해 더 많은 것을 발견할 수 있으며, 우리의 임무는 시작하기에 좋은 장소입니다.

GitHub의 정면(사례 매핑) 충돌

2019년 11월 28일 블로그 게시물에서 보안 연구 그룹 지혜는 GitHub에서 발견한 보안 버그에 대해 보고했습니다. 그들은 유니코드에서 사례 매핑 충돌을 사용하여 잘못된 이메일 주소로 암호 재설정 전자 메일 전송을 트리거할 수 있는 방법을 설명했습니다(또는 공격자처럼 생각하고 있는 경우 위협 행위자가 선택한 이메일 주소).

보안 취약점은 결코 좋은 소식이 아니지만, 화이트햇을 흔들보안 연구원들은 코드베이스에서 잠재적으로 악용가능한 오류를 발견하면 재해를 피할 수 있는 기회는 말할 것도 없고 자비를 제공합니다. 그들의 블로그와 보고서는 종종 훌륭한 독서를 위해 만들고, 새로운 취약점과 그것이 어떻게 작동하는지에 대해 배우는 것은 멋지다.

보안 코딩 기량의 다음 단계로 이동하기 위해, 그것은 단지 일반적인 취약점을 찾을 수 없습니다 (특히 멋진 새로운 것 - 우리 모두는 악의적 인 위협 배우가 이러한 새로운 기술로 일부 데이터를 발굴하는 비옥한 땅을 찾고있을 것입니다 알고) 뿐만 아니라 그들을 악용하는 방법을 이해하는 안전, 실습 환경을 가지고.

그래서, 그냥 그렇게 할 수 있습니다. 유니코드의 케이스 매핑 충돌이 어떻게 악용되는지, 실시간으로 어떻게 보이는지, 보안 연구원의 사고 방식을 어떻게 활용할 수 있는지 알아보려면 계속 읽으십시오.

지금 케이스 매핑 충돌에 걸릴 준비가 되셨습니까? 바로 단계:

유니코드: 복잡하고 끝없이 사용자 정의 할 수 있으며 이모티콘 그 이상

"유니코드"는 보통 사람의 어휘에 있지 않을 수 있지만 대부분의 사람들이 매일 어떤 형태로 든 사용할 가능성이 높습니다. 웹 브라우저, Microsoft 소프트웨어 또는 이모티콘을 사용한 경우 유니코드와 친밀하고 친분적입니다. 전 세계 대부분의 작사 시스템에서 텍스트를 일관되게 인코딩하고 처리하는 표준으로, 모두가 단일 문자 세트를 사용하여 (디지털 방식으로) 자신을 표현할 수 있도록 합니다. 143,000자 이상이 기재되어 있기 때문에 아이슬란드인이든 터키점도 사용하지 않든, 그 사이에 는 무엇이든 다루고 있습니다.

유니코드가 세트에 있는 문자의 양이 많기 때문에 캐릭터를 다른 "동등한" 캐릭터로 변환하는 방법이 많은 경우에 필요합니다. 예를 들어, 점없는 유니코드 문자열을 ASCII로 변환하면 단순히 "i"로 바뀌어야한다는 것이 합리적일 것으로 보입니다.

문자 인코딩의 큰 볼륨으로 재해에 대한 큰 잠재력을 온다

유니코드의 사례 매핑 충돌은 비즈니스 논리 결함이며 핵심은 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 JOHN@GITHUB.COM thub.com 변환
2. 데이터베이스에서 위로 보이는 사용자가 JOHN@GITHUB.COM
3. 새 암호를 생성하고 John@G thub.com

이 프로세스는 매우 민감한 이메일을 잘못된 전자 메일 주소로 전송하게 됩니다. 이런!

이 유니 코드 악마를 캐스팅하는 방법

이 특정 취약점의 흥미로운 측면은 취약하게 만드는 여러 가지 요인이 있다는 것입니다.

1. 실제 유니코드 캐스팅 동작
2. 사용할 전자 메일 주소(예: 데이터베이스)에 이미 존재하는 이메일 주소 대신 사용할 전자 메일 주소를 결정하는 논리입니다.

이론적으로 지혜의 블로그 게시물에 식별된 두 가지 방법으로 이 특정 문제를 해결할 수 있습니다.

1. Punycode 변환을 통해 이메일을 ASCII로 변환
2. 사용자가 제공한 이메일 주소가 아닌 데이터베이스의 전자 메일 주소를 사용합니다.

소프트웨어를 강화하는 데 있어 가능한 한 많은 방어 층을 사용하여 우연히 아무것도 남기지 않는 것이 좋습니다. 우리가 아는 모든, 이 인코딩을 악용하는 다른 방법이있을 수 있습니다 - 우리는 아직 그들을 인식하지 못하고 있습니다. 위험을 줄이고 공격자에게 열려 있을 수 있는 창을 닫기 위해 할 수 있는 모든 일은 유용합니다.

직접 이것을 시도 할 준비가 되셨습니까?

대부분의 개발자는 손상된 데이터가 비즈니스에 좋지 않은 다는 것을 알고 있습니다. 그러나 보안 인식 엔지니어는 증가하는 취약점, 침해 및 사이버 보안 불황에 대한 강력한 해독제입니다.

보안 코딩 및 인식 기술을 다음 단계로 끌어올릴 시간입니다. 프런트 엔드 및 백엔드 컨텍스트 모두에서 잘못된 코드가 미치는 영향을 볼 수 있는 몰입형 안전한 시뮬레이션에서 이 GitHub 취약점을 경험하십시오. 공격자는 장점이 있으므로 경기장도 만들고 화이트햇 카운터 펀치로 실제 기술을 적용합시다.