Bezpečnost a bezpečné programování

Bezpečnost a bezpečné programování 1. Úvod do bezpečnosti programování, současná bezpečnost.

Ing. Tomáš Zahradnický, EUR ING, Ph.D.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Příprava studijních programů Informatika pro novou fakultu ČVUT je spolufinancována Evropským sociálním fondem a rozpočtem Hlavního města Prahy v rámci Operačního programu Praha — adaptabilita (OPPA) projektem CZ.2.17/3.1.00/31952 – „Příprava a zavedení nových studijních programů Informatika na ČVUT v Prazeÿ. Praha & EU: Investujeme do vaší budoucnosti T. Zahradnický (ČVUT FIT)

Úvod do bezpečnosti prg., souč. bezpečnost

MI-BPR, 2011, Předn. 1

1 / 37

Obsah I 1

Internet, Wild Wild Web a útočník

2

Požadavky na software

3

Definice bezpečnostních cílů

4

Modelování a vyhodnocování hrozeb

5

Bezpečnost ve vývojové fázi Předpoklady Typicky špatný postup Proč je postup špatný Správný postup

6

Princip SD3 Secure by Design Secure by Default Secure in Deployment

7

Základní bezpečnostní principy T. Zahradnický (ČVUT FIT)



2 / 37

Internet — World Wide Web Fakta o Internetu 2010: Posláno 107 bilionů e-mailů (89.1% SPAM) 255 milionů webových stránek 1.97 miliardy uživatelů internetu 2.9 miliardy e-mailových schránek 5 miliard připojených zařízení

[3]

T. Zahradnický (ČVUT FIT)



3 / 37

Internet — Wild Wild Web I Fakta o Internetu 2010 a důsledky: Bylo-li posláno 107 bilionů e-mailů (89.1% SPAM) za rok, → bylo odesláno průměrně 293 miliard SPAMů za den

Obsahovalo-li v únoru 2011 přibližně 3.18% e-mailů škodlivý kód [2] → dostáváme každý cca 4.7 nebezpečných e-mailů denně → můžeme se spolehnout na zabezpečení?

Není otázkou jestli budeme napadeni, ale kdy! → bezpečnost je naprosto nezbytná

[3]




4 / 37

Internet — Wild Wild Web II Motivy útočníků jsou různé: – Zisk phishing e-maily — zjištění hesel, čísel kreditních karet, kont, . . . viry a červi — krádeže citlivých dat, certifikátů, rozesílání SPAMu, . . . začlenění do botnetů — pronájem botnetů pro další činnost

– Kybernetické útoky; nejčastěji DoS (Denial of Service) útoky internetový útok vládní servery Estonské republiky v r. 2006 útoky na servery MasterCard, VISA a další (Wikileaks) v r. 2010 útoky na servery České pošty, s.p.

– Pro zábavu dokázat si, že takovou věc dokáží (www.zone-h.org) Script Kiddies — „děti,ÿ které používají již vytvořené skripty exploitující existující zranitelnosti. Nejsou hackery v pravém slova smyslu.




5 / 37

Útočník × Vy

Vy

Útočník Útočí když on chce Vybírá si místo útoku vaše nejslabší místo

Nehraje podle pravidel

Musíte být „stále ve střehuÿ Musíte hrát podle pravidel Můžete se bránit jen proti známým typům útoků

Vymýšlí stále nové a nové strategie útoků




6 / 37

Požadavky na software, hrozba, zranitelnost Bezpečný software Je software, který chrání důvěrnost, integritu a dostupnost informace a integritu a dostupnost zpracovávaných prostředků pod kontrolou jeho vlastníka nebo administrátora.

va

lit ní s

of tw ar

e

Bezpečný software

K

Spolehlivý software Je software, který dělá přesně to, k čemu je určen, a nic víc.

Kvalitní software

Spolehlivý software

Obrázek: Kvalitní software [1]

Je software, který je spolehlivý a bezpečný.




7 / 37

Hrozba, zranitelnost Hrozba (Threat) Potenciální příčina nechtěho incidentu, která může vyústit v poškození systému nebo organizace [4].

Příklad hrozby Zaslání podvrženého datagramu službě echo z portu, kde běží chargen.

Zranitelnost (Vulnerability) Slabé místo aktiva nebo skupiny aktiv, které může být využitou jednou nebo více hrozbami [4].

