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

Пятничный вечер, который пошел не по плану

Все началось доволь­но буд­нично: в пят­ницу, в шесть вечера, я решил поп­равить на нашем офис­ном MikroTik пра­вило NAT, потому что бух­галте­рия не мог­ла зай­ти на оче­ред­ной гос­портал. Открыл Winbox, по слу­чай­нос­ти ткнул в Neighbors и нем­ного залип.

Для тех, кто не работал с MikroTik, пояс­ню: на вклад­ке Neighbors вид­ны устрой­ства, обна­ружен­ные через про­токо­лы L2 discovery, — MNDP (проп­риетар­ный мик­ротиков­ский), CDP (Cisco) и LLDP (стан­дар­тный IEEE 802.1AB). Все три работа­ют на каналь­ном уров­не и рас­простра­няют­ся в пре­делах broadcast-домена, то есть показы­вают толь­ко то, что находит­ся с вами в одном L2-сег­менте. В нор­маль­ной ситу­ации там виден мак­симум ваш ком­мутатор или вышес­тоящий мар­шру­тиза­тор про­вай­дера.

У меня там висело штук двад­цать пять чужих девай­сов. С чужими име­нами, чужими MAC-адре­сами и впол­не рабочи­ми IP. Какие‑то ООО «Ромаш­ка», чей‑то NAS и пара точек дос­тупа непонят­ного про­исхожде­ния. Пол­ный зоопарк. Если они вид­ны в Neighbors, зна­чит, все эти устрой­ства физичес­ки находят­ся со мной в одном broadcast-домене. А это­го вро­де как быть не дол­жно.

Паника, гипотезы, тупики

Пер­вая мысль была паничес­кой и свя­зан­ной с текущи­ми реалиями: нас лома­ют. Кто‑то проб­рался в сеть, рас­ста­вил свои устрой­ства и вот‑вот ута­щит раз­работ­ки ком­пании, а заод­но пер­сональ­ные дан­ные. А может, уже не один день исполь­зует нашу инфраструк­туру как часть бот­нета. Я полез про­верять: сме­нил пароль на роуте­ре, про­шер­стил логи авто­риза­ции, одна­ко все ока­залось чис­то. Пра­вила firewall на мес­те, нет никаких левых под­клю­чений изнутри. Я про­ана­лизи­ровал внут­ренний тра­фик через вен­дор­ский NTA (Network Traffic Analysis) и уже вруч­ную через Wireshark. Пошел в сер­верную, про­верил патч‑панель: вро­де все кабели наши, ничего лиш­него не вот­кну­то. Тупик.

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

Я даже спус­тился к мон­тажно­му шка­фу на пер­вом эта­же, пос­мотрел: наш кабель идет в отдель­ный порт про­вай­дер­ско­го ком­мутато­ра. Физичес­ки мы ни с кем не соеди­нены. А устрой­ства в Neighbors все рав­но висят. Тупик номер два.

Тог­да я подумал: лад­но, может, это какой‑то глюк Winbox? Показы­вает кеширо­ван­ное, или discovery ловит широко­веща­тель­ный мусор из кос­моса. Перезаг­рузил роутер, подож­дал пять минут, открыл Neighbors. Двад­цать пять девай­сов на мес­те, некото­рые даже обно­вили uptime. Нет, не глюк.

Ос­талась одна вер­сия: дело не в нашей сети, а в том, что при­ходит к нам по кабелю от про­вай­дера. То есть про­вай­дер где‑то не изо­лиро­вал кли­ентов друг от дру­га и мы все сидим в общем L2-сег­менте. Зву­чало дико, но про­верить эту гипоте­зу, в прин­ципе, нес­ложно.

Копаем в сторону провайдера

Я вклю­чил Torch на WAN-интерфей­се (это встро­енный монитор тра­фика в MikroTik — показы­вает потоки в реаль­ном вре­мени: адре­са источни­ков и наз­начений, про­токо­лы, ско­рос­ти) и начал смот­реть, что при­ходит с аплинка.

Пер­вые секун­ды — ничего осо­бен­ного, обыч­ный поток. Но потом в этом потоке замель­кал тра­фик на харак­терные муль­тикаст‑адре­са CDP и LLDP — про­токо­лы обна­руже­ния соседей, работа­ющие на каналь­ном уров­не. Сетевое обо­рудо­вание через них рас­ска­зыва­ет о себе: hostname, порт, вер­сия про­шив­ки. В нор­ме ты видишь их толь­ко от сво­его ком­мутато­ра или вышес­тояще­го мар­шру­тиза­тора. А тут десят­ки чужих устрой­ств пред­став­лялись друг дру­гу, как на кон­ферен­ции.

