brianwrf/magento-cve-2016-4010마젠토 인증되지 않은 원격 코드 실행 (CVE-2016-4010)
0x00 서문
5월 17일, 해외 보안 연구원 Netanel Rubin이 Magento의 인증되지 않은 원격 코드 실행 취약점(CVE-2016-4010)을 공개했습니다. 이 취약점은 실제로 여러 개의 작은 취약점을 포함하며, 공격자가 취약한 Magento 서버에서 인증 없이 PHP 코드를 실행할 수 있도록 합니다. Magento는 매우 인기 있는 전자상거래 플랫폼으로, 2011년 eBay에 인수되었습니다. 삼성, 니콘, 레노버와 같은 유명 기업 및 수많은 소규모 전자상거래 업체가 이를 사용하고 있습니다. 알려진 바에 따르면, Magento는 250,000개의 온라인 상점에서 사용되며, 연간 600억 달러에 달하는 금액이 거래됩니다.
0x01 분석
해당 취약점의 이용 조건:
Magento의 웹 API는 REST RPC와 SOAP API의 두 가지 방식의 RPC를 허용합니다. 두 방식 모두 동일한 기능을 제공하지만, 전자는 JSON과 HTTP 요청을 사용하여 입력을 전달하고, 후자는 XML을 사용한다는 차이점이 있습니다.
일부 모듈의 API만 공개하기 위해, Magento는 개발자에게 "webapi.xml" 파일에 접근을 허용하려는 모듈의 API만 선언할 수 있는 편리한 방법을 제공합니다. webapi.xml 파일에는 공개해야 하는 모든 웹 API의 클래스와 메서드가 포함되어 있으며, 각 메서드는 필요한 구체적인 권한도 지정합니다. 이러한 권한에는 다음이 포함됩니다:
물론, 개발자가 webapi.xml 파일을 사용하여 시스템의 프론트엔드와 백엔드(웹 API) 간에 통신할 수 있도록 허용하는 이 방식은 실제로 모듈 코어로 바로 연결되는 백도어를 열어줍니다.
또한, "anonymous" 권한이 있더라도 동적으로 값을 전달할 수 있는 방법이 필요합니다. 여기서 시스템에서 사용할 수 있는 다양한 객체가 있습니다. 예를 들어, "CustomerRepositoryInterface::save()" API 기능은 "$customer" 변수에 "CustomerInterface" 객체를 사용할 수 있으며, 코드 프로토타입은 다음과 같습니다:
interface CustomerRepositoryInterface
{
/**
* Create customer.
*/
public function save(\Magento\Customer\Api\Data\CustomerInterface $customer);
}
그렇다면 RPC 인터페이스를 사용하여 객체를 어떻게 생성할 수 있을까요? 사실 이 질문에 대한 답은 Magento가 SOAP 서버를 구성하는 방식에 있습니다.
Magento는 PHP "SoapServer"가 기본 번들로 포함된 SOAP 서버를 사용합니다. 올바르게 구성하기 위해 "SoapServer"는 WSDL 파일이 필요하며, 이 파일에서 모든 메서드, 매개변수 및 실제 RPC 요청에 사용되는 사용자 정의 유형을 정의합니다. Magento는 XMLRPC 기능을 지원하는 각 모듈에 대해 서로 다른 WSDL 파일을 생성하고, 모듈의 webapi.xml 파일에서 직접 값을 설정합니다.
RPC 요청이 서버에서 구문 분석될 때, 서버는 WSDL 파일에서 찾은 데이터를 사용하여 요청이 유효한지 판단하고, 요청의 메서드, 매개변수 및 유형을 확인합니다. 요청이 유효하면 구문 분석된 요청 객체가 Magento로 전달되어 추가 구문 분석이 수행됩니다. 매우 중요한 점은 "SoapServer"가 Magento와 어떤 방식으로도 상호작용하지 않으며, 모듈의 메서드 및 매개변수에 대한 모든 정보는 WSDL 파일에서 비롯된다는 것입니다. 이때 전송된 요청은 여전히 중첩된 배열로 구성되어 있으며, SoapServer 구문 분석 단계에서는 객체가 생성되지 않습니다. 필요한 객체를 생성하기 위해 Magento는 자체적으로 입력을 처리합니다.
매개변수 이름과 데이터 유형을 추출하기 위해 Magento는 요청된 메서드에서 프로토타입을 가져옵니다(앞서 코드 참조). 문자열, 배열, 부울 등과 같은 기본 데이터 유형의 경우 시스템은 입력을 해당 유형에 매핑합니다. 그러나 객체 유형의 경우 해결 방법이 더 까다롭습니다.
매개변수의 데이터 유형이 클래스의 인스턴스인 경우, Magento는 제공된 입력을 사용하여 인스턴스를 생성하려고 시도합니다. 여기서 입력은 단지 딕셔너리이며, 키는 속성 이름이고 값은 속성 값입니다.
먼저 Magento는 필요한 클래스의 새 인스턴스를 생성합니다. 그런 다음 다음 방법을 사용하여 채우기를 시도합니다:
Magento는 사용자가 설정하려는 각 속성에 대해 이 방법을 처리합니다. 모든 속성이 확인되면 Magento는 해당 인스턴스가 설정된 것으로 간주하고 다음 매개변수를 처리합니다. 모든 매개변수가 이렇게 처리되면 Magento는 최종적으로 API 메서드를 실행합니다.
요약하자면, Magento는 객체를 생성하고, 해당 공용 속성을 설정한 다음, RPC를 통해 "Set"으로 시작하는 메서드를 실행할 수 있도록 합니다. 바로 이러한 동작이 Magento 취약점의 원인이 되었습니다.
연구 결과, 일부 API 호출은 장바구니에 특정 정보(예: 배송 주소, 상품, 결제 수단)를 설정할 수 있도록 합니다.
Magento가 장바구니 인스턴스에 우리의 정보를 설정할 때, 인스턴스의 "save" 메서드를 사용하여 새로 추가된 데이터를 데이터베이스에 저장합니다.
이제 "save" 메서드가 어떻게 작동하는지 살펴보겠습니다!
/**
* Save object data
*/
public function save(\Magento\Framework\Model\AbstractModel $object)
{
...
// If the object is valid and can be saved
if ($object->isSaveAllowed()) {
// Serialize whatever fields need serializing
$this->_serializeFields($object);
...
// If the object already exists in the DB, update it
if ($this->isObjectNotNew($object)) {
$this->updateObject($object);
// Otherwise, create a new record
} else {
$this->saveNewObject($object);
}
// Unserialize the fields we serialized
$this->unserializeFields($object);
}
...
return $this;
}
// AbstractDb::save()
Magento는 객체가 유효한지 확인한 후, 직렬화해야 할 모든 부분을 직렬화하여 데이터베이스에 저장하고, 마지막으로 직렬화된 부분을 역직렬화합니다.
간단해 보이죠? 그렇지 않습니다. 계속해서 Magento가 어떤 부분을 직렬화해야 하는지 어떻게 결정하는지 살펴보겠습니다.
/**
* Serialize serializable fields of the object
*/
protected function _serializeFields(\Magento\Framework\Model\AbstractModel $object)
{
// Loops through the '_serializableFields' property
// (containing hardcoded fields that should be serialized)
foreach ($this->_serializableFields as $field => $parameters) {
// Get the field's value
$value = $object->getData($field);
// If it's an array or an object, serialize it
if (is_array($value) || is_object($value)) {
$object->setData($field, serialize($value));
}
}
}
// AbstractDb::_serializeFields()
보시다시피, 하드코딩된 딕셔너리 "_serializableFields"에 나타나는 부분만 직렬화될 수 있습니다. 가장 중요한 것은, 이 메서드는 필드 값이 배열 또는 객체인지 확인한 후에만 직렬화를 진행한다는 점입니다.
이제 Magento가 어떤 부분을 역직렬화해야 하는지 어떻게 결정하는지 살펴보겠습니다.
/**
* Unserialize serializeable object fields
*/
public function unserializeFields(\Magento\Framework\Model\AbstractModel $object)
{
// Loops through the '_serializableFields' property
// (containing hardcoded fields that should be serialized)
foreach ($this->_serializableFields as $field => $parameters) {
// Get the field's value
$value = $object->getData($field);
// If it's not an array or an object, unserialize it
if (!is_array($value) && !is_object($value)) {
$object->setData($field, unserialize($value));
}
}
}
// AbstractDb::unserializeFields ()
음, 매우 비슷해 보입니다. 유일한 차이점은 이번에는 Magento가 필드 값이 배열 또는 객체가 아닌지 확인해야 한다는 것입니다. 이 두 번의 확인 덕분에, 직렬화 가능한 필드에 특정 규칙의 문자열을 설정하기만 하면 객체 주입 공격을 수행할 수 있어야 합니다. 이렇게 설정하면, 시스템이 데이터베이스에 객체를 저장하기 전에 해당 필드를 직렬화하지 않습니다(객체나 배열이 아니기 때문에). 그러나 데이터베이스 쿼리가 실행된 후 시스템이 역직렬화를 시도할 때는 객체나 배열이 아니기 때문에 역직렬화됩니다.
하지만 바로 이 작아서 거의 보이지 않는 조건이 취약점을 만들었습니다. 남은 문제는 어떤 필드가 "직렬화 가능"한 것으로 간주되는지, 그리고 어떻게 설정할 수 있는지 고려하는 것입니다.
물론 첫 번째 문제는 간단합니다. "_serializableFields" 속성을 포함하는 클래스를 검색하기만 하면 됩니다. 곧바로 "Payment" 클래스에서 API 메서드를 찾았지만, 매개변수로 사용되지 않아 인스턴스 속성을 생성하거나 제어할 수 없었습니다. 가장 중요한 것은, 직렬화 가능한 필드인 "additional_information"은 추가 보안 조치로 "Set[PROPERTY_NAME]" 기술을 사용하여 배열로만 설정할 수 있다는 점입니다. 따라서 생성할 수 없을 뿐만 아니라, 생성할 수 있더라도 문자열로 설정할 수 없습니다.
하지만 흥미롭게도, 다른 "멋진" 방식으로 설정할 수 있습니다. Magento가 매개변수 인스턴스의 속성을 설정할 때, 실제로 속성을 설정하는 것이 아니라 "_data"라는 딕셔너리에 저장합니다. 인스턴스의 속성이 사용될 때 이 딕셔너리가 사용됩니다. 이는 우리에게 직렬화 가능한 필드인 "additional_information"이 실제로 정상적인 속성이 아닌 내장 딕셔너리에 저장된다는 것을 의미합니다.
따라서 "_data" 딕셔너리를 완전히 제어할 수 있다면, "Set[PROPERTY_NAME]"을 호출하지 않고 수동으로 설정할 수 있기 때문에 "additional_information" 필드의 배열 제한을 쉽게 우회할 수 있습니다.
하지만 이 민감한 딕셔너리를 어떻게 제어할 수 있을까요?
"Payment" 인스턴스를 저장하기 전에 Magento가 해야 할 일 중 하나는 해당 속성을 편집하는 것입니다. Magento는 우리의 API 입력을 "Payment" 인스턴스에 저장해야 하는 결제 정보로 간주하며, 다음과 같습니다:
/**
* Adds a specified payment method to a specified shopping cart.
*/
public function set($cartId, \Magento\Quote\Api\Data\PaymentInterface $method)
{
$quote = $this->quoteRepository->get($cartId); // Get the cart instance
$payment = $quote->getPayment(); // Get the payment instance
// Get the data from the user input
$data = $method->getData();
// Check for additional data
if (isset($data['additional_data'])) {
$data = array_merge($data, (array)$data['additional_data']);
unset($data['additional_data']);
}
// Import the user input to the Payment instance
$payment->importData($data);
...
}
// PaymentMethodManagement::set()
보시다시피, "Payment" 데이터는 "$method->getData()"를 호출하여 "$method" 매개변수에서 "_data" 속성을 반환함으로써 가져옵니다. "$method"는 API 메서드의 매개변수이므로 우리가 제어할 수 있음을 기억하세요.
Magento가 우리의 "$method" 매개변수에서 "getData()"를 호출하면, 매개변수의 "_data" 속성이 반환되며, 여기에는 우리가 삽입한 모든 결제 정보가 포함됩니다. 그런 다음 "_data" 속성을 입력으로 사용하여 "importData()"를 호출하고, 우리의 "_data" 속성으로 "Payment" 인스턴스의 "_data" 속성을 대체합니다. 이제 우리는 제어 가능한 "_data" 속성을 사용하여 "Payment" 인스턴스의 민감한 "_data" 속성을 대체할 수 있게 되었습니다. 즉, 이제 "additional_information" 필드를 설정할 수 있습니다.
unserialize()가 작동하려면 필드를 문자열로 설정할 수 있어야 하지만, "Set[PROPERTY_NAME]" 메서드는 배열만 허용합니다. 해결 방법은 "importData()"를 호출하기 전에 2줄의 코드가 있다는 것입니다. Magento는 개발자가 자신의 결제 방법을 추가하고, 자신의 데이터와 정보를 제공할 수 있도록 합니다. 이를 위해 Magento는 "additional_data" 필드를 사용합니다. 이 필드는 더 많은 데이터를 포함하는 결제 방법이며 완전히 사용자 제어 가능한 딕셔너리입니다. 사용자 정의 콘텐츠가 원본 데이터의 일부가 되도록 Magento는 "additional_data" 딕셔너리를 원본 "data" 딕셔너리와 병합합니다. 이는 실제로 "additional_data" 딕셔너리가 "data" 딕셔너리의 모든 값을 덮어쓸 수 있도록 허용하며, 기본적으로 완전히 덮어쓸 수 있습니다. 즉, 두 딕셔너리가 병합된 후 사용자 제어 가능한 "additional_data" 딕셔너리는 이제 매개변수 "_data" 딕셔너리가 되고, "importData()"로 인해 "Payment" 인스턴스의 민감한 "_data" 속성도 됩니다. 다시 말해, 이제 직렬화 가능한 필드 "additional_information"을 완전히 제어할 수 있으며, 객체 주입 공격을 수행할 수 있습니다.
이제 원하는 문자열을 역직렬화할 수 있으므로, 객체 주입 공격을 수행할 때입니다.
먼저, 객체가 역직렬화되거나 소멸될 때 자동으로 호출되는 "__wakeup()" 또는 "__destruct()" 메서드가 있는 객체가 필요합니다. 이는 객체의 속성을 제어할 수 있지만 메서드를 호출할 수 없기 때문입니다. 따라서 특정 이벤트가 발생할 때 자동으로 호출되는 PHP의 매직 메서드에 의존해야 합니다.
첫 번째로 사용할 객체는 "Credis_Client" 클래스의 인스턴스이며, 다음과 같은 메서드가 포함되어 있습니다:
/*
* Called automaticlly when the object is destrotyed.
*/
public function __destruct()
{
if ($this->closeOnDestruct) {
$this->close();
}
}
/*
* Closes the redis stream.
*/
public function close()
{
if ($this->connected && ! $this->persistent) {
...
$result = $this->redis->close();
}
...
}
// Credis_Client::__destruct(), close()
이 클래스에는 객체가 소멸될 때 PHP가 자동으로 호출하는 간단한 "__destruct" 메서드가 있어 "close()" 메서드를 호출합니다. 흥미롭게도 "close()" 메서드는 Redis 서버에 활성 연결이 있으면 "redis" 속성의 "close()"를 호출하여 연결을 종료합니다.
"unserialize()"는 모든 객체 속성을 제어할 수 있게 해주므로 "redis" 속성도 제어할 수 있습니다. 속성에 (Redis뿐만 아니라) 원하는 객체를 설정하고, 시스템의 모든 클래스에서 "close()" 메서드를 호출할 수 있습니다. 이는 공격 표면을 크게 확장합니다. Magento에는 일부 "close()" 메서드가 있으며, 이러한 메서드는 일반적으로 스트림 종료, 파일 핸들 닫기 및 객체 데이터 저장에 사용되므로 흥미로운 호출을 찾을 수 있을 것입니다.
예상대로, "Transaction" 클래스에서 다음과 같은 "close()" 메서드를 발견했습니다:
/**
* Close this transaction
*/
public function close($shouldSave = true)
{
...
if ($shouldSave) {
$this->save();
}
...
}
/**
* Save object data
*/
public function save()
{
$this->_getResource()->save($this);
return $this;
}
// Magento\Sales\Model\Order\Payment\Transaction::__destruct(), close()
간단해 보입니다. "close()" 메서드는 "save()" 메서드를 호출하고, 이어서 "_resource" 속성의 "save()" 메서드를 호출합니다. 동일한 방식으로 "_resource" 속성을 제어하므로 해당 클래스도 제어할 수 있으므로, 원하는 클래스의 "save()" 메서드를 호출할 수 있습니다.
한 걸음 더 나아갔습니다. 예상대로 "save()" 메서드는 일반적으로 다양한 저장 매체(예: 파일 시스템, 데이터베이스 등)에 다양한 데이터를 저장하는 데 사용됩니다. 이제 해야 할 일은 파일 시스템을 저장 매체로 사용하는 "save()" 메서드를 찾는 것입니다.
곧바로 하나를 찾았습니다:
/**
* Try to save configuration cache to file
*/
public function save()
{
...
// save stats
file_put_contents($this->getStatFileName(), $this->getComponents());
...
}
// Magento\Framework\Simplexml\Config\Cache\File::save()
이 메서드는 실제로 "components" 필드의 데이터를 파일에 저장합니다. 파일 경로는 "stat_file_name" 필드에서 가져오므로, 이 두 매개변수를 제어할 수 있기 때문에 파일 경로와 내용을 실제로 제어할 수 있으며, 이는 임의 파일 쓰기 취약점을 발생시킵니다.
이제 유효하고 쓰기 가능하며 웹 서버가 접근할 수 있는 파일 경로를 찾아야 합니다. 모든 Magento 설치 디렉토리에는 이미지나 관리자가 업로드한 파일을 저장하는 데 사용되는 "/pub" 디렉토리가 있으며, 이는 효과적으로 활용할 수 있는 경로입니다.
마지막으로 PHP 웹쉘 파일을 서버에 작성하기만 하면 Magento 서버에서 인증 없이 임의의 PHP 코드를 실행할 수 있습니다.
0x02 활용
테스트 환경 구축
참고: 여기에서 몇 가지 문제가 발생할 수 있으며, 다음을 참조하십시오:
취약점 활용
exploit-db에 공개된 취약점 exp 다운로드 주소: https://www.exploit-db.com/exploits/39838/
활용 방법은 다음과 같습니다:
취약한 Magento 웹사이트 찾기 Magento 버전 온라인 확인: http://magentoversion.com/
장바구니에 상품 추가
장바구니로 이동하여 "결제" 클릭
배송 주소를 입력하고 POST 요청 /rest/default/V1/guest-carts/[guestCartId]/shipping-information를 확인하여 [guestCartID] 가져오기
위의 exp를 magento_exp.php로 저장하고 실행: php magento_exp.php [Magento_URL] [guestCartID] ([webshell写入路径])
대량 탐지
위의 exp 연구를 통해 이 활용을 위해서는 다음 조건을 충족해야 합니다:
따라서 위의 exp와 함께 사용할 간단한 대량 검증 스크립트를 작성했습니다:
#!/usr/bin/env python
import urllib
import sys
import socket
timeout = 5
socket.setdefaulttimeout(timeout)
input = sys.argv[1] ＃包含Magento站点的URL的文件
output = sys.argv[2] ＃结果的保存文件，可以为：output.txt
def logFile(str):
f = open(output,'a')
f.write(str+"\n")
f.close()
def checkVul(url):
try:
html = urllib.urlopen(url).read()
if "guest-carts" in html:
print url,"is vulnerable!"
logFile(url)
else:
print url,"is not vulnerable!"
except Exception:
pass
if __name__ == '__main__':
inp = open(input,'r')
for i in inp:
url=i.strip()
#print url
checkVul(url)
print "All Done!"
실행 결과:
0x03 방어
Magento를 최신 버전(2.0.6)으로 업그레이드하십시오. 다운로드 주소: https://www.magentocommerce.com/download
참고