Příklad zranitelnosti Funkce f v programu P obsahuje přetečení bufferu (Buffer overrun), které lze zneužít ke spuštění kódu zadaného útočníkem. T. Zahradnický (ČVUT FIT)



8 / 37

Bezpečnost nesmíme chápat jako překážku . . . přejděte do nastavení již vytvořeného mailového účtu: Nyní postupně vypneme SSL pro příchozí poštu a následně pro odchozí. Nejprve přejděte do nastavení Advanced (Ostatní), vypněte Use SSL (Použít SSL) a vraťte se zpět tlačítkem nahoře . . . How can I disable the User Account Control (UAC) feature on my Windows Vista computer? 1 2

Launch MSCONFIG by from the Run menu. Click on the Tools tab. Scroll down till you find Disable UAC.

How to disable SMB packet signing enforcement? To disable SMB packet signing enforcement on Windows Server 2008–based domain controllers: 1 2

Click Start, click Run, type gpmc.msc, and then click OK. In the console tree, right-click Default Domain Controllers Policy . . .




9 / 37

Bezpečnost Bezpečnost je dnes povinná vlastnost softwaru software, který není bezpečný je nekvalitní chtěli byste takový software používat?

S bezpečností nutno počítat již ve fázi návrhu softwaru, a to: definicí bezpečnostních cílů modelováním a vyhodnocováním hrozeb

Bezpečnostní vlastnosti 6= bezpečné vlastnosti Software, který má bezpečnostní vlastnosti nutně neznamená, že je bezpečný!

!! Bezpečnost chápána že stojí „zbytečnéÿ peníze, proto často opomíjena !! Bezpečnost často přidávána až nakonec existující funkcionalita aplikace obalována bezpečností! často vede k nutnosti redesignu — drahé




10 / 37

Definice bezpečnostních cílů Je nutno určit, kdo je cílový uživatel produktu, a jaké jsou jeho potřeby: Pro koho je software určen? Co znamená slovo bezpečnost pro tuto skupinu uživatelů? V jakém prostředí bude aplikace běžet ( web | pc | embedded | . . . )? Co chráníme? Jaké budou následky, až budou chráněná data kompromitována? Kdo bude spravovat aplikaci ( uživatel | administrátor )? Je produkt interní anebo externí? Jaké bezpečnostní prvky OS může náš produkt využít? Jak můžeme uživatele ochránit před akcemi jeho samého?




11 / 37

#$%&'()*+!

!"#$%"&

