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