ThinkPHP6.0.13 역직렬화 취약점 분석

요즘 좀 한가해서 할 일이 없으면 불편할 것 같아서 분석할 부분을 좀 찾아보려고 하는데 ThinkPHP6.0.13은 좀 살펴보려고 합니다. 지난 8월 한 마스터가 TP에 역직렬화 문제가 있음을 지적하는 이슈를 제출했는데 인터넷의 일부 전문가가 이를 분석했지만 중단점이 많고 일부 방법에서는 용도가 명확하지 않습니다. 자세히 분석해 보았습니다. 먼저 POC

분석

먼저 POC

의 시작점을 살펴보고 시작점이 Psr6Cache 클래스에 있음을 확인했습니다. , 그러나 __destruct는 발견되지 않았습니다. 또는 __wakeup과 같은 일반적인 역직렬화 시작 매직 메서드인 경우 부모 클래스 AbstractCache의 추상 클래스에 있어야 한다고 추측됩니다. 그림과 같이 AbstractCache 클래스

에 이어 이 역직렬화 체인의 시작 클래스를 성공적으로 찾았습니다. 여기서는 자동 저장 속성을 false로 제어하여 저장 방법을 시작할 수 있습니다.

이 메서드를 보려면 Psr6Cache 클래스로 돌아가세요.

풀 속성과 키 속성을 모두 제어할 수 있다는 것을 알 수 있습니다. 따라서 서로 다른 클래스의 동일한 이름(getItem)을 가진 메서드를 호출하는 두 가지 경로가 있을 수 있습니다. 또는 __call 메서드를 직접 트리거해 보세요. POC 작성자가 역직렬화 진행을 허용하는 방법을 살펴보겠습니다.

작성자는 생성자 메서드를 사용하여 exp를 전달했으며 exp는 실제로 Channel 클래스를 인스턴스화하고 있습니다. Channel 클래스로 가서

Channel 클래스에 __call 메서드가 있으므로 작성자는 체인을 계속하기 위해 __call을 트리거하도록 선택합니다. 이 호출 메소드는 두 개의 매개변수를 허용합니다(getItem). 매개변수는 제어 가능합니다(즉, 이전에 제어 가능한 키 속성). 이를 보려면 로그 메소드를 따르십시오(그러나 실제로는 그렇습니다. 후속 체인에는 쓸모가 없음) 기록 메소드

에 이어 기록 메소드

를 전달한 다음 다시 돌아가서 작성자의 POC를 확인하고 해당 제어 게으른 속성이 false인지 확인하고 함수를 입력하세요. 마지막으로 Branch가 save 메소드를 실행하는 경우

save 메소드에 이어 악용될 수 있는 세 가지 포인트가 저자가 선택한 것입니다.

POC에 따르면 작성자가 로거 속성을 제어하고 생성자를 사용하여 값을 할당하고 이를 Socket 클래스의 객체로 만들기로 선택했음을 찾는 것은 어렵지 않습니다

이 수업에서는 많은 작업이 포함된 동일한 이름의 복잡한 A 메서드를 발견했습니다.

작성자가 config 속성을 제어하고 배열 값을 할당하는 방법을 계속 살펴보겠습니다. 배열에는 다음 콘텐츠가 있습니다

핵심은 이 두 가지 키 값에 있습니다. 작성자는 구성을 제어하고 프로그램이 호출 메서드

를 호출하는 분기에서 실행되도록 합니다. 속성은 제어 가능합니다. 작성자는 App 클래스 Object의 app 속성을 만들고 App 클래스에 들어갑니다

여기서 먼저 App 클래스의 존재 메소드를 살펴보고 해당 상위 클래스에서 이 메소드를 찾았습니다

계속해서, 인스턴스 속성의 값을 제어하는 ​​App 클래스에서 수행되는 유일한 작업은 다음과 같습니다. 여기서 값을 제어하는 ​​목적은 Request 클래스를 입력하고 url 메소드를 실행하는 것입니다