2%3"+,4*%,*#3()"%,(3$*#%35(61)7%()*%/03$(+*#%$-,*8

Obrázek: Ukázkový uživatel [1] !"#$%&#'()*&+$#,-#$%&#./0,1$2"+&#,-#("3&1'$2"3."4#$%&#)('."&''#1&5(.1&/&"$'6#78! 9::;;6#<7"-,1/2$.,"#=&+%",>,4?#@#A,3&#,-#012+$.+&#-,1#."-,1/2$.,"#'&+(1.$?#/2"24&B T. Zahradnický (ČVUT FIT)/&"$6CD2"#."$&1"2$.,"2>#'$2"3213#$%2$#+,E&1'#,142".F2$.,"2>6#0%?'.+2>6#+,//(".+2$.,"'6 Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1

12 / 37

Modelování a vyhodnocování hrozeb Proces modelování a vyhodnocování hrozeb vypadá takto: 1 Dekomponujeme software na komponenty tento proces často opakujeme a komponenty rozkládáme dále někdy jdeme i 3-4 úrovně do hloubky! 2

Vytvoříme jejich konceptuální model doplníme vazby mezi komponenty

3

Vytvoříme a popíšeme modely hrozeb

4

Ohodnotíme závažnost jednotlivých hrozeb

použijeme například metodiku STRIDE metodikou DREAD ohodnotíme závažnost hrozeb seřadíme hrozby podle DREAD skóre 5

Navrhneme změny v konceptuálním modelu tak, aby byly dopady minimální

Modelování hrozeb detailně více přednáška č. 2. T. Zahradnický (ČVUT FIT)



13 / 37

Bezpečnost ve vývojové fázi Předpokládáme použití repozitáře zdrojového kódu svn, cvs, Microsoft Visual SourceSafe, Perforce, git, . . .

Check-in1 zdrojového kódu je privilegium, ne právo. Všechny check-iny by měly být kontrolovány dalšími osobami, opravy prováděny „autoryÿ chyb! Všichni členové vývojového týmu by měli být pravidelně školeni Kód by měl být periodicky znovu kontrolován.

1

Nahrání zdrojovéko kódu do repozitáře.




14 / 37

Bezpečnost ve vývojové fázi — Typicky špatný postup 1

Návrh

2

Implementace hlavních vlastností

3

Implementace dalších vlastností

4

Implementace bezpečnosti

5

Testování

6

Oprava chyb

7

Zveřejnění




15 / 37

Bezpečnost ve vývojové fázi — Proč je postup špatný Bezpečnost není prioritou, ponechávána na později. Co když se dostane plán vývoje do skluzu?

Špatný postup

Je nutné dodržet plán! → Ukrátíme bezpečnost –– produkt funguje!

Implementace bezpečnosti „obalenímÿ často vede ke změně designu. Obalujeme existující funkcionalitu bezpečností — zlé! Zabezpečení může vyžadovat i kompletní změnu vlastnosti. Může dojít i ke změně uživatelského rozhraní aplikace.

→ Bezpečnost nutné zahrnout již do plánování. T. Zahradnický (ČVUT FIT)


1

Návrh

2

Implementace hlavních vlastností

3

Implementace dalších vlastností

4

Implementace bezpečnosti

5

Testování

6

Oprava chyb

7

Zveřejnění


16 / 37

Bezpečnost ve vývojové fázi — Správný postup 1

Návrh produktu včetně bezpečnosti

2

Implementace vlastností

3

Testování vlastností a bezpečnosti

4

Opravy chyb

5

Zveřejnění




17 / 37

Základní bezpečnostní principy — SD3 Princip SD3 : 1

Secure by Design

2

Secure by Default

3

Secure in Deployment




18 / 37

SD3 — Secure by Design Bezpečný již ve fázi návrhu Dodržování návrhu a programovacích konvencí například nepoužívání některých API

Programovací konvence by se měly vyvíjet s ohledem na aktuální trendy v bezpečnosti Starý kód a nepoužívané vlastnosti jsou z produktu vyřazovány Provádíme a necháme si provádět penetrační testy produktu Naplánujte běh aplikace s minimálními oprávněními nevyžadujte běh s administátorskými oprávněními, pokud to není absolutně nezbytné vzdejte se všech práv, které nepotřebujete

+ V organizaci by měl být security expert, na kterého se obracíme v případě nejasností + Zaměstnanci periodicky bezpečnostně proškolování T. Zahradnický (ČVUT FIT)



19 / 37

SD3 — Secure by Default Výchozí instalace je nejvíce bezpečná 90% uživatelů zvolí výchozí instalaci výchozí nastavení aplikace po výchozí instalaci je bezpečné může mít negativní dopad na uživatele

Neinstalujte všechny vlastnosti ve výchozí instalaci je zbytečné instalovat méně používané vlastnosti poskytněte možnosti snadné doinstalace

Zabezpečte všechny prostředky, které představují citlivá data a jsou potenciálním cílem útoků Vyžadujte minimální oprávnění vzdejte se všech práv, které nepotřebujete pokud už musíte X udělat jako administrátor, spusťte nový proces, který umí udělat pouze X a nic víc.




20 / 37

SD3 — Secure in Deployment Aplikace by měla obsahovat nastavení bezpečnosti Vydávejte bezpečnostní záplaty promptně v reakci na nalezené zranitelnosti Poskytněte uživateli dostatek informací o tom, jak používat produkt bezpečně Dokumentace, tipy na obrazovce, ale i chybová hlášení.




21 / 37

Základní bezpečnostní principy 1 2 3 4 5 6 7 8 9 10 11 12 13

Učení se z předešlých chyb Minimizace počtu bodů útoku Bezpečné výchozí nastavení Víceúrovňová bezpečnost Použití nejmenších oprávnění Zpětná kompatibilita je vždy bezpečnostní problém Externí systémy jsou nebezpečné Plánujte selhání Selhání do bezpečného módu Security features 6= secure features Security through obscurity Nemíchejte kód a data Opravujte správně bezpečnostní záležitosti




22 / 37

Základní bezp. principy –– Učení se z předešlých chyb Při nalezení chyby je nutné se ptát: Jak se stala? Může se stejná chyba objevit i v jiných částech kódu? Jak jsme se této chyby mohli vyvarovat? Jak zaručíme, že se tato chyba již nebude opakovat? (Ne)Potřebujeme proškolit vývojový tým anebo lepší nástroje?




23 / 37

Základní bezp. principy –– Minimizace počtu bodů útoku Za možné body pro útok považujeme: otevřené sokety pojmenované roury koncové body pro RPC běžící služby webové stránek s dynamickým obsahem (PHP, ASP, . . . ) účty s administrátorskými oprávněními soubory, adresáře a klíče v registrech se slabými ACL




24 / 37

Základní bezp. principy –– Bezpečné výchozí nastavení Výchozí instalace má být: Bezpečná Méně bezpečné součásti by měly být snadno doinstalovatelné Pro určení množiny výchozích vlastností je vhodné použít Paretovo pravidlo: Kterých 20% vlastností je využíváno 80% uživatelů?




25 / 37

Základní bezp. principy –– Víceúrovňová bezpečnost Bezpečnost vždy na více úrovních Nespoléhejme na firewall, antivirový software Nutno počítat s tím, že všechny ostatní vrstvy byly prolomeny




26 / 37

Základní bezp. principy –– Víceúrovňová bezpečnost Bezpečnost vždy na více úrovních Nespoléhejme na firewall, antivirový software Nutno počítat s tím, že všechny ostatní vrstvy byly prolomeny ACL

File sharing Firewall

IDS/IPS




26 / 37

Základní bezp. principy –– Použití nejmenších oprávnění Lidé často pracují jako lokální administrátoři. A vy? → Získá-li škodlivý kód kontrolu nad procesem, disponuje právy, se kterými byl proces spuštěn! → Oprávnění, které nemáte nemůže být zneužito. → Vzdejte se všech oprávnění, které absolutně nepotřebujete. Windows: Pokud si proces vyjme právo, nemůže jej již získat zpět! (WinAPI AdjustTokenPrivileges)

Pokud už musíte něco udělat se zvýšenými oprávněními, udělejte: Nový proces, který provede pouze úkol, který vyžaduje administrátorská oprávnění (WinAPI ShellExecute a CreateProcess) Uživatel rozhodne zda spuštění nového procesu s jinými credentials, které mají patřičné oprávnění, povolí. Napadnout takto nově spuštěný proces bude velmi složité, zvlášť když nemá téměř žádný prostor pro útok.




27 / 37

Základní bezp. principy –– Zpětná kompatibilita je vždy bezpečnostní problém Často lze nastavit software (ale i hardware) ke kompatibilitě se staršími zařízeními Ta již nejsou bezpečná — nejsou pro ně bezpečnostní záplaty a nepodporují nejnovější bezpečnostní standardy → bezpečnostní riziko !! notebook z roku 2000 se nepřipojí k Wifi se 128b šifrováním. Dilema: Snížíme zabezpečení na 40b, anebo notebook nepřipojíme?

Dovolíte-li, aby se úroveň zabezpečení nastavila domluvou mezi účastníky (negotiate) na nejvyšší možnou, pak útočník zneužije právě této vlastnosti a domluví si takovou úroveň zabezpečení, kterou umí prolomit. → Je třeba být velmi opatrný se zpětnou kompatibilitou.




28 / 37

Základní bezp. principy –– Externí systémy jsou nebezpečné Externí systémy vám poskytují vstup máme jistotu, že dotyčný, se kterým komunikujeme, je opravdu ten, za koho se vydává? → předpokládejme, že ne!

Vstup = zlo veškerý vstup musíme bereme jako škodlivý, dokud se jeho důkladným prověřením (validací) nepřesvědčíte o opaku jinak se vystavujeme nebezpečí útoku (např. XSS, SQL Injection, DoS útoky, . . . )




29 / 37

Základní bezp. principy –– Plánujte selhání Murphyho zákon Jestliže se něco může nepodařit, tak se to také nepodaří.

Murphyho zákon — druhá základní věta Všechno se nepodaří současně.

Murphyho zákon — čtvrtá elektronická aplikace U počítačů se nedá na nic spolehnout. Ani na to, že se nedá na nic spolehnout. Selhání je nevyhnutelné. Plánujte co se stane, pokud je prolomen firewall, zabezpečení aplikace, webová stránka, přístup odmítnut.




30 / 37

Základní bezp. principy –– Selhání do bezpečného módu I Selhání z bezpečnostních důvodů musí selhat bezpečně.

Chybně DWORD err = IsAccessAllowed(...); if (err == ERROR_ACCESS_DENIED) { // Security check failed. // Inform user that access is denied. } else { // Security check OK. // Perform task. } Co se stane, když volání funkce IsAccessAllowed selže z jiného než bezpečnostního důvodu?




31 / 37

Základní bezp. principy –– Selhání do bezpečného módu II Správně DWORD err = IsAccessAllowed(...); if (err == NO_ERROR) { // Security check OK. // Perform task. } else { // Security check failed. // Inform user that access is denied. } Odmítněte všechny, kteří se neprokáží že mají přístup!




32 / 37

Základní bezp. principy –– Security features 6= secure features Program je tak bezpečný, jak bezpečná je jeho nejslabší část. Skutečnost, že aplikaci zabezpečíte (např. přidáním šifrování) ji nutně nemusí dělat bezpečnou nakládání a používání šifer má svá přesná pravidla co když bude šifrovací klíč nastaven napevno v aplikaci takto bylo prolomeno šifrování CSS používané na DVD

Nač používat nutně SSL, když je aplikace zranitelná zcela jiným způsobem? místa pro zabezpečení vyplynou z fáze modelování hrozeb.




33 / 37

Základní bezp. principy –– Security through obscurity Zabezpečení skrýváním Účinná metoda ke zmatení útočníků Neposkytuje zabezpečení, systém je stále stejně zranitelný! Zahrnuje také použití obfuskace:

Co dělá tento JavaScript? [5] ([],[][([![]]+[])[++[++[++[[]][+[]]][+[]]][+[]]]+([]+{})[++ [[]][+[]]]+([!![]]+[])[++[[]][+[]]]+([!![]]+[])[+[]]])()[ (+[][+[]]+[])[++[[]][+[]]]+([![]]+[])[++[++[[]][+[]]][+[]]] +([!![]]+[])[++[++[++[[]][+[]]][+[]]][+[]]]+([!![]]+[])[++[ []][+[]]]+([!![]]+[])[+[]]](++[[]][+[]]) Nikdy nespoléhejte pouze na „security by obscurityÿ. Používejte ji jako doplněk zabezpečení. T. Zahradnický (ČVUT FIT)



34 / 37

Základní bezp. principy –– Nemíchejte kód a data Spouštět kód jako součást dat je mocná vlastnost, která vás okamžitě postaví před hrozbu spuštění škodlivého kódu útočníkem. Příklady kódu v datech: E-mailové přílohy — jako příloha je spustitelný kód, který může obsahovat viry. JavaScript v HTML — nebezpečí XSS. Když už musíte: Nechte rozhodnutí zda spustit na uživateli. Výchozí nastavení jako nespouštět.




35 / 37

Základní bezp. principy –– Opravujte správně bezpečnostní záležitosti Když je nalezena zranitelnost, tak: Je nezbytné ji neprodleně opravit, a to v místě výskytu chyby. Projít celý kód a zjistit, kde všude se mohla stejná chyba propagovat. Důkladně záplatu otestovat, hlavně na regresi2 . Vydat záplatu. Zatajování zranitelností: Zranitelnosti jsou často zatajovány. To vede ke konspiračním teoriím a špatné (vaší) publicitě.

2

Regrese nastává způsobí-li oprava nefunkčnost některé vlastnosti produktu.




36 / 37

Bibliografie Howard M., LeBlanc D.: Writing Secure Code, 2nd edition, Microsoft Press, 2003. Namestnikova M.: Spam report: February 2011, http://www.securelist.com/en/analysis/204792167/Spam report February 2011. Pingdom AB: Internet 2010 in numbers, http://royal.pingdom.com/2011/01/12/internet-2010-in-numbers/, Pingdom AB, Vasteras, Sweden, 2011. ISO/IEC 27002: Information technology — Security techniques — Code practice for information security management, 2005. Lupták P.: Bypassing Web Application Firewalls (WAFs), http://www.slideshare.net/nethemba/bypassing-web-applicationfirewalls?src=embed. T. Zahradnický (ČVUT FIT)



37 / 37

Bezpečnost a bezpečné programování

Recommend Documents