CentOS에서 바이너리가 자발적으로 변경되었습니다.

CentOS에서 바이너리가 자발적으로 변경되었습니다.

이것은 약간 걱정됩니다.아프다CentOS 6 서버에서 파일 및 디렉터리 변경 사항을 모니터링합니다. 바이너리 파일, 서버로 밀수되는 PHP 스크립트, 변경되는 구성 파일 등의 변경 사항을 감지하고 싶습니다. 이 작업은 매일 실행되며 감지된 변경 사항이 포함된 이메일을 받습니다. 일반적으로 여기에는 웹코드를 업데이트하거나 새 소프트웨어를 설치한 후의 로그 파일과 변경 사항만 포함됩니다. 오늘은 대박을 터뜨린 것 같았는데 잘 모르겠네요.

수백 개의 파일에 대한 MD5 체크섬이 변경되었지만 타임스탬프나 크기는 변경되지 않은 이메일을 받았습니다. 여기에는 와 같은 실행 /bin/gawk파일뿐만 아니라 /lib/libasound.so.2.0.0. 이 모든 일은 1월 1일 4시부터 1월 2일 4시 사이에 일어났습니다(영화는 4시에 실행됩니다).

테스트로 백업에서 /bin/gawk를 복원하고 수동 md5 체크섬을 실행했습니다. 실제로 파일이 변경되었습니다. 그러나 두 바이너리 간의 차이점은 다소 결론적이지 않습니다.

--- old.gawk.hex        2017-01-02 15:56:06.000000000 +0100
+++ new.gawk.hex        2017-01-02 15:56:14.000000000 +0100
@@ -881,12 +881,12 @@
 00003700  a6 03 00 00 00 00 00 00  d1 04 00 00 12 00 0d 00  |................|
 00003710  f0 6d 42 00 00 00 00 00  2a 10 00 00 00 00 00 00  |.mB.....*.......|
 00003720  01 00 00 00 b0 6b 5a 56  65 fd 1b 6d 00 00 00 00  |.....kZVe..m....|
-00003730  00 00 00 00 44 00 00 00  b0 6b 5a 56 b2 04 c4 e2  |....D....kZV....|
+00003730  00 00 00 00 44 00 00 00  56 e5 5d 58 82 a0 c7 cf  |....D...V.]X....|
 00003740  00 00 00 00 00 00 00 00  62 00 00 00 b0 6b 5a 56  |........b....kZV|
 00003750  58 97 65 11 00 00 00 00  00 00 00 00 97 10 00 00  |X.e.............|
 00003760  b0 6b 5a 56 30 fb 60 86  00 00 00 00 00 00 00 00  |.kZV0.`.........|
 00003770  b0 2f 40 83 34 00 00 00  01 00 00 00 00 00 00 00  |./@.4...........|
-00003780  e0 08 65 00 00 00 00 00  e0 1f c8 83 34 00 00 00  |..e.........4...|
+00003780  e0 08 65 00 00 00 00 00  e0 1f 88 0a 35 00 00 00  |..e.........5...|
 00003790  01 00 00 00 00 00 00 00  08 09 65 00 00 00 00 00  |..........e.....|
 000037a0  50 2d 15 83 34 00 00 00  01 00 00 00 00 00 00 00  |P-..4...........|
 000037b0  d0 ff ff ff ff ff ff ff  58 2d 15 83 34 00 00 00  |........X-..4...|
@@ -19806,13 +19806,13 @@
 *
 000501e0  28 00 65 00 00 00 00 00  1e 59 40 00 00 00 00 00  |(.e......Y@.....|
 000501f0  00 00 00 00 00 00 00 00  00 b1 e8 82 34 00 00 00  |............4...|
-00050200  10 cd ec 82 34 00 00 00  50 32 a2 83 34 00 00 00  |....4...P2..4...|
-00050210  80 79 e6 82 34 00 00 00  e0 2f a2 83 34 00 00 00  |.y..4..../..4...|
+00050200  10 cd ec 82 34 00 00 00  50 32 62 0a 35 00 00 00  |....4...P2b.5...|
+00050210  80 79 e6 82 34 00 00 00  e0 2f 62 0a 35 00 00 00  |.y..4..../b.5...|
 00050220  20 87 e7 82 34 00 00 00  20 bc e8 82 34 00 00 00  | ...4... ...4...|
 00050230  20 9f e7 82 34 00 00 00  b0 05 e8 82 34 00 00 00  | ...4.......4...|
 00050240  d0 af e9 82 34 00 00 00  20 5e ed 82 34 00 00 00  |....4... ^..4...|
 00050250  40 7e ee 82 34 00 00 00  40 71 ec 82 34 00 00 00  |@[email protected]...|
-00050260  10 9d e9 82 34 00 00 00  30 6f a1 83 34 00 00 00  |....4...0o..4...|
+00050260  10 9d e9 82 34 00 00 00  30 6f 61 0a 35 00 00 00  |....4...0oa.5...|
 00050270  f0 d7 ec 82 34 00 00 00  60 19 e3 82 34 00 00 00  |....4...`...4...|
 00050280  e0 b1 e9 82 34 00 00 00  10 85 ee 82 34 00 00 00  |....4.......4...|
 00050290  30 84 ec 82 34 00 00 00  40 20 e6 82 34 00 00 00  |0...4...@ ..4...|
