Друзья, вот уже мно­го лет наш жур­нал пишет о том, как сло­мать то или это с одной сто­роны или как пра­виль­но защитить и что делать, что­бы это не сло­мали. Мно­гие в ИБ‑тусов­ке называ­ют такую кон­цепцию «взлом/защита» гон­кой и про­тивос­тоянием, что, в прин­ципе, логич­но и понят­но, но если смот­реть с дру­гой точ­ки зре­ния, то вся эта борь­ба — единс­твен­ный путь к недося­гаемо­му совер­шенс­тву, ста­биль­ному и надеж­ному ПО. Давай же поп­робу­ем огля­нуть­ся на то, что было сде­лано за пос­ледние нес­коль­ко лет в мире безопас­ности для решения этой проб­лемы.
 

Что есть безопасность

Так как тема широкая и доволь­но мно­гог­ранная, мы не смо­жем обой­ти сто­роной повес­тво­вание в сти­ле «люди и события», но все же будем смот­реть на этот воп­рос более акценти­рован­но — ата­ка/нападе­ние, допус­тим на при­мере перепол­нения буфера. Резюми­руя: давай пос­мотрим, как живут уяз­вимос­ти в ПО (на при­мере перепол­няшки), как раз­работ­чики ПО «отве­чали» этой проб­леме, ну и как финал этой рет­роспек­тивы — поп­робу­ем про­ана­лизи­ровать бли­жай­шее будущее и раз­витие ПО в целом.

 

Начало

При­нято счи­тать, что изна­чаль­но о безопас­ной раз­работ­ке ПО ник­то в мире не думал, аж до чер­вя Мор­риса, и лишь потом появи­лись CERT и началась дви­жуха с безопас­ной раз­работ­кой и так называ­емы­ми менед­жерами. Нап­ример, нас­коль­ко мне извес­тно, имен­но червь Мор­риса содер­жал пер­вый «докумен­тирован­ный» экс­плойт перепол­нения буфера. Да, как мы зна­ем, одна из самых популяр­ных и извес­тных уяз­вимос­тей — перепол­нение буфера, и впер­вые мир пос­тра­дал от нее в нояб­ре 1988 года, одна­ко до сих пор мы стал­кива­емся с этой уяз­вимостью в сов­ремен­ных прог­рам­мных про­дук­тах.

Бы­ло бы, кста­ти, неп­равиль­но не отме­тить, что в 1988 году Мор­рис показал экс­плойт миру, но по фак­ту об этой проб­леме было извес­тно аж с 1972 года! Имен­но тог­да Джей­мс Андерсон и груп­па дру­гих спе­циалис­тов (работа­ющих на пра­витель­ство, а кон­крет­но на ВВС США) выпус­тили работу Computer Security Technology Planning Study. В этой работе при­сутс­тву­ет ана­лиз угроз и атак для компь­ютер­ных тех­нологий, акту­аль­ных тог­да для ВВС США csrc.nist.gov/publications/history/ande72.pdf. Имен­но тог­да было сфор­мулиро­вано мно­жес­тво инте­рес­ных тем, от тро­янско­го коня до недове­рия к обра­баты­ваемым поль­зователь­ским дан­ным. В кон­тек­сте пос­ледне­го и были выяв­лены угро­зы работы с ука­зате­лями (типа HeartBleed), и перепол­нений буфера. То есть уже в 1972 году отдель­ные орга­низа­ции были оза­даче­ны проб­лемами безопас­ности ПО, одна­ко и в 2014-м мы име­ем все те же самые проб­лемы. Конеч­но, сто­ит при­нимать во вни­мание слож­ность и мас­штаб. Все‑таки в пер­вую оче­редь ПО — это эффектив­ный инс­тру­мент для ведения биз­неса и про­чих дел, в 80-х компь­ютер уже не был ред­костью в работе запад­ных ком­паний, а в 90-х воп­росы ИБ ста­ли более акту­аль­ными.

