Ваш VPN пролаз је компромитован: шта је заправо изложено

VPN пролаз стоји на крају тунела који штити, што значи да прекида ту енкрипцију уместо да је пропушта даље. Ако нападач контролише хост, тунел споља и даље изгледа здраво, док машина у средини више није поуздана. Корисно питање није да ли је све дешифровано. Питање је шта је тај хост могао видети, докле је могао доћи и које су тајне на њему заиста биле сачуване. Та три одговора се много разликују, а и реакција се разликује са њима.

Пролаз прекида тунел, па види унутар њега

Енкрипција у VPN-у иде хоп по хоп, а пролаз је тај хоп. Он скида спољни слој, примењује политику и прослеђује унутрашњи пакет, па сваки пренесени пакет у неком тренутку постоји у читљивом облику у меморији тог хоста. То је дизајн, а не пропуст. Зато је компромитација пролаза другачији догађај од компромитације криптографије тунела.

Прво што нападач добија јесте позиција: могућност да посматра пренесени саобраћај, мења прослеђивање или одговара уместо backend система. Шта добија даље зависи од хоста, и ту људи претерују. Сам приступ пролазу не предаје TLS сесијске кључеве прегледача, јер они никада нису били на пролазу.

Три излагања која нису исте величине

Поделите питање на пренесени саобраћај, доступне системе и сачуване тајне, па одговорите на свако засебно.

Средњи ред је онај који се прескаче. Пролаз обично има руту у приватне мреже и изворну адресу којој backend системи већ верују, па је занимљиво питање шта ти backend системи дозвољавају са те адресе. Уска политика клијентског приступа је добра контрола, али нападач на хосту није ограничен на интерфејс који би користио нормалан клијент.

Доњи ред одлучује колико инцидент траје. Серверски кључ и CA кључ имају потпуно различите радијусе удара, као и локални администраторски налог и токен за надзор само за читање.

HTTPS унутар тунела и даље је HTTPS

TLS апликације прекида се у апликацији, а не на VPN пролазу, па компромитован пролаз за те токове види шифрат. То је стварно ограничење онога што нападач добија и вреди то јасно рећи, јер супротна тврдња шири панику и лоше одлуке. Два услова то руше. Ако је на путу компонента за инспекцију са поузданим сертификатом, пролаз може по дизајну да види чист текст. Ако је сама крајња тачка апликације компромитована, тунел није релевантан.

Зато је одговор на питање шта су видели услован, и треба га записати као услове, а не објавити као пресуду.

Шта мора да се промени пре него што му поново верујете

Поновно постављање хоста је неопходно и ретко довољно. Нападач који још држи управљачки налог, акредитив за имплементацију или кључ за потписивање може да врати хост како жели. Опоравак мора да почне од административног пута који не зависи од компромитоване машине.

Пре него што одлучите шта да ротирате, направите попис онога што је било на њему. Кључеви, сервисни налози, API токени, локални корисници, заказани послови, односи поверења и имплементациони pipeline сви су кандидати, а сваки има власника који би то требало да потврди.

ss -lntup
getent passwd
crontab -l
ip route show table all

Тај списак је најбржи начин да видите шта је хост нудио и докле је могао да дође. Прво сачувајте доказе, према процесу власника одговора, јер поновно постављање уништава управо оно што је истрази потребно. NIST SP 800-61 Ревизија 3 третира припрему, откривање, одговор и опоравак као делове једног процеса ризика, а не као упутство за поновно покретање.

Границе које следећи случај чине јефтинијим

Четири границе вреди изградити пре него што вам затребају. Држите независан пут опоравка који се не аутентификује кроз пролаз. Држите овлашћење за потписивање одвојено од хоста који опслужује саобраћај. Ограничите докле пролаз може да дође, да компромитован пролаз не буде аутоматски компромитована управљачка мрежа. И забележите коме припада сваки акредитив, да ротација буде телефонски позив уместо археолошког пројекта.

Ниједна од ових не спречава компромитацију. Оне је ограничавају и чине разлику између лоше недеље и лошег квартала.