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