На­до ска­зать, что с 1961-го по 1988-й безопас­ность прог­рам­мно­го обес­печения была воп­росом логики и архи­тек­туры, и, нес­мотря на то что еди­ницы (будь то инже­неры при пра­витель­стве США или еди­нич­ные хакеры) находи­ли и экс­плу­ати­рова­ли уяз­вимос­ти ПО, сис­темно­го и мас­сового раз­вития эта тема не получа­ла. К тому же боль­шинс­тво атак в 80-е так­же были «сис­темны­ми» и исполь­зовали не уяз­вимос­ти в ПО, а ско­рее челове­чес­кий фак­тор, типа пароли по умол­чанию и докумен­тирован­ные осо­бен­ности сис­темы нес­тандар­тным обра­зом. То есть не было боль­шой угро­зы, и сущес­тво­ванию ПО (как про­дук­та) угро­зы не было, поэто­му дей­ствия раз­работ­чиков была реак­тивны­ми, а не про­активны­ми: есть проб­лема — устра­ним. Такой под­ход был впол­не рабочим до тех пор, пока количес­тво проб­лем и атак не начало рас­ти так, что перехо­дило в реаль­ную угро­зу. Угро­зу не кон­крет­ному кли­енту с про­дук­том, а угро­зу сущес­тво­ванию все­го про­дук­та, идеи или тех­нологии, гло­баль­ной безопас­ности. Подумай сам: если бы уяз­вимос­ти в ПО не фик­сились и любой человек мог получить пол­ный дос­туп к тво­ему ПК, ты бы прос­то перес­тал поль­зовать­ся ПК или искал бы конт­рме­ры. Вот раз­работ­чики и ста­ли дей­ство­вать про­активно где‑то в 1990-х, а кто‑то и в начале 2000-х.

Фон Нейман. Тот, кто создал BoF
Фон Ней­ман. Тот, кто соз­дал BoF

Вер­немся к нашей проб­леме, с которой мы начали: перепол­нение буфера. Итак, о проб­леме было извес­тно с 1972 года, одна­ко пер­вая ата­ка с исполь­зовани­ем этой уяз­вимос­ти датиро­вана 1988 годом. Кажет­ся, что 26 лет — это мно­го, но сто­ит пом­нить, что рас­простра­нение ПО и компь­юте­ров не было мас­совым, да и воз­можнос­ти про­водить такие ата­ки были очень огра­ничен­ными (интерне­та не было, сер­висов, дос­тупных по сетям, — тоже не осо­бо). Теория ста­ла прак­тикой, ког­да появи­лись век­торы ата­ки, а до того это было неак­туаль­но.

 

Эволюция

Итак, с 1972-го по 1988-й ата­ка у нас была теоре­тичес­кая, но извес­тная. В сле­дующий пери­од сети и тех­нологии, интернет и BBS раз­вивались в стра­нах, которые были далеки от все­го это­го. Раз­работ­чики про­дол­жали писать софт, воз­можно подоз­ревая о каких‑то мифичес­ких ата­ках, но раз­ницы в мотива­ции и кон­крет­ных дей­ствий по срав­нению с тем, что было до 1988 года, не наб­людалось. Все оста­лось как было. Поч­ти. На самом деле кон­цепция фаз­зинга, для тес­тирова­ния ПО в том чис­ле и с целью поис­ка оши­бок вво­да и перепол­нения буфера, появи­лась поч­ти сра­зу пос­ле чер­вя Мор­риса, в 1990 году ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf. Одна­ко зачем это нуж­но раз­работ­чикам, для которых такое явле­ние ско­рее науч­ный про­ект, чем выгод­ный биз­нес, пока неяс­но. Но с дру­гой сто­роны бар­рикад все менялось — хакеров ста­нови­лось все боль­ше и боль­ше, информа­ция рас­простра­нялась (Фидо, интернет), как и леген­ды.

Так, сле­дующий извес­тный мне пуб­личный экс­плойт на перепол­няшку появил­ся в 1995 году seclists.org/bugtraq/1995/Feb/109. Немец прос­то пос­тавил NCSA HTTPD и, так как он читал про чер­вя Мор­риса, по ана­логии нашел такую же проб­лему и в этом HTTP-сер­висе, о чем и отпи­сал в соз­данный в 1993 году лист рас­сылки bugtraq. Клас­сика в чис­том виде. Поз­же появ­лялись еди­нич­ные спло­иты, так, за 1995 год их было опуб­ликова­но аж целых два. Короче было это дело тех, кто самос­тоятель­но может про­ана­лизи­ровать ана­логи, понять, как работа­ет, и при­менить эти зна­ния на новом объ­екте. При этом тех­ника и идея не силь­но меня­ется. Разуме­ется, было и мно­жес­тво при­ват­ных экс­плой­тов, которые не попада­ли в баг­трек, но все рав­но мас­шта­бы были не такие, как, допус­тим, в наше вре­мя.

Роберт Моррис (C:/Users/User/Downloads/rm.png). Тот, кто заюзал BoF
Ро­берт Мор­рис (C:/Users/User/Downloads/rm.png). Тот, кто заюзал BoF