(etc)

물론 처음에는 해킹이라고 생각했는데 차이점을 보니 궁금하네요. 실제 코드는 변경되지 않은 것 같습니다. 나는 ELF 바이너리에 대한 전문가는 아니지만 이것이 공유 라이브러리에 대한 재배치 오프셋 테이블일 뿐이라고 생각합니다.

그럼 실제로 무슨 일이 일어났다고 생각하시나요? 해킹 외에 내가 생각할 수 있는 유일한 다른 가능성은 공유 라이브러리 오프셋이 무작위로 지정되고 링크된 바이너리도 업데이트되어야 하는 '보안' 조치입니다. 그런데 왜 지금? 마지막으로 일부 소프트웨어를 설치한 것은 12월 23일이었고 그 사이에는 이상한 일이 전혀 나타나지 않았습니다. 관련될 수 있는 유일한 cronjob은 /etc/cron.daily/prelink입니다. 그렇다면 왜 지금입니까?

답변1

설명하신 바이너리 체크섬의 차이는 아마도 사전 연결 때문일 것입니다. CentOS 및 Fedora와 같은 RHEL 기반 Linux 배포판에는 기본적으로 사전 연결이 활성화되어 있습니다. 2009년은 이렇습니다LWN.net 기사prelink의 개념을 설명합니다.

Linux 프로그램은 일반적으로 여러 공유 라이브러리를 참조하는 바이너리 실행 파일로 구성됩니다. 이러한 라이브러리는 메모리에 한 번 로드되고 여러 실행 파일에 의해 공유됩니다. 이를 수행하려면 동적 링커(예: ld.so)는 라이브러리 개체의 모든 주소가 메모리의 올바른 위치를 가리키도록 메모리의 바이너리를 변경해야 합니다. 공유 라이브러리가 많은 애플리케이션(예: GUI 프로그램)의 경우 해당 프로세스에 시간이 걸릴 수 있습니다.

사전 연결의 개념은 매우 간단합니다. 동적 링커가 이러한 주소 재배치를 수행하는 데 필요한 시간을 미리 수행하고 결과를 저장함으로써 줄이는 것입니다. 사전 링크 프로그램은 ld.so와 거의 동일한 방식으로 ELF 바이너리와 공유 라이브러리를 처리한 다음 재배치를 설명하는 파일에 특수 ELF 섹션을 추가합니다. ld.so는 미리 연결된 바이너리나 라이브러리를 로드할 때 이러한 섹션을 확인하고 라이브러리가 예상 위치에 로드되고 라이브러리가 변경되지 않은 경우 작업을 훨씬 더 빠르게 수행할 수 있습니다.

그러나 라이브러리가 항상 동일한 메모리 위치에 로드되는 경우 공격자는 악성 코드로 이러한 위치를 표적으로 삼을 수 있습니다. 이것이 바로 Redhat distro가 (주소 공간 레이아웃 무작위화를 달성하기 위해) 옵션 prelink을 사용하여 정기적으로 실행되는 이유입니다 -R. 메모리 위치를 변경하면 이진 실행 파일의 체크섬이 변경됩니다. 따라서 AIDE와 같은 파일 무결성 검사기를 사용하는 경우 실제로 발생한 유일한 변경 사항은 prelink -R.

참고자료: https://en.wikipedia.org/wiki/Prelink#Linux

관련 정보