You are on page 1of 36

Part IV: Software

Part 4  Software 1
Why Software?
 Mengapa pengamanan software penting..
seperti halnya crypto, access control, protocols
?
 Sebagian besar kekuatan/keutamaan keamanan
informasi di implementasikan di dalam software
 Apabila software anda telah menjadi subjek
sasaran attack, maka keamanannya bisa jebol
o Bergantung pada kekuatan dari crypto, access
control, or protocols
 Software adalah foundation yg jelek untuk
keamanan
Part 4  Software 2
Chapter 11:
Software Flaws and Malware
If automobiles had followed the same development cycle as the computer,
a Rolls-Royce would today cost $100, get a million miles per gallon,
and explode once a year, killing everyone inside.
 Robert X. Cringely

My software never has bugs. It just develops random features.


 Anonymous

Part 4  Software 3
Bad Software adalah sangat
umum contoh :
 NASA Mars Lander (cost $165 million)
o Crashed into Mars due to…
o …error in converting English and metric units of measure
o Believe it or not
 Denver airport
o Baggage handling system  very buggy software
o Delayed airport opening by 11 months
o Cost of delay exceeded $1 million/day
o What happened to person responsible for this fiasco?
 MV-22 Osprey
o Advanced military aircraft
o Faulty software can be fatal

Part 4  Software 4
Software Issues
Bagi Alice and Bob Bagi Trudy
 Bugs dan kelemahan  Aktif mencari bugs
ditemukan secara dan kelemahan
tdk sengaja  Senang pd bad
 Benci bad software… software…
 Berusaha toleran  …mencoba
terhadap bug dan menggunakan bug
kelemahan dan kelemahan tsb
 Berupaya membuat  Attacks systems via
bad software work bad software
Part 4  Software 5
Complexity
 “Komplexitas adalah musuh dari security”, Paul
Kocher, Cryptography Research, Inc.

System Lines of Code (LOC)


Netscape 17 million
Space Shuttle 10 million
Linux kernel 2.6.0 5 million
Windows XP 40 million
Mac OS X 10.4 86 million
Boeing 777 7 million
 Software mobil LOC yg baru lebih komplek dari
software untuk pendaratan astronot apollo di bulan
Part 4  Software 6
Lines of Code and Bugs
 Conservative estimate: 5 bugs/10,000 LOC
 Do the math
o Typical computer: 3k exe’s of 100k LOC each
o Conservative estimate: 50 bugs/exe
o Implies about 150k bugs per computer
o So, 30,000-node network has 4.5 billion bugs
o Maybe only 10% of bugs security-critical and
only 10% of those remotely exploitable
o Then “only” 45 million critical security flaws!

Part 4  Software 7
Software Security Topics
 Program flaws (tdk disengaja)
o Buffer overflow
o Incomplete mediation
o Race conditions
 Malicious software (sengaja)
o Viruses
o Worms
o Other breeds of malware

Part 4  Software 8
Program Flaws
(Kelemahan/Kebocoran)
 An error is a programming mistake (kesalahan)
o To err is human
 An error may lead to incorrect state: fault
o A fault is internal to the program
 A fault may lead to a failure, where a system
departs from its expected behavior
o A failure is externally observable

error fault failure

Part 4  Software 9
Example
char array[10];
for(i = 0; i < 10; ++i) Nyasar  crash
array[i] = `A`;
array[10] = `B`;
 program ini mempunyai error
 error tsb dpt mengakibatkan fault
o Incorrect internal state
 Bila fault terjadi, maka bisa mengakibatkan
soffware failure
o Program behaves incorrectly (external)
 Kita menggunakan istilah flaw untuk hal2 di atas
Part 4  Software 10
Secure Software
 Dlm software engineering, “mengupayakan”
software mengerjakan sesuai apa yg
direncanakan
 Sedangkan Secure software engineering
“membutuhkan” software mengerjakan sesuai
apa yg direncanakan
 …and nothing more
 Absolutely secure software? Hanya mimpi…