Од­нако в 1996 году выходит популяр­ная работа, которая под­робно раз­жевыва­ет шаги по экс­плу­ата­ции этой уяз­вимос­ти, фак­тичес­ки учеб­ник для нович­ков — www.phrack.org/issues/49/14.html#article. И надо ска­зать, что это дало ход делу. Экс­плой­тов ста­ло появ­лять­ся все боль­ше и боль­ше, учи­тывая, что интернет уже был доволь­но рас­простра­нен­ным и ПК и сер­висов было уже очень мно­го, да и само ПО ста­нови­лось слож­нее и избы­точ­нее в коде. Короче, целей для атак ста­ло мно­го, а глав­ное — век­тор ата­ки стал прос­тым и реаль­ным, а зна­ния дос­тупны­ми. К сло­ву ска­зать, основная цель атак — сетевые и локаль­ные сер­висы. Оче­вид­но, что име­ется некая гло­баль­ная проб­лема в безопас­ности, которая осно­вана на фун­дамен­таль­ных прин­ципах фун­кци­они­рова­ния компь­юте­ра (фон­ней­манов­ская архи­тек­тура), а пос­коль­ку ПО ста­ло важ­ной частью биз­неса и жиз­ни мно­гих людей, необ­ходимо пред­при­нимать какие‑то дей­ствия. Уже в 1998 году (за год до) на кон­ферен­ции USENIX Security Symposium году был пред­став­лен StackGuard — тех­нология защиты адре­са воз­вра­та с помощью stack canaries. И тут уже дей­стви­тель­но начина­ет работать прин­цип гон­ки: «вот вам защита» с одной сто­роны и «а я тог­да обой­ду ее так» — с дру­гой. Оче­вид­но, что это луч­ший спо­соб эво­люции для ПО, и раз­работ­чики при­няли вызов: cта­ло нерен­табель­ным для биз­неса делать ущер­бное ПО, а пос­тоян­но латать дыры еще и дороже, чем пытать­ся изна­чаль­но их не допус­кать. Индус­трия ИБ начина­ет рас­ти где‑то в это вре­мя, но мы не будем рас­смат­ривать всю кар­тину, так как огра­ничи­ваем­ся толь­ко перепол­нени­ем буфера.

В 2001 году Билл Гей­тс ска­зал, что так даль­ше жить нель­зя, и вло­жил в безопас­ность сво­ей, безум­но популяр­ной ОС огромные день­ги. Разуме­ется, это не работа­ет сра­зу, и пер­вые пло­ды появи­лись лишь в середи­не 2000-х: и защита адре­са воз­вра­та, и SEH-обра­бот­ка, и под­дер­жка бита NX — все это резуль­тат той борь­бы. Разуме­ется, хакеры так­же не сидели на мес­те, и было опуб­ликова­но мно­жес­тво экс­плой­тов и работ на тему обхо­да этих защит­ных механиз­мов, про что мы не раз писали (так как в это вре­мя и наш жур­нал стал вно­сить леп­ту в эту борь­бу, рас­простра­няя информа­цию). В Open Source мире, так же как и в MS, очень охот­но при­нима­ли под­дер­жку все­го, что помога­ло защитить­ся от этой напас­ти, — DEP, PIE, FORTIFY. Тем не менее проб­лемы обратной сов­мести­мос­ти, необ­ходимость в под­дер­жке этих вещей сто­рон­ними раз­работ­чиками (а тут у нас челове­чес­кий фак­тор) — все это дела­ет наш мир пока еще несовер­шенным. Кро­ме того, раз­работ­чики ста­ли исполь­зовать раз­личные парадиг­мы безопас­ной раз­работ­ки — во всех соф­твер­ных ком­пани­ях, для которых безопас­ность про­дук­та — важ­ный показа­тель качес­тва и ответс­твен­ности, име­ются про­цеду­ры фаз­зинга, ана­лиза кода на уяз­вимос­ти, обу­чение прог­раммис­тов навыкам безопас­ного кодин­га и так далее.