Я еще пытал­ся себя убе­дить, что это прос­то какой‑то сетевой мусор, но даль­ше в потоке пош­ли пакеты OSPF Hello, и вот тут ста­ло сов­сем не смеш­но. Для тех, кто не работал с динами­чес­кой мар­шру­тиза­цией, пояс­ню: OSPF (Open Shortest Path First) — это про­токол, с помощью которо­го мар­шру­тиза­торы авто­мати­чес­ки обме­нива­ются информа­цией о сетевой тополо­гии. Работа­ет он так: мар­шру­тиза­торы в одной area (логичес­кой зоне) рас­сыла­ют друг дру­гу Hello-пакеты для уста­нов­ления соседс­тва, а затем обме­нива­ются LSA (Link-State Advertisements) — сооб­щени­ями, опи­сыва­ющи­ми все извес­тные им сети и свя­зи. Из этих LSA каж­дый мар­шру­тиза­тор стро­ит LSDB (Link-State Database), пол­ную кар­ту тополо­гии всей area. Пол­ную. Каж­дый мар­шру­тиза­тор зна­ет про каж­дую под­сеть и каж­дый линк.

Те­перь понят­но, почему OSPF Hello на моем WAN — это катас­тро­фа? OSPF Hello рас­сыла­ются муль­тикас­том на 224.0.0.5, и, если я их вижу, зна­чит, я в одном L2-сег­менте с теми, кто их отправ­ляет. В самом Hello-пакете ука­зан Area ID: из него вид­но, в какой зоне работа­ют соседи. А зна­чит, я могу нас­тро­ить свой OSPF-про­цесс в ту же area, уста­новить adjacency и получить пол­ную LSDB-кар­ту всей сети. Тут сом­невать­ся ста­ло бес­смыс­ленно: про­вай­дер сва­лил всех в общий котел.

Проверяем, насколько все плохо

Окей, чужие про­токо­лы в эфи­ре — это уже нехоро­шо. Но одно дело — видеть широко­веща­тель­ные пакеты, дру­гое — реаль­но дос­тучать­ся до чужих устрой­ств. Я взял MAC-адрес одно­го из соседей из Neighbors и сде­лал MAC Ping, пинг на каналь­ном уров­не, который работа­ет без IP, чис­то по MAC-адре­су. Отве­чает? Отве­чает.

Тог­да я поп­робовал MAC Telnet — проп­риетар­ный про­токол MikroTik, при­думан­ный для удобс­тва юзе­ров: он поз­воля­ет под­клю­чить­ся к кон­соли управле­ния любого RouterOS-устрой­ства в том же L2-сег­менте, исполь­зуя толь­ко MAC-адрес. IP не нужен, мар­шру­тиза­ция не нуж­на — дос­таточ­но находить­ся в одном broadcast-домене. Задумы­валось это для слу­чаев, ког­да роутер све­жий из короб­ки и IP еще не нас­тро­ен. А в нашей ситу­ации это озна­чало: я могу под­клю­чить­ся к кон­соли управле­ния любого из двад­цати пяти сосед­ских MikroTik.

Под­клю­чил­ся. Уви­дел приг­лашение логина чужого роуте­ра. Вво­дить чужие пароли я, разуме­ется, не стал, мне хва­тило самого фак­та.

Но и это еще не всё. Я про­пин­говал нес­коль­ко IP-адре­сов из спис­ка соседей обыч­ным ICMP ping, по треть­ему уров­ню. Устрой­ства отве­тили. То есть меж­ду нами не прос­то общий L2-сег­мент, а есть пол­ноцен­ная IP-связ­ность.

А вот тут мне ста­ло по‑нас­тояще­му страш­но. До это­го момен­та мож­но было уте­шать себя: ну видят устрой­ства друг дру­га, ну пин­гуют­ся, неп­рият­но, но не смер­тель­но. Но я решил пос­мотреть, что еще лета­ет в OSPF-пакетах и какие мар­шру­ты анон­сиру­ются.

Сре­ди чужих пре­фик­сов обна­ружи­лись адре­са, которые явно при­над­лежали не кли­ентам, а самому про­вай­деру. Loopback-интерфей­сы, лин­ковые /30-под­сети меж­ду их мар­шру­тиза­тора­ми. Я про­пин­говал нес­коль­ко из них, они отве­тили.

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