bisa gak jadi2..
o Absolute security anywhere is impossible
 Yg bisa dicapai adalah “How can we manage
software risks”
Part 4  Software 11
Program Flaws (Kelemahan)
 Program flaws are unintentional (tak
sengaja)
o But can still create security risks
 We’ll consider 3 types of flaws
o Buffer overflow (smashing the stack)
o Incomplete mediation
o Race conditions
 These are the most common flaws

Part 4  Software 12
Buffer Overflow

Part 4  Software 13
Attack Scenario
 User memasukin data ke halaman Web
 Halaman Web dikirim ke server
 Server menulis data ke array disebut buffer,
tanpa mencek panjang input data
 Data “overflows” buffer
o Beberapa kemungkinan overflow bisa terjadi
o Dengan demikian attack bisa dilakukan oleh siapapun
menggunakan akses Internet

Part 4  Software 14
Buffer Overflow
int main()
{
int buffer[10];
buffer[20] = 37;
}

 Q: Apa yg terjadi bila code ini di eksekusi ?


 A: Tergantung apa yg akan disimpan pd
memory di locasi “buffer[20]”
o Mungkin akan menimpa user data atau code
o Mungkin akan menimpa system data atau code
o atau program akan tetap berjalan

Part 4  Software 15
Simple Buffer Overflow
 Anggaplah boolean flag untuk otentikasi
 Buffer overflow mungkin akan menimpa flag
sehingga seseorang terotentikasi oke..
Boolean flag
buffer
F OU R S C … T
F

 Pada beberapa kasus, Trudy tdk


seberuntung seperti kasus ini
Part 4  Software 16
Memory Organization
¬ low
 Text  code text address
 Data  static variables data
 Heap  dynamic data
heap
 Stack  “scratch paper” 
¬ stack
o Dynamic local variables pointer (SP)
o Parameters to functions 
stack ¬ high
o Return address
address

Part 4  Software 17
Simplified Stack Example
low 

void func(int a, int b){ :


char buffer[10]; :
}
void main(){
func(1,2); ¬ SP
buffer
}
ret ¬ address
¬ return
SP

a ¬ SP

high  b ¬ SP

Part 4  Software 18
Smashing the Stack
low 

 What happens if :
??? :
buffer overflows?
 Program“returns” ¬ SP
to wrong location buffer
overflow
ret ¬ ret…
SP
A crash is likely
overflow
a ¬ SP NOT!

high  b ¬ SP

Part 4  Software 19
Smashing the Stack
low 
 Trudy has a
:
better idea… :
 Code injection
 Trudy can run ¬ SP
code of her evil code

choosing… ret ret ¬ SP


a ¬ SP
o …on your machine
high  b ¬ SP

Part 4  Software 20
Smashing the Stack
:
:
 Trudy may not know…
NOP
1) Address of evil code :
2) Location of ret on stack NOP

 Solutions evil code

1) Precede evil code with ret


¬ ret
NOP “landing pad” ret
:
2) Insert ret many times
ret
:
Part 4  Software : 21
Stack Smashing Summary
 Buffer overflow selalu bisa terjadi pd suatu code
 Tapi buffer overflows tdk selalu bisa di eksplotasi
o Harus ada kesesuaian
 Bila bisa di ekplotasi, attacker dpt meng- inject code
 Trial & error perlu dilakukan
o Fear not, lots of help is available online
o Smashing the Stack for Fun and Profit, Aleph One
 Stack smashing adalah “attack of the decade”…
o …for many recent decades
o Also heap & integer overflows, format strings, etc.

Part 4  Software 22
Stack Smashing Example
 Misalkan program minta masukan serial
number dimanaTrudy tdk tahu
 Juga, Trudy tdk mempunyai source code
 Trudy hanya punya executable (exe)

 Program akan keluar bila serial number yg


dimasukan salah
Part 4  Software 23
Buffer Overflow Present?
 Dgn coba2 (trial and error), Trudy
