실재로 확인은 안해봤는데요. 오픈소스 시대가 되어 있을 수 있는 전수되는 해킹 방법이 있는 것 같습니다.
한 예로, 오픈소스에 참여한 사람의 개인정보를 탈취해서 그 사람 PC에 어떤 방법이든 접근해서 메모리 인젝션이 일어나게 하는 경우가 있는데요. 정상적인 URL에 웹브라우저가 접속 요청을 내리면, 내리는 순간, 메모리에 인젝션된 정보대로 그 사람이 참여하는 오픈소스 소스코드에 변경을 몰래 가하는 것이 가능한 것 같애요. 그러면 응용하기에 따라 오픈소스 저장소에 소스코드 변경 사항이 기록도 안되고 바뀌어서 문제가 일어나고나서야 발견을 하는 경우가 있네요. 기록이 남아도, 해킹받은 개발자가 남긴 것처럼 보이구요.
이와 유사한 경우, 해킹받은 분이 오픈소스 개발자는 아니더라도 누군가 해킹을 할때, 단체로 100명 정도가 특정 코드에 버그가 있다고 보고하게 되는 일이 있을 수 있죠. 여러 유형의 단체가 있겠지만 숙주처럼 된 경우에 해당하구요. 100명이 보고한 문제라 버그라고 확신해서 개발자가 그 버그를 고칠때 누군가 했던 메모리 인젝션이 영향을 줘서 다른 정상적인 PC에서는 오작동을 하는 것. 본래의 보고된 버그가 고쳐져도 다른 문제가 일어나는 경우에 의심할만 합니다.
전에 스펙터 공격이나 멜트다운 공격을 패치하고나서 성능이 낮아지는게 현저했던 것도 버그가 고쳐져도 다른 문제가 일어나는 경우인데요. 위의 경우 메모리 인젝션을 원천적으로 막을 수 없는 구조 문제와 같고, 패치하고나서 다른 문제가 생기는 것과 유사한 사례 같애요. 현상은 다르더라두요.
제가 말하는 핵심은 개인 정보 탈취, 메모리 인젝션, 다른 요청을 오픈소스 저장소에 날리기, 단체 보고인데요.
이와 복합적인 조건으로 소스코드의 방대함도 겹치는 것 같애요. 사용자 PC에서 실행된 것과 오픈소스 소스코드가 방대하고 방법적으로 여러 소스코드로 나누어져 있으면 해킹이라고 발견해내기가 애매하게 되죠. 시간이 지나서 발견되구요.
이런 해킹 방법이 전수되는 경우가 있는 것 같구요. 악성코드가 쓰여도 악성코드를 감지한 안티바이러스가 커버못하는 기술이 남아있다거나, 악성코드 없어도 접속이 되게 하는 기술력이 있는 경우, 악성코드가 삭제되면 보통 방심하게 되는 심리도 이용되는 것 같애요. (이를 응용하면 해킹후 업데이트 설치해주기와 같이 변용되기도 합니다)
이런 해킹 방법을 툴써서 확인은 못했는데, 강하게 이런 방법이 쓰인 것이 의심되는 경우가 있어요.
개발자가 메모리 덤프 확인을 했다고 해도 메모리 인젝션된 것이 발견이 안되게 교묘하게 인젝션이 되면 위에 언급한 오픈소스 특성과 맞물려서 해킹이 되는 것 같애요.
이 글 전에 쓴 글이 이해가 더 쉬운데, 몇대목에서 해킹 주체를 헷갈리게 써놔서 다시 씁니다 ^^
오픈소스가 대중화되어 이제는 많은 프로젝트가 소스코드를 공개해서 집단지성으로 발전해가는 체제가 되었습니다. 도커와 같은 사례처럼 누구나 참여해서 작업을 잘 할 수 있도록 돕는 체제도 있죠. 그런데 이러한 발전상의 이면에는 오픈소스 시대의 해킹 기법이 존재하기도 하네요.
어떠한 기술이든 개발 초창기와 다른 유형의 해킹 기술이 개발되기도 합니다. 암호화된 데이터를 탈취하는 방법이 여럿 있구요. 무엇보다도 이를 방지하는 기술에 대해서도 오픈소스일때 (또는 특수한 경우 오픈소스가 아니더라도 해킹의 가능성은 늘 존재하지만) 사용자 보고의 형식을 토대로 소스코드에 변경을 가하는 경우도 있는 것 같애요.
보통 하드웨어나 프로그래밍을 하게 해주는 API나 SDK들은 보수적으로 업데이트가 되었습니다. 너무 급격한 변화는 사람들에게 혼란을 주기도 하고 너무 빠른 대처는 미처 생각치못한 오류를 동반하기도 해서네요. 가벼운 경우는 STM32 계열의 IDE와 SDK의 변경이고, 심각한 경우는 제가 지금 소개하는 기법인데요.
오픈소스에 접근가능한 프로젝트 참여자의 PC를 해킹하지 않더라도, 문제 보고의 정식화된 형태에 의해서는 문제를 야기하는 코드로 업데이트를 하게 하는 경우가 있습니다. 보통 버그 보고는 프로젝트 참여자들이 순수하게 생각하는 대상이라, 이를 사전에 알기도 어렵고, 알더라도 현상으로 나타나는 표현에 의존하게 되기에 정말로 사전에 강력하게 표현을 구성하면 프로젝트 참여자들이 수용해서 코드를 고칠때, 이에 의해 다른 문제가 발생하게 되는 경우입니다. 이 경우 고친 실행을 한 주체가 문제시되네요.
이 경우에 보조조건은 특정한 작동을 유발하는 트리거가 정의롭게 고친 버그 패치에 의해서도 일으켜진다는 것인데요. 심리적으로 보면 버그 패치는 사용자에 대한 존중이고, 이를 고친 것이 정의로움이라, 프로젝트 참여자분들도 나중에 알게 되면 같이 당하게 되서 문제가 큽니다.
이 경우 프로젝트 사용자들이 성토하면 프로젝트 존립 자체도 큰 문제가 일으켜지죠. 특별히 제품이면 더 그러합니다.
마치 인터넷 업체들이 해킹받아 이슈가 될때 저희도 피해자입니다라고 말하면 큰일나는 것과 같애요.
인지과학에서는 이러한 판단에 대해 보조조건들이 여럿 일어나서 결정조건을 만든다고 하기도 하는데요. 보통 과학적이라는 인식의 전제는 논리적이어야 한다는 것이고, 한번에 하나만 생각하게 하는 조건에 의해서는 복잡하게 얽힌데 대해 “복잡하게 얽혔다”라고만 말하게 하고 지나가는데요. 위의 조건처럼 프로젝트 참여자들의 공감능력에 의해 보조조건이 성립하는 경우, 정말로 악랄한 시도에 대해 인식이 잘못 이루어지게 됩니다.
한국에서도 있게 되는 일 같애요.
그리고 이런 것들이 알려지면 역이용하는 것도 가능할 것입니다.
이러한 것들이 기록에 남으면 논리만 남기에 역전이 되기도 하네요. 그리고 프로젝트가 정말로 큰 영향력이 있었다면, “역사에는 가정이란 없다”라는 말과 같이 규범적인 효력이 있는 방향으로 이해가 쏠리면, 이후에 연구하시는 분들도 부담이 주어질 수밖에 없죠.
다른 말로 해킹이 이렇게도 되는 것이 순간적이고 우연인데, 이후에 보면 필연이 되는 보조조건이 있었을 것이라는 판단이네요.
이 경우에도 데이터 중시에 대해 도와주려는 분들도 골탕을 먹기도 하네요.
이런 것에 대해 역이용하는 것도 가능해서 문제가 큽니다.
이에 대한 대처의 한 방법은 공식적으로는 집단지성에 의해 문제가 없다고 된 현상 (예, MCU SDK에서 그냥 핀 번호만 SDK에 반영한 경우) 이 있었다면 뭔가 다른 큰 오류가 나게 하는 시도가 있었을지 판단해보는 것이네요. 이는 프로젝트 참여자분들이 프로젝트 구조를 잘 아시기에 채택하시면 정말로 큰 오류 유발 버그 보고를 탐지하는 방법이기도 할 것입니다.
한가지 예로, 있을 수 있다고 생각하지만 여러 조건에 의해 표현에 제한이 오면 근원이 달리 이해되는 것은
소프트웨어에 플러그인 생태계가 형성된 경우, 플러그인이 해킹받으면 플러그인 개발자가 처벌되어 다른 영향력있는 플러그인 개발자들이 처벌받은 개발진에 공감을 표명하면, 프로젝트 활성화 정도에 따라서는 커뮤니티 붕괴도 됩니다. 이게 안되는 평판이 있으면 안일어나지만요.
이 경우 소프트웨어 관리측과 플러그인 개발측이 다 피해자이구요. 피해받았다고 말하는게 프로젝트 자살 행위라, 안말하면 근원이 다르게 기록되기도 하네요.
현상적으로는 서로 싸운거라 이렇게 본다는게 이상하게도 보이는데, 처벌받은 플러그인 개발진이 강하게 성토해도 인정이 안되는 경우가 있네요. 이 경우에 작게는 버그 패치 후의 일이거나, 코드 자체를 해킹받은 것이 원인일 수가 있네요.
비지니스의 속성상 이런 것을 공개적으로 말하는게 어렵구요.
논쟁을 바라고 쓴 글은 아니구요. 이런 근원이 안알려지면 있게 되는 공식적인 이해는 피해자를 한명이라도 남겨두는 효과가 있다는 것입니다. 이는 심리적인 측면도 살펴보고 인과에 이어지는 당사자들의 사정을 보면 이해가 되네요.
위에 쓴 댓글처럼 대처가 가능하다고만 하면 아시는 분들은 이해해도, 이에 대해 아무것도 아니라고 인식하고 지나가는 경우도 있네요.
플러그인 개발과 관련해서 있었던 예가 있었는데, 플러그인 개발에 있어 누군가 경고를 받고 후속으로 있던 영향력 있는 다른 플러그인 개발진들이 경고를 내린 관리측과 분쟁이 있던 것이 예 같애요. 경고를 받은 플러그인이 의도한 작동이 아닌 해킹이 있어서 이를 사용자 권익을 지키려는 관리측이 강하게 처리를 했는데, 이게 버그 보고나 이에 준하는 소스코드 무단 변경이 일으킨 일 같기도 합니다. 이게 공식적인 판단이 아니라서 특정은 안하겠습니다. 개발진이나 관리측 모두가 피해자인 것 같애요. (물론 특정을 안하면 오해받을테지만요)