트로이 소스는 무엇이며 소스 코드에 어떻게 몰래 들어가는가?
11 월 초에, 케임브리지 대학은 트로이 목마 소스라는 자신의 연구를 발표했다. 이 연구는 방향 서식 문자를 사용하여 백도어를 소스 코드 및 주석에 숨길 수있는 방법에 초점을 맞추지 했습니다. 이러한 논리는 컴파일러가 인간 코드 검토자보다 다르게 해석되는 코드를 만드는 데 사용할 수 있습니다.
유니코드가 파일 이름의 마지막 부분의 방향을 반전하여 파일의 실제 파일 이름 확장을 숨기는 등 과거에 사심하게 사용되었지만 이 취약점은 새 입니다. 최근 연구에 따르면 많은 컴파일러가 경고 없이 소스 코드의 유니코드 문자를 무시하는 반면 코드 편집기를 포함한 텍스트 편집기는 이를 기반으로 주석과 코드가 포함된 줄을 리플로우할 수 있습니다. 따라서 편집기는 코드와 주석을 다르게 표시할 수 있으며 컴파일러가 코드와 주석을 교환하는 방식과 다른 순서로 표시할 수 있습니다.
자세한 내용을 알아보기 위해 계속 읽으십시오. 또는 소매를 걷어 붙이고 트로이 목마 소스의 시뮬레이션 해킹을 시도하려면 자유롭고 공공적인 임무에 뛰어 들어 직접 경험하십시오.
양방향 텍스트
이러한 트로이 목마-소스 공격 중 하나는 영어(왼쪽에서 오른쪽) 및 아랍어(오른쪽에서 왼쪽)와 같은 다른 표시 순서로 텍스트를 결합하는 방법을 처리하는 유니코드 비디(양방향) 알고리즘을 사용합니다. 방향 서식 문자를 사용하여 그룹화를 재구성하고 문자 순서를 표시할 수 있습니다.
위의 테이블에는 공격과 관련된 Bidi 재정의 문자가 포함되어 있습니다. 예를 들어,
RLI e d o c PDI
약어 RLI는 오른쪽에서 왼쪽 분리를 의미합니다. 텍스트를 컨텍스트(PDI, 팝-디렉션-격리)에서 분리하고 오른쪽에서 왼쪽으로 읽습니다. 그 결과:
c o d e
그러나 컴파일러와 인터프리터는 일반적으로 원본 코드를 구문 분석하기 전에 Bidi 재정의를 비롯한 제어 문자서 지정을 처리하지 않습니다. 방향 서식 문자를 무시하면 구문 분석됩니다.
e d o c
새로운 병에 오래된 와인?
물론, 이것은 태양 아래 새로운 아무것도. 과거에는 악의적인 특성을 위장하기 위해 파일 이름에 방향 서식 문자를 삽입했습니다. 'myspecialexexe.doc'로 표시된 이메일 첨부 파일은 'myspecialcod.exe'라는 실명을 드러내는 RLO(오른쪽에서 왼쪽 에 대한 재정의) 캐릭터가 아니라면 충분히 무고해 보일 수 있습니다.
트로이 메일 공격은 소스 코드에 있는 주석 및 문자열에 방향 서식 문자를 삽입합니다. 이러한 컨트롤 문자는 코드의 표시 순서를 변경하여 컴파일러가 인간과 완전히 다른 것을 읽게 합니다.
예를 들어 이 순서로 다음 바이트가 포함된 파일은 다음과 같은 경우 다음과 같은 경우
방향 서식 문자에 의해 다음과 같이 정렬됩니다.
방향 서식 문자를 명시적으로 호출하지 않으면 코드가 다음과 같이 렌더링됩니다.
RLO는 닫는 중괄호를 오프닝 중괄호로 뒤집고, 그 반대의 경우도 마찬가지입니다. 이 코드를 실행한 결과는 "관리자"입니다. 관리자 확인이 주석이 나왔지만 컨트롤 문자는 여전히 존재한다는 인상을 줍니다.
(출처: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
이것이 여러분에게 어떤 영향을 미칠 수 있는가?
C, C++, C#, 자바스크립트, 자바, 러스트, 이동 및 파이썬과 같은 많은 언어가 공격에 취약하며 더 많은 언어가 있다고 가정합니다. 이제 일반 개발자는 소스 코드에서 방향 성 서식 문자를 보고 눈살을 찌푸리게 할 수 있지만 초보자는 어깨를 으쓱하고 아무 생각도 하지 않을 수 있습니다. 또한 이러한 문자의 시각화는 IDE에 따라 매우 의존적이기 때문에 발견될 것이라는 보장은 없습니다.
그러나 이 취약점이 어떻게 처음에 소스 코드에 몰래 들어갈 수 있을까요? 무엇보다도 악의적인 코드 기여도가 눈에 띄지 않는 신뢰할 수 없는 소스에서 소스 코드를 사용할 때 이러한 문제가 발생할 수 있습니다. 둘째, 그것은 인터넷에서 발견 된 코드에서 간단한 복사 붙여 넣기에 의해 발생할 수 있습니다., 우리 개발자의 대부분은 전에 했던 뭔가. 대부분의 조직은 여러 공급업체의 소프트웨어 구성 요소에 의존합니다. 이것은 우리가 완전히 신뢰하고이 코드에 의존 할 수있는 정도에 질문을 제기? 숨겨진 백도어가 포함된 소스 코드를 어떻게 선별할 수 있습니까?
누구의 문제입니까?
한편으로는 컴파일러와 빌드 파이프라인은 한 방향이 문자열 및 주석으로 엄격하게 제한되지 않는 한 두 개 이상의 방향으로 소스 코드 줄을 허용하지 않아야 합니다. 문자열 또는 주석의 방향 서식 문자는 팝업되지 않은 경우 줄이 끝날 때까지 방향 변경을 확장할 수 있습니다. 일반적으로 코드 편집기는 동종 문자 및 방향 서식 문자와 같은 의심스러운 유니코드 문자를 명시적으로 렌더링하고 강조 표시해야 합니다. 11월부터 GitHub는 이제 양방향 유니코드 텍스트가 포함된 모든 코드 줄에 경고 표시와 메시지를 추가하지만 이러한 문자가 줄에 있는 위치를 강조표시하지는 않습니다. 이렇게 하면 악의적인 방향 변경 내용과 양호한 방향 변경이 허용될 수 있습니다.
개발자와 코드 검토자 간의 인식이 필수적이기 때문에 취약점을 설명하는 연습서를 만들었습니다. 현재 이 연습은 Java, C#, 파이썬, GO 및 PHP에서 사용할 수 있습니다.
그래서 당신은 더 알고 싶은 경우에, 우리의 시도 시뮬레이션(공개) missions) 트로이 소스의, 트로이 목마 소스 연구를 읽어보십시오.
Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
Laura Verheyde는 Secure Code Warrior 의 소프트웨어 개발자로서 취약점을 연구하고 Missions 및 코딩 연구소의 콘텐츠를 제작하는 데 주력하고 있습니다.
11 월 초에, 케임브리지 대학은 트로이 목마 소스라는 자신의 연구를 발표했다. 이 연구는 방향 서식 문자를 사용하여 백도어를 소스 코드 및 주석에 숨길 수있는 방법에 초점을 맞추지 했습니다. 이러한 논리는 컴파일러가 인간 코드 검토자보다 다르게 해석되는 코드를 만드는 데 사용할 수 있습니다.
유니코드가 파일 이름의 마지막 부분의 방향을 반전하여 파일의 실제 파일 이름 확장을 숨기는 등 과거에 사심하게 사용되었지만 이 취약점은 새 입니다. 최근 연구에 따르면 많은 컴파일러가 경고 없이 소스 코드의 유니코드 문자를 무시하는 반면 코드 편집기를 포함한 텍스트 편집기는 이를 기반으로 주석과 코드가 포함된 줄을 리플로우할 수 있습니다. 따라서 편집기는 코드와 주석을 다르게 표시할 수 있으며 컴파일러가 코드와 주석을 교환하는 방식과 다른 순서로 표시할 수 있습니다.
자세한 내용을 알아보기 위해 계속 읽으십시오. 또는 소매를 걷어 붙이고 트로이 목마 소스의 시뮬레이션 해킹을 시도하려면 자유롭고 공공적인 임무에 뛰어 들어 직접 경험하십시오.
양방향 텍스트
이러한 트로이 목마-소스 공격 중 하나는 영어(왼쪽에서 오른쪽) 및 아랍어(오른쪽에서 왼쪽)와 같은 다른 표시 순서로 텍스트를 결합하는 방법을 처리하는 유니코드 비디(양방향) 알고리즘을 사용합니다. 방향 서식 문자를 사용하여 그룹화를 재구성하고 문자 순서를 표시할 수 있습니다.
위의 테이블에는 공격과 관련된 Bidi 재정의 문자가 포함되어 있습니다. 예를 들어,
RLI e d o c PDI
약어 RLI는 오른쪽에서 왼쪽 분리를 의미합니다. 텍스트를 컨텍스트(PDI, 팝-디렉션-격리)에서 분리하고 오른쪽에서 왼쪽으로 읽습니다. 그 결과:
c o d e
그러나 컴파일러와 인터프리터는 일반적으로 원본 코드를 구문 분석하기 전에 Bidi 재정의를 비롯한 제어 문자서 지정을 처리하지 않습니다. 방향 서식 문자를 무시하면 구문 분석됩니다.
e d o c
새로운 병에 오래된 와인?
물론, 이것은 태양 아래 새로운 아무것도. 과거에는 악의적인 특성을 위장하기 위해 파일 이름에 방향 서식 문자를 삽입했습니다. 'myspecialexexe.doc'로 표시된 이메일 첨부 파일은 'myspecialcod.exe'라는 실명을 드러내는 RLO(오른쪽에서 왼쪽 에 대한 재정의) 캐릭터가 아니라면 충분히 무고해 보일 수 있습니다.
트로이 메일 공격은 소스 코드에 있는 주석 및 문자열에 방향 서식 문자를 삽입합니다. 이러한 컨트롤 문자는 코드의 표시 순서를 변경하여 컴파일러가 인간과 완전히 다른 것을 읽게 합니다.
예를 들어 이 순서로 다음 바이트가 포함된 파일은 다음과 같은 경우 다음과 같은 경우
방향 서식 문자에 의해 다음과 같이 정렬됩니다.
방향 서식 문자를 명시적으로 호출하지 않으면 코드가 다음과 같이 렌더링됩니다.
RLO는 닫는 중괄호를 오프닝 중괄호로 뒤집고, 그 반대의 경우도 마찬가지입니다. 이 코드를 실행한 결과는 "관리자"입니다. 관리자 확인이 주석이 나왔지만 컨트롤 문자는 여전히 존재한다는 인상을 줍니다.
(출처: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
이것이 여러분에게 어떤 영향을 미칠 수 있는가?
C, C++, C#, 자바스크립트, 자바, 러스트, 이동 및 파이썬과 같은 많은 언어가 공격에 취약하며 더 많은 언어가 있다고 가정합니다. 이제 일반 개발자는 소스 코드에서 방향 성 서식 문자를 보고 눈살을 찌푸리게 할 수 있지만 초보자는 어깨를 으쓱하고 아무 생각도 하지 않을 수 있습니다. 또한 이러한 문자의 시각화는 IDE에 따라 매우 의존적이기 때문에 발견될 것이라는 보장은 없습니다.
그러나 이 취약점이 어떻게 처음에 소스 코드에 몰래 들어갈 수 있을까요? 무엇보다도 악의적인 코드 기여도가 눈에 띄지 않는 신뢰할 수 없는 소스에서 소스 코드를 사용할 때 이러한 문제가 발생할 수 있습니다. 둘째, 그것은 인터넷에서 발견 된 코드에서 간단한 복사 붙여 넣기에 의해 발생할 수 있습니다., 우리 개발자의 대부분은 전에 했던 뭔가. 대부분의 조직은 여러 공급업체의 소프트웨어 구성 요소에 의존합니다. 이것은 우리가 완전히 신뢰하고이 코드에 의존 할 수있는 정도에 질문을 제기? 숨겨진 백도어가 포함된 소스 코드를 어떻게 선별할 수 있습니까?
누구의 문제입니까?
한편으로는 컴파일러와 빌드 파이프라인은 한 방향이 문자열 및 주석으로 엄격하게 제한되지 않는 한 두 개 이상의 방향으로 소스 코드 줄을 허용하지 않아야 합니다. 문자열 또는 주석의 방향 서식 문자는 팝업되지 않은 경우 줄이 끝날 때까지 방향 변경을 확장할 수 있습니다. 일반적으로 코드 편집기는 동종 문자 및 방향 서식 문자와 같은 의심스러운 유니코드 문자를 명시적으로 렌더링하고 강조 표시해야 합니다. 11월부터 GitHub는 이제 양방향 유니코드 텍스트가 포함된 모든 코드 줄에 경고 표시와 메시지를 추가하지만 이러한 문자가 줄에 있는 위치를 강조표시하지는 않습니다. 이렇게 하면 악의적인 방향 변경 내용과 양호한 방향 변경이 허용될 수 있습니다.
개발자와 코드 검토자 간의 인식이 필수적이기 때문에 취약점을 설명하는 연습서를 만들었습니다. 현재 이 연습은 Java, C#, 파이썬, GO 및 PHP에서 사용할 수 있습니다.
그래서 당신은 더 알고 싶은 경우에, 우리의 시도 시뮬레이션(공개) missions) 트로이 소스의, 트로이 목마 소스 연구를 읽어보십시오.
11 월 초에, 케임브리지 대학은 트로이 목마 소스라는 자신의 연구를 발표했다. 이 연구는 방향 서식 문자를 사용하여 백도어를 소스 코드 및 주석에 숨길 수있는 방법에 초점을 맞추지 했습니다. 이러한 논리는 컴파일러가 인간 코드 검토자보다 다르게 해석되는 코드를 만드는 데 사용할 수 있습니다.
유니코드가 파일 이름의 마지막 부분의 방향을 반전하여 파일의 실제 파일 이름 확장을 숨기는 등 과거에 사심하게 사용되었지만 이 취약점은 새 입니다. 최근 연구에 따르면 많은 컴파일러가 경고 없이 소스 코드의 유니코드 문자를 무시하는 반면 코드 편집기를 포함한 텍스트 편집기는 이를 기반으로 주석과 코드가 포함된 줄을 리플로우할 수 있습니다. 따라서 편집기는 코드와 주석을 다르게 표시할 수 있으며 컴파일러가 코드와 주석을 교환하는 방식과 다른 순서로 표시할 수 있습니다.
자세한 내용을 알아보기 위해 계속 읽으십시오. 또는 소매를 걷어 붙이고 트로이 목마 소스의 시뮬레이션 해킹을 시도하려면 자유롭고 공공적인 임무에 뛰어 들어 직접 경험하십시오.
양방향 텍스트
이러한 트로이 목마-소스 공격 중 하나는 영어(왼쪽에서 오른쪽) 및 아랍어(오른쪽에서 왼쪽)와 같은 다른 표시 순서로 텍스트를 결합하는 방법을 처리하는 유니코드 비디(양방향) 알고리즘을 사용합니다. 방향 서식 문자를 사용하여 그룹화를 재구성하고 문자 순서를 표시할 수 있습니다.
위의 테이블에는 공격과 관련된 Bidi 재정의 문자가 포함되어 있습니다. 예를 들어,
RLI e d o c PDI
약어 RLI는 오른쪽에서 왼쪽 분리를 의미합니다. 텍스트를 컨텍스트(PDI, 팝-디렉션-격리)에서 분리하고 오른쪽에서 왼쪽으로 읽습니다. 그 결과:
c o d e
그러나 컴파일러와 인터프리터는 일반적으로 원본 코드를 구문 분석하기 전에 Bidi 재정의를 비롯한 제어 문자서 지정을 처리하지 않습니다. 방향 서식 문자를 무시하면 구문 분석됩니다.
e d o c
새로운 병에 오래된 와인?
물론, 이것은 태양 아래 새로운 아무것도. 과거에는 악의적인 특성을 위장하기 위해 파일 이름에 방향 서식 문자를 삽입했습니다. 'myspecialexexe.doc'로 표시된 이메일 첨부 파일은 'myspecialcod.exe'라는 실명을 드러내는 RLO(오른쪽에서 왼쪽 에 대한 재정의) 캐릭터가 아니라면 충분히 무고해 보일 수 있습니다.
트로이 메일 공격은 소스 코드에 있는 주석 및 문자열에 방향 서식 문자를 삽입합니다. 이러한 컨트롤 문자는 코드의 표시 순서를 변경하여 컴파일러가 인간과 완전히 다른 것을 읽게 합니다.
예를 들어 이 순서로 다음 바이트가 포함된 파일은 다음과 같은 경우 다음과 같은 경우
방향 서식 문자에 의해 다음과 같이 정렬됩니다.
방향 서식 문자를 명시적으로 호출하지 않으면 코드가 다음과 같이 렌더링됩니다.
RLO는 닫는 중괄호를 오프닝 중괄호로 뒤집고, 그 반대의 경우도 마찬가지입니다. 이 코드를 실행한 결과는 "관리자"입니다. 관리자 확인이 주석이 나왔지만 컨트롤 문자는 여전히 존재한다는 인상을 줍니다.
(출처: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
이것이 여러분에게 어떤 영향을 미칠 수 있는가?
C, C++, C#, 자바스크립트, 자바, 러스트, 이동 및 파이썬과 같은 많은 언어가 공격에 취약하며 더 많은 언어가 있다고 가정합니다. 이제 일반 개발자는 소스 코드에서 방향 성 서식 문자를 보고 눈살을 찌푸리게 할 수 있지만 초보자는 어깨를 으쓱하고 아무 생각도 하지 않을 수 있습니다. 또한 이러한 문자의 시각화는 IDE에 따라 매우 의존적이기 때문에 발견될 것이라는 보장은 없습니다.
그러나 이 취약점이 어떻게 처음에 소스 코드에 몰래 들어갈 수 있을까요? 무엇보다도 악의적인 코드 기여도가 눈에 띄지 않는 신뢰할 수 없는 소스에서 소스 코드를 사용할 때 이러한 문제가 발생할 수 있습니다. 둘째, 그것은 인터넷에서 발견 된 코드에서 간단한 복사 붙여 넣기에 의해 발생할 수 있습니다., 우리 개발자의 대부분은 전에 했던 뭔가. 대부분의 조직은 여러 공급업체의 소프트웨어 구성 요소에 의존합니다. 이것은 우리가 완전히 신뢰하고이 코드에 의존 할 수있는 정도에 질문을 제기? 숨겨진 백도어가 포함된 소스 코드를 어떻게 선별할 수 있습니까?
누구의 문제입니까?
한편으로는 컴파일러와 빌드 파이프라인은 한 방향이 문자열 및 주석으로 엄격하게 제한되지 않는 한 두 개 이상의 방향으로 소스 코드 줄을 허용하지 않아야 합니다. 문자열 또는 주석의 방향 서식 문자는 팝업되지 않은 경우 줄이 끝날 때까지 방향 변경을 확장할 수 있습니다. 일반적으로 코드 편집기는 동종 문자 및 방향 서식 문자와 같은 의심스러운 유니코드 문자를 명시적으로 렌더링하고 강조 표시해야 합니다. 11월부터 GitHub는 이제 양방향 유니코드 텍스트가 포함된 모든 코드 줄에 경고 표시와 메시지를 추가하지만 이러한 문자가 줄에 있는 위치를 강조표시하지는 않습니다. 이렇게 하면 악의적인 방향 변경 내용과 양호한 방향 변경이 허용될 수 있습니다.
개발자와 코드 검토자 간의 인식이 필수적이기 때문에 취약점을 설명하는 연습서를 만들었습니다. 현재 이 연습은 Java, C#, 파이썬, GO 및 PHP에서 사용할 수 있습니다.
그래서 당신은 더 알고 싶은 경우에, 우리의 시도 시뮬레이션(공개) missions) 트로이 소스의, 트로이 목마 소스 연구를 읽어보십시오.
아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
Laura Verheyde는 Secure Code Warrior 의 소프트웨어 개발자로서 취약점을 연구하고 Missions 및 코딩 연구소의 콘텐츠를 제작하는 데 주력하고 있습니다.
11 월 초에, 케임브리지 대학은 트로이 목마 소스라는 자신의 연구를 발표했다. 이 연구는 방향 서식 문자를 사용하여 백도어를 소스 코드 및 주석에 숨길 수있는 방법에 초점을 맞추지 했습니다. 이러한 논리는 컴파일러가 인간 코드 검토자보다 다르게 해석되는 코드를 만드는 데 사용할 수 있습니다.
유니코드가 파일 이름의 마지막 부분의 방향을 반전하여 파일의 실제 파일 이름 확장을 숨기는 등 과거에 사심하게 사용되었지만 이 취약점은 새 입니다. 최근 연구에 따르면 많은 컴파일러가 경고 없이 소스 코드의 유니코드 문자를 무시하는 반면 코드 편집기를 포함한 텍스트 편집기는 이를 기반으로 주석과 코드가 포함된 줄을 리플로우할 수 있습니다. 따라서 편집기는 코드와 주석을 다르게 표시할 수 있으며 컴파일러가 코드와 주석을 교환하는 방식과 다른 순서로 표시할 수 있습니다.
자세한 내용을 알아보기 위해 계속 읽으십시오. 또는 소매를 걷어 붙이고 트로이 목마 소스의 시뮬레이션 해킹을 시도하려면 자유롭고 공공적인 임무에 뛰어 들어 직접 경험하십시오.
양방향 텍스트
이러한 트로이 목마-소스 공격 중 하나는 영어(왼쪽에서 오른쪽) 및 아랍어(오른쪽에서 왼쪽)와 같은 다른 표시 순서로 텍스트를 결합하는 방법을 처리하는 유니코드 비디(양방향) 알고리즘을 사용합니다. 방향 서식 문자를 사용하여 그룹화를 재구성하고 문자 순서를 표시할 수 있습니다.
위의 테이블에는 공격과 관련된 Bidi 재정의 문자가 포함되어 있습니다. 예를 들어,
RLI e d o c PDI
약어 RLI는 오른쪽에서 왼쪽 분리를 의미합니다. 텍스트를 컨텍스트(PDI, 팝-디렉션-격리)에서 분리하고 오른쪽에서 왼쪽으로 읽습니다. 그 결과:
c o d e
그러나 컴파일러와 인터프리터는 일반적으로 원본 코드를 구문 분석하기 전에 Bidi 재정의를 비롯한 제어 문자서 지정을 처리하지 않습니다. 방향 서식 문자를 무시하면 구문 분석됩니다.
e d o c
새로운 병에 오래된 와인?
물론, 이것은 태양 아래 새로운 아무것도. 과거에는 악의적인 특성을 위장하기 위해 파일 이름에 방향 서식 문자를 삽입했습니다. 'myspecialexexe.doc'로 표시된 이메일 첨부 파일은 'myspecialcod.exe'라는 실명을 드러내는 RLO(오른쪽에서 왼쪽 에 대한 재정의) 캐릭터가 아니라면 충분히 무고해 보일 수 있습니다.
트로이 메일 공격은 소스 코드에 있는 주석 및 문자열에 방향 서식 문자를 삽입합니다. 이러한 컨트롤 문자는 코드의 표시 순서를 변경하여 컴파일러가 인간과 완전히 다른 것을 읽게 합니다.
예를 들어 이 순서로 다음 바이트가 포함된 파일은 다음과 같은 경우 다음과 같은 경우
방향 서식 문자에 의해 다음과 같이 정렬됩니다.
방향 서식 문자를 명시적으로 호출하지 않으면 코드가 다음과 같이 렌더링됩니다.
RLO는 닫는 중괄호를 오프닝 중괄호로 뒤집고, 그 반대의 경우도 마찬가지입니다. 이 코드를 실행한 결과는 "관리자"입니다. 관리자 확인이 주석이 나왔지만 컨트롤 문자는 여전히 존재한다는 인상을 줍니다.
(출처: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
이것이 여러분에게 어떤 영향을 미칠 수 있는가?
C, C++, C#, 자바스크립트, 자바, 러스트, 이동 및 파이썬과 같은 많은 언어가 공격에 취약하며 더 많은 언어가 있다고 가정합니다. 이제 일반 개발자는 소스 코드에서 방향 성 서식 문자를 보고 눈살을 찌푸리게 할 수 있지만 초보자는 어깨를 으쓱하고 아무 생각도 하지 않을 수 있습니다. 또한 이러한 문자의 시각화는 IDE에 따라 매우 의존적이기 때문에 발견될 것이라는 보장은 없습니다.
그러나 이 취약점이 어떻게 처음에 소스 코드에 몰래 들어갈 수 있을까요? 무엇보다도 악의적인 코드 기여도가 눈에 띄지 않는 신뢰할 수 없는 소스에서 소스 코드를 사용할 때 이러한 문제가 발생할 수 있습니다. 둘째, 그것은 인터넷에서 발견 된 코드에서 간단한 복사 붙여 넣기에 의해 발생할 수 있습니다., 우리 개발자의 대부분은 전에 했던 뭔가. 대부분의 조직은 여러 공급업체의 소프트웨어 구성 요소에 의존합니다. 이것은 우리가 완전히 신뢰하고이 코드에 의존 할 수있는 정도에 질문을 제기? 숨겨진 백도어가 포함된 소스 코드를 어떻게 선별할 수 있습니까?
누구의 문제입니까?
한편으로는 컴파일러와 빌드 파이프라인은 한 방향이 문자열 및 주석으로 엄격하게 제한되지 않는 한 두 개 이상의 방향으로 소스 코드 줄을 허용하지 않아야 합니다. 문자열 또는 주석의 방향 서식 문자는 팝업되지 않은 경우 줄이 끝날 때까지 방향 변경을 확장할 수 있습니다. 일반적으로 코드 편집기는 동종 문자 및 방향 서식 문자와 같은 의심스러운 유니코드 문자를 명시적으로 렌더링하고 강조 표시해야 합니다. 11월부터 GitHub는 이제 양방향 유니코드 텍스트가 포함된 모든 코드 줄에 경고 표시와 메시지를 추가하지만 이러한 문자가 줄에 있는 위치를 강조표시하지는 않습니다. 이렇게 하면 악의적인 방향 변경 내용과 양호한 방향 변경이 허용될 수 있습니다.
개발자와 코드 검토자 간의 인식이 필수적이기 때문에 취약점을 설명하는 연습서를 만들었습니다. 현재 이 연습은 Java, C#, 파이썬, GO 및 PHP에서 사용할 수 있습니다.
그래서 당신은 더 알고 싶은 경우에, 우리의 시도 시뮬레이션(공개) missions) 트로이 소스의, 트로이 목마 소스 연구를 읽어보십시오.
.png)