Что с этим может сделать злоумышленник

Ког­да пер­вый шок про­шел, я сел, налил кофе и начал думать: а что бы с этим мог сде­лать кто‑то менее доб­росовес­тный?

Сценарий 1. ARP spoofing — перехват трафика соседей

Это самый оче­вид­ный сце­нарий. В общем L2-сег­менте любой поль­зователь может разос­лать под­дель­ные ARP-отве­ты (gratuitous ARP) и объ­явить себя шлю­зом. Все устрой­ства в сег­менте обно­вят свою ARP-таб­лицу, и тра­фик, пред­назна­чен­ный шлю­зу, потечет через ата­кующе­го. Даль­ше — клас­сичес­кий man-in-the-middle: пароли, которые переда­ются без TLS, содер­жимое HTTP-зап­росов, DNS-зап­росы, токены аутен­тифика­ции. Если у кого‑то из соседей поч­товый кли­ент ходит на POP3 без шиф­рования (а в мел­ких кон­торах такое встре­чает­ся сплошь и рядом) — это прос­то подарок для хакера.

Инс­тру­мен­тарий три­виаль­ный:

• ettercap уме­ет и ARP poisoning, и перех­ват тра­фика, и пар­синг паролей на лету;
• bettercap — более сов­ремен­ная аль­тер­натива с веб‑интерфей­сом и модуля­ми для HTTPS-даун­грей­да;
• arpspoof из пакета dsniff — если хочет­ся сов­сем по‑прос­тому.

Все это есть в Kali из короб­ки.

ARP spoofing хотя бы мож­но заметить: на управля­емых ком­мутато­рах име­ется Dynamic ARP Inspection, да и ано­малии в ARP-таб­лице бро­сают­ся в гла­за. Но это если кто‑то смот­рит. А вот даль­ше начина­ется кое‑что похуже.

Сценарий 2. Брутфорс роутеров через MAC Telnet и не только

MAC Telnet до чужих роуте­ров работа­ет, мы это уже выяс­нили. А раз так, работа­ет и перебор паролей. Сколь­ко из этих двад­цати пяти MikroTik’ов сто­ят с паролем admin/admin или admin без пароля вооб­ще? По моему опы­ту — про­цен­тов сорок, не мень­ше. Мел­кие ком­пании покупа­ют роутер, вты­кают кабель, нас­тра­ивают NAT — и всё, даль­ше им неин­терес­но.

Пе­реби­рать мож­но раз­ными спо­соба­ми. В Metasploit есть модуль auxiliary/scanner/ssh/ssh_login для перебо­ра по SSH. Hydra работа­ет с SSH, Telnet и HTTP-фор­мами (WebFig на 80/443-м пор­те). RouterOS API (порт 8728) исполь­зует собс­твен­ный бинар­ный про­токол — для него готовых модулей в Metasploit нет, но на GitHub есть спе­циали­зиро­ван­ные скрип­ты на Python (нап­ример, RouterOS-API-bruteforce), а так­же соот­ветс­тву­ющий скрипт в NSE Nmap. Для Winbox-про­токо­ла (порт 8291) — отдель­ные инс­тру­мен­ты вро­де winbox-brute.

По­доб­рал пароль, и ты в management-кон­соли чужого роуте­ра. Отту­да вид­на вся внут­ренняя сеть орга­низа­ции: мож­но добавить себя в мар­шрут, нас­тро­ить проб­рос, под­клю­чить­ся к SMB-шарам, камерам наб­людения, прин­терам. Если в сети есть Active Directory, до кон­трол­лера домена обыч­но один‑два хопа.

Сценарий 3. Инъекция маршрутов через OSPF

Вот тут начина­ется по‑нас­тояще­му инте­рес­ное. OSPF в этом сег­менте работа­ет без аутен­тифика­ции. Как я это опре­делил? В заголов­ке каж­дого OSPF-пакета есть поле Auth Type: 0 — без аутен­тифика­ции, 1 — plaintext-пароль, 2 — MD5. В перех­вачен­ных Hello сто­ял ноль. OSPF под­держи­вает аутен­тифика­цию, но по умол­чанию она вык­лючена, и в дан­ном слу­чае ее ник­то не вклю­чил. А зна­чит, нич­то не меша­ет под­нять свой OSPF-про­цесс и влить­ся в area как пол­ноправ­ный учас­тник.