Cybersecurity

Да шпионираме шпионите*...

Александър Цокев

• 5 min read
Да шпионираме шпионите*...

* По аналогия на "Quis custodiet ipsos custodes?" исках заглавието да включва латинския превод на "шпиониране на шпионите", но явно Google Translate, Yandex Translate и повечето автоматизирани системи за превод имат странно разбиране за латинския и обратния превод звучеше меко казано ... "уникално".

Преди седмица попаднах на интересна статия в Gizmodo, описваща инструмент за анализ на трафика от смарт устройства, с цел да се провери за потенциално шпиониране, изтичане на данни и други съмнителни действия. Описаният инструмент за Mac се базира на по-стара концепция за конфигуриране на Raspberry PI като точка за достъп (access point), свързването на различните системи към нея, прихващане и анализиране на трафика. В самият подход (за прихващане и проверка на трафика) няма нищо изненадващо, защото е сравнително често прилаган при корпоративни мрежи, SIEM, IDS/IPS и други подобни системи за превенция на кибератаки. Тук се замислих над факта, че би било много полезно да се разработи компактна система (комбинация от хардуерни модули и/или софтуерни компонент), която да е достатъчно лесна за свързване и употреба от потребители с минимални ИТ познания.

Реших да подходя максимално праволинейно - от целта към решението. Запитах се какво ще ми е необходимо за подобни анализи и стигнах до следния списък:

  1. Базова информация за потока от пакети (не NetFlow или IPFIX, а просто 5-tuple);
  2. Съдържанието на определени пакети;
  3. Възможност за дешифриране на криптирана комуникация;
  4. Максимално бързо свързване към съществуваща домашна мрежа;
  5. Графично представяне на данните;
  6. Лесно и бързо търсене в информацията;
  7. Възможност за автоматизация.

Ако изключим т.3 решението може да се базира на port-mirror, което би отговорило на изискването за лесно свързване от потребители с минимален ИТ опит. Tap устройство, работещо на 1 Gbps е с цена около 100 USD, но комутатор (switch), поддържащ софтуерно копиране на пакетите може да се закупи за приблизително половината от тази сума. Свързването на суитча може да е между телекома и устройството на потребителя, като в същото време на това място би могло да се направят и MITM и SSL Strip атаки.

Прецених, че това ще е подхода, а устройството, което може да се използва е някои от бюджетните модели на MikroTik. Разполагам с маршрутизатор на тази фирма и беше сравнително лесно да стартирам с конфигурацията на копирането на трафика, което изискваше въвеждане на една единствена команда:

/interface ethernet switch set switch1 mirror-source=ether1 mirror-target=ether4

Проверих в Wireshark и получавах пакетите между устройствата в WLAN мрежата ми и интернет. До тук добре - една най-важните точки от списъка беше успешно изпълнена.

Бях решил да използвам ELK за съхранение и анализ на данните. За целта във VirtualBox инсталирах Ubuntu Server 18.04.2 LTS. Добавих два виртуални мрежови интерфейса в мостов режим (bridged), първият беше свързан към безжичната мрежа, а втория към Ethernet интерфейса на лаптопа. Тук е важно да се отбележи ключовата роля на една настройка, свързана с режима "promiscuous mode":

Без да е активиран "безразборен режим" виртуалната машина няма да получава целия трафик, постъпващ на Ethernet интерфейса.

Инсталирането на ELK е сравнително просто и бързо, но предварително добавих и конфигурирах Oracle Java:

sudo apt update
sudo apt upgrade
sudo apt install software-properties-common apt-transport-https -y
sudo add-apt-repository ppa:webupd8team/java -y
sudo apt update
sudo apt install oracle-java8-installer -y

Създадох файл /etc/profile.d/java.sh със следното съдържание:

#Set JAVA_HOME
JAVA_HOME="/usr/lib/jvm/java-8-oracle"
export JAVA_HOME
PATH=$PATH:$JAVA_HOME
export PATH

Пристъпих към инсталиране на ELK:

sudo chmod +x /etc/profile.d/java.sh
source /etc/profile.d/java.sh

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-6.x.list
sudo apt update

sudo apt install elasticsearch kibana

systemctl start kibana
systemctl start elasticsearch

Преди да се стартират услугите промених конфигурационния файл на Kibana - /etc/kibana/kibana.yml.

server.port: 5601
server.host: 0.0.0.0
elasticsearch.hosts: ["http://localhost:9200"]

Логичното решение за изпращане на копираните пакети е Packetbeat. Инсталирането отново е лесно и бързo, както и създаването на работните екрани (dashboard) за Kibana.

sudo apt install libpcap0.8
wget https://artifacts.elastic.co/downloads/beats/packetbeat/packetbeat-7.0.0-amd64.deb
sudo dpkg -i packetbeat-7.0.0-amd64.deb
sudo service packetbeat start
packetbeat setup --dashboards

Свързах се към Kibana и проверих индексите в Elasticsearch и възможностите за визуализация. Останах приятно изненадан от факта, че всичко работеше според очакванията ми.

Още един успех - разполагах с инструмент за анализ на копираните пакети. Оставаше да изчакам да се съберат данни от различните смарт системи и други устройства и да потърся аномалии. За около час се получи:

Проверих за HTTP трафик и за моя радост не открих такъв. Анализът на изходящите шифрирани сесии показа:

Веднага вниманието ми се привлече от трафика към fibaro.com, поради причината, че използвам тяхна система от тип умен дом (на български "smart home" ми звучи малко странно, почти като позабравения термин - "образцов дом").

Бърза проверка на данните за изпратените и получените пакети към и от fibarо.com не показаха нищо притеснително. Трафикът се дължеше на факта, че бях стартирал приложението за наблюдение на моя телефон и бях отворил статистиката за консумирана електроенергия от един умен контакт (... "образцов контакт").

Изводът до който стигнах беше, че няма нищо странно в изходящия и входящия поток от пакети, въпреки че имах подозрения. Разбира се, ако сме по-конспиративно настроени може да помислим, че е възможно периода за анализ от  приблизително 60 минути да не е достатъчен, както и възможността да се използва специфичен протокол, който не е активиран по подразбиране в Packetbeat. И двете хипотези могат да се окажат верни, но това е проверка, която ще оставя за друг път.

Нека да се върнем на цялостната концепция. Копирането на трафика между портовете на MikroTik маршрутизатора даде възможност чрез Packetbeat и ELK да се получат данни за трафичните потоци, които в последствие да се анализират за аномалии. Дали това може да се извърши автоматизирано? Определено - да. От списъка с "изисквания", който е в началото на статията се вижда, че подхода единствено не е изпълнил точката за дешифриране на трафика, но това също е възможно посредством MITM.

Ако приемем, че се използва предварително конфигуриран комутатор (с зададени параметри за "port mirror") и софтуерно приложение, базирано на ELK, Packetbeat и допълнителни анализи, то потребителя ще трябва да:

  1. Свърже суитча и портовете към съответните устройства;
  2. Да инсталира софутера за анализ.

Втората стъпка може да се окаже по-трудна, поради причината, че ако се разполага само с едно устройство, по време на прихващане и анализ на трафика е възможно системата да не може да се използва за достъп до други мрежови ресурси и интернет, но това може да се окаже минимално затруднение.

Според мен си заслужава да се отдели известен ресурс от време за изчистване на концепцията и създаване на цялостно решение, което да се опита да "следи умните шпиони в домовете ни".

Лошото е, че може да се наложи да разширим шегата "Искате ли защитна стена (firewall) за тостера?" с "..., а да добавим ли и домашна SIEM система?".