Уже в кон­це 2000-х прак­тичес­ки перес­тали появ­лять­ся боевые экс­плой­ты с перепол­нени­ем буфера под сетевые сер­висы (Windows/*nix — не важ­но). Вооб­ще говоря, уже в середи­не 2000-х акцент экс­плой­тов на перепол­няшку смес­тился на кли­ент­ское популяр­ное ПО. Нап­ример, ког­да в начале 2000-х раз­работ­чики «сер­верных» ком­понен­тов подош­ли более кон­крет­но к валида­ции поль­зователь­ских дан­ных и смог­ли сни­зить количес­тво уяз­вимос­тей к кон­цу 2000-х, раз­работ­чики кли­ент­ских прог­рамм не видели проб­лем и спох­ватились лишь тог­да, ког­да хакеры переш­ли на них (а до это­го было нерен­табель­но, не было пот­ребнос­ти).

 

Сейчас

В дан­ный момент защита от BoF — это дело раз­работ­чика (не допус­тить ошиб­ки, под­держать тех­нологии защиты), ОС (пре­дос­тавить методы стра­хов­ки от экс­плу­ата­ции), поль­зовате­ля (оза­дачить­ся рис­ком для себя и, нап­ример, пос­тавить EMET) и даже железа (ага, нап­ример, в 2005 году не все про­цес­соры под­держи­вали NX-бит). Есть тут мес­то и хакерам — они пос­тоян­но заин­тересо­ваны во взло­ме все­го это­го сте­ка защиты, и если они это смог­ли сде­лать, то зна­чит, с той сто­роны сде­лали не все, что­бы защитит­ся. Эта борь­ба про­дол­жится до тех пор, пока хакеры не перей­дут на что‑то более пер­спек­тивное и лег­кое (в любом смыс­ле — про­дукт, тип уяз­вимос­ти или поль­зовате­ля). В целом вся эта эко­сис­тема дела­ет эво­люци­онное раз­витие всей сис­темы — уже сей­час экс­плой­ты на перепол­нение появ­ляют­ся в основном для мел­ких или экзо­тичес­ких про­дук­тов, «вой­на» еще не закон­чена, но путь с 1972-го до 2014-го очень зна­читель­ный и показа­тель­ный — с рос­том зна­чимос­ти сетей и компь­юте­ров рас­тет и зна­чимость безопас­ности. Основной этап борь­бы все же про­шел с 1996 до 2012 года (мои внут­ренние ощу­щения), для того, что­бы осоз­нать, как побеж­дать проб­лему и что это воз­можно (с некото­рой очень высокой веро­ятностью). Все­го это­го бы не было без всех учас­тни­ков событий — без хакеров, без инже­неров и даже, как ни стран­но, без менед­жеров и биз­несме­нов, прос­то каж­дый выпол­няет свою роль.

 

Будущее

Че­лове­чес­кий фак­тор пока что глав­ная проб­лема несовер­шенс­тва — даже имея все тех­нологии и методы защиты от такой проб­лемы, как BoF, мы все еще их встре­чаем. Как ска­зано выше — сей­час это не Google и Microsoft, а более мел­кие вен­доры, которые не стол­кну­лись с зна­чимостью безопас­ности сво­их про­дук­тов, что логич­но. Но дру­гая реаль­ность видит­ся мне более зна­чимой проб­лемой для нас. Пов­торя­ется исто­рия 80–90-х — было мно­го важ­ного и уяз­вимого ПО, но оно было изо­лиро­вано от хакеров, поэто­му раз­работ­чики, даже зная, что у них есть уяз­вимос­ти (хотя бы в теории), игно­риро­вали эту проб­лему по при­чине нерен­табель­нос­ти и зна­чимос­ти — нет угро­зы. При­мер АСУ ТП — софт там такой же, как и вез­де, а вот решений проб­лем безопас­ной раз­работ­ки в кон­тек­сте сов­ремен­ных угроз мало. Сооб­щес­тво раз­работ­чиков АСУ ТП было не готово встре­тить тот факт, что кто‑то смо­жет и будет ата­ковать их про­дук­ты. Учи­тывая, что дос­тупность АСУ ТП сетей через интернет пока не очень обширна, мы не име­ем проб­лем с реаль­ными ата­ками в мас­се. Пока это еди­нич­ные слу­чаи, которые осно­ваны на куче усло­вий, вро­де заразить флеш­ку или под­рубить­ся к токовой линии, — век­торы реаль­ны, но не мно­гочис­ленны, а инци­ден­тов мало. Поэто­му поезд едет мед­ленно.

C дру­гой сто­роны, я вижу автопро­изво­дите­лей, которые выводят авто­моби­ли в сети, в том силе и в интернет и в ради­ока­налы, — со сла­бо под­готов­ленным для сов­ремен­ных угроз ПО. И я сме­ло ван­гую, что сле­дующие десять лет прой­дут не под лозун­гом безопас­ности АСУ ТП, а под лозун­гом безопас­ности авто­моби­лей и появят­ся пер­вые экс­плой­ты, в том чис­ле и RCE под реаль­ные машины. Про­изво­дите­ли авто прек­расно зна­ют, что эра их взло­мов идет, но ста­ли думать они об этом нем­ного поз­дно: к сожале­нию, обновле­ние про­шивок для ком­понен­тов авто­моби­ля и ОС — про­цесс не сов­сем отла­жен­ный и прос­той. Поэто­му я верю, что BoF воз­родит­ся, прос­то в дру­гой сре­де. Тем не менее дорож­ка по защите про­топ­тана — ОС QNX и ARM-чипы (которые исполь­зуют­ся в тач­ках) под­держи­вают и NX, и ASLR. Ребята, мы дела­ем будущее, и неваж­но, с какой сто­роны. Хакер ли ты и пуб­лику­ешь ресерч, как ломать, или ты менед­жер, внед­ряющий SDLC, — все мы часть боль­шой эко­сис­темы, и резуль­тат наших тру­дов один — более совер­шенные тех­нологии, ПО и мир!

Оставить мнение