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

Transkript

1 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

2 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 SD 3 Secure by Design Secure by Default Secure in Deployment 7 Základní bezpečnostní principy T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 2 / 37

3 Internet World Wide Web Fakta o Internetu 2010: Posláno 107 bilionů ů (89.1% SPAM) 255 milionů webových stránek 1.97 miliardy uživatelů internetu 2.9 miliardy ových schránek 5 miliard připojených zařízení [3] T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 3 / 37

4 Internet Wild Wild Web I Fakta o Internetu 2010 a důsledky: Bylo-li posláno 107 bilionů ů (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% ů škodlivý kód [2] dostáváme každý cca 4.7 nebezpečných ů denně můžeme se spolehnout na zabezpečení? Není otázkou jestli budeme napadeni, ale kdy! bezpečnost je naprosto nezbytná [3] T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 4 / 37

5 Internet Wild Wild Web II Motivy útočníků jsou různé: Zisk phishing y 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 útoky na servery MasterCard, VISA a další (Wikileaks) v r útoky na servery České pošty, s.p. Pro zábavu dokázat si, že takovou věc dokáží ( Script Kiddies děti, které používají již vytvořené skripty exploitující existující zranitelnosti. Nejsou hackery v pravém slova smyslu. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 5 / 37

6 Útočník Vy Útočník Útočí když on chce Vybírá si místo útoku vaše nejslabší místo Nehraje podle pravidel Vymýšlí stále nové a nové strategie útoků Vy 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ů T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 6 / 37

7 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. Spolehlivý software Je software, který dělá přesně to, k čemu je určen, a nic víc. Kvalitní software Je software, který je spolehlivý a bezpečný. Bezpečný software Kvalitní software Spolehlivý software Obrázek: Kvalitní software [1] T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 7 / 37

8 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) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 8 / 37

9 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 Launch MSCONFIG by from the Run menu. 2 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 Click Start, click Run, type gpmc.msc, and then click OK. 2 In the console tree, right-click Default Domain Controllers Policy... T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn. 1 9 / 37

10 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 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é T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

11 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? T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

12 !"#$%"& #$%&'()*+! 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! 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 / 37

13 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 použijeme například metodiku STRIDE 4 Ohodnotíme závažnost jednotlivých hrozeb 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) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

14 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-in 1 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

15 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í T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

16 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? 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í. Š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í T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

17 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í T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

18 Základní bezpečnostní principy SD 3 Princip SD 3 : 1 Secure by Design 2 Secure by Default 3 Secure in Deployment T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

19 SD 3 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) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

20 SD 3 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

21 SD 3 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í. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

22 Základní bezpečnostní principy 1 Učení se z předešlých chyb 2 Minimizace počtu bodů útoku 3 Bezpečné výchozí nastavení 4 Víceúrovňová bezpečnost 5 Použití nejmenších oprávnění 6 Zpětná kompatibilita je vždy bezpečnostní problém 7 Externí systémy jsou nebezpečné 8 Plánujte selhání 9 Selhání do bezpečného módu 10 Security features secure features 11 Security through obscurity 12 Nemíchejte kód a data 13 Opravujte správně bezpečnostní záležitosti T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

23 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? T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

24 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 T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

25 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ů? T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

26 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 T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

27 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 T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

28 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

29 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

30 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,... ) T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

31 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

32 Základní bezp. principy Selhání do bezpečného módu I Chybně Selhání z bezpečnostních důvodů musí selhat bezpečně. 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? T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

33 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! T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

34 Základní bezp. principy Security features 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

35 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) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

36 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: ové 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

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 regresi 2. 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. T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37

38 Bibliografie Howard M., LeBlanc D.: Writing Secure Code, 2 nd edition, Microsoft Press, Namestnikova M.: Spam report: February 2011, report February Pingdom AB: Internet 2010 in numbers, Pingdom AB, Vasteras, Sweden, ISO/IEC 27002: Information technology Security techniques Code practice for information security management, Lupták P.: Bypassing Web Application Firewalls (WAFs), T. Zahradnický (ČVUT FIT) Úvod do bezpečnosti prg., souč. bezpečnost MI-BPR, 2011, Předn / 37