menemukan buffer overflow utk suatu input

 Note  0x41 adalah ASCII untuk “A”


 Sepertinya ret overwritten dengan 2 bytes!
Part 4  Software 24
Disassemble Code
 Selanjutnya, disassemble bo.exe cek..

 Tujuannya adalah buat buffer overflow


utk lompat ke address 0x401034
Part 4  Software 25
Buffer Overflow Attack
 Addres 0x401034 dlm ASCII adalah “@^P4”

Masih error

 Mungkin urutan byte terbalik ? Sebab…


 X86 processors are “little-endian”
Part 4  Software 26
Overflow Attack, Take 2
 Balik urutan byte-nya “4^P@” dan…

 Success! Kita berhasil mem-bypass cek serial


number dgn exploitasi buffer overflow
 Apa yg barusan terjadi.?
o Overwrote (tulis/input berlebihan), return
(memberikan/mengembalikan) address dari stack

Part 4  Software 27
Buffer Overflow
 Trudy tdk perlu akses ke source code
 Hanya perlu tools utk meng-disassembler
code utk mengetahui address “to jump to”
 Cari address dgn coba2 (trial dan error) ?
o Diperlukan bila kita tdk mempunyai exe
o Misal pada kasus remote attack

Part 4  Software 28
Source Code di atas tadi..
 Source code for buffer overflow example
 Flaw easily
exploited by
attacker…
 …without
access to
source code!

Part 4  Software 29
Menghindari
Stack Smashing (Defenses)
 Terapkan non-executable stack
o “No execute” NX bit (apabila ada)
o Seems like the logical thing to do, but some real
code executes on the stack (Java, for example)
 Gunakan :
 canary
 Address space layout randomization (ASLR)
 safe languages (Java, C#)
 safer C functions
o Utk unsafe functions, safer versions exist
o Misal strncpy pengganti strcpy
Part 4  Software 30
Stack Smashing Defenses
low 
:
 Canary :
o Run-time stack check
o Push canary onto stack
o Canary value: buffer
 Constant 0x000aff0d overflow
canary ¬
 Or, may depends on ret overflow
ret
a
high  b
Part 4  Software 31
Microsoft’s Canary
 Microsoft added buffer security check
feature to C++ with /GS compiler flag
o Based on canary (or “security cookie”)
Q: What to do when canary dies?
A: Check for user-supplied “handler”
 Handler shown to be subject to attack
o Claimed that attacker can specify handler code
o If so, formerly “safe” buffer overflows become
exploitable when /GS is used!

Part 4  Software 32
ASLR
 Address Space Layout Randomization
o Randomize place where code loaded in memory
 Makes most buffer overflow attacks
probabilistic
 Windows Vista uses 256 random layouts
o So about 1/256 chance buffer overflow works
 Similar thing in Mac OS X and other OSs
 Attacks against Microsoft’s ASLR do exist
o Possible to “de-randomize”

Part 4  Software 33
Input Validation
 Consider: strcpy(buffer, argv[1])
 A buffer overflow occurs if
len(buffer) < len(argv[1])
 Software must validate the input by
checking the length of argv[1]
 Failure to do so is an example of a more
general problem: incomplete mediation

Part 4  Software 34
Input Validation
 Consider web form data
 Suppose input is validated on client
 For example, the following is valid
http://www.things.com/orders/final&custID=112&num=55A&qty=2
0&price=10&shipping=5&total=205
 Suppose input is not checked on server
o Why bother since input checked on client?
o Then attacker could send http message
http://www.things.com/orders/final&custID=112&num=55A&qty=2
0&price=10&shipping=5&total=25

Part 4  Software 35
Buffer Overflow
 A major security threat yesterday, today,
and tomorrow
 The good news?
o It is possible to reduce overflow attacks (safe
languages, NX bit, ASLR, education, etc.)
 The bad news?
o Buffer overflows will exist for a long time
o Why? Legacy code, bad development practices,
clever attacks, etc.

Part 4  Software 36

You might also like