작성자가 여기에서 Request 클래스에 대해 수행한 유일한 조작은 url 속성의 값을 제어하는 ​​것입니다. url 속성이 존재하면 첫 번째 분기가 입력되고 해당 값은 자체와 동일하다는 것을 알 수 있습니다.

동시에 우리는 이전에 전달한 전체 값이 true임을 확인했습니다. 따라서 최종 반환된 결과는 $this->domain().$url입니다. URL을 제어했으니 domain 메서드는 무엇을 반환합니까?

좋아, 이건 볼 필요가 없어. 많은 분석을 거쳐 $currentUri의 최종 값을 얻었습니다. 즉,

http://localhost/

currentUri는 체인의 길이에 따라 호출에 전달됩니다. Invoke, 우리의 반응 직렬화 여정이 거의 끝났습니다

invoke를 보면 App 클래스가 이 메소드를 찾을 수 없고 상위 클래스에서 이 메소드를 찾았습니다

여기에서 볼 수 있습니다. 이 함수에는 세 가지 분기가 있는데 결국 어디로 갈까요? 이전 $config['format_head']에 따르면 우선 우리가 전달한 객체는 Closure의 인스턴스나 하위 클래스가 아니며 두 번째 브랜치

의 조건을 충족하지 않으므로 다음과 같이 입력합니다. 세 번째 가지. 우리는 InvokeMethod() 메소드를 사용하여 후속 조치를 취합니다. 여기에 전달된 $callabel은 [new thinkviewdriverPhp,'display']이고 $vars는 ['http://localhost/']

우리가 전달한 $method는 배열이므로 다음을 입력하세요. 첫 번째 지점. $class에 새로운 thinkviewdriverPhp(객체)를 할당하고, 새로운 $method에 'display'(메소드 이름)를 할당합니다.

그런 다음 $class가 객체이면 그 값은 객체 자체로 전달되므로 여기서는 변경 사항이 없습니다. 그런 다음 가장 중요한 코드를 입력하세요

새 thinkviewdriverPhp 개체와 메서드 표시가 ReflectionMethod에 전달되는 것을 볼 수 있습니다.

마지막에 새로운 thinkviewdriverPhp 개체를 전달하고 $args

도 전달하여 InvokeArgs 메서드를 호출하면 args가 무엇인가요?

어어어어어어어어어어어어어어어어어어어어어어어어어어어어어어 거의 다 끝났기 때문에 열심히 읽지 않고 직접 결론을 내립니다. 우리가 전달한 var, 즉 ['http://localhost/'] 주요 부분은 유지되어 후속 매개변수 전송에 입력됩니다

더 자세히 살펴보면 이 함수(invokeArgs)에 대해 간단히 비교할 수 있습니다. to call_user_func() 따라서 마지막 키 코드는 실제로 이 두 줄

$reflect = new ReflectionMethod(new \think\view\driver\Php,’display’);
return $reflect->invokeArgs(new \think\view\driver\Php,’ ’)

입니다. tp deserialization을 자주 보는 친구들은 이제 끝났다는 걸 아실 겁니다! 결국 표시 방법이 호출됩니다. 그러나 위에서 ReflectionMethod 클래스를 호출하는 작업은 정확히 무엇입니까? 다음 예를 통해 이를 입증할 수 있습니다. 그래서 이것은 call_user_func

마지막으로 표시 방법이 있습니다. 말할 것도 없습니다. 내용은 표시 방법에 전달되고 eval은 명령을 실행합니다

결론

TP의 체인은 그 어느 때보다 흥미롭고 복잡합니다. 특히 마지막 ReflectionMethod 클래스의 사용법을 이해하지 못하고 클래스의 메서드 조합을 사용하면 call_user_func 함수와 유사한 기능을 얻을 수 있습니다. 이런 멋진 이벤트를 놓치기 쉽습니다.

【관련 튜토리얼 추천: thinkphp Framework】

위 내용은 ThinkPHP6.0.13 역직렬화 취약점 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!