Insights on Software Security and Flaws in WinVote System
Explore the importance of software security, common flaws caused by developers, and vulnerabilities in the WinVote system. Learn how lack of awareness, knowledge, and professionalism contribute to security risks, with real-life examples illustrating the consequences of these issues.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Software Security Dror Feitelson Hebrew University
Security and YOU Security flaws are bugs They are caused by developers who Make mistakes Are careless Work too quickly Lack awareness Lack knowledge Behave unprofessionally
Under the Hood <form method="post" action="http://www.pikiwiki.org.il/login/do-login" class="login"> <input type="text" name="email" class="form-control email" placeholder="email"/> <input type="password" name="password" class="form-control" placeholder= password /> <button type="submit" class="btn btn- info">Enter</button> </form> [Fixed within a few days after being notified in October 2017]
WinVote Security One of several systems built in response to Help America Vote Act of 2002 Used in real elections for over 10 years Based on Windows XP Uses Wi-Fi to program election details and download results In 2014 reports of crashing when a poll worker downloaded music on his iPhone Led to new assessment of the system
WinVote Security Results XP embedded not patched since 2004 Uses WEP, considered obsolete already in 2004 due to security flaws WEP key hardwired to abcde Disabling Wi-Fi disabled the WinVote app, left XP exposed Windows administrator password set to admin with no interface to change it No logs or checksums to detect tampering with system s database If system was not hacked it was only because nobody tried
Excuses It s the clients fault They didn t specify security requirements They bought the system No it isn t Clients don t know about all the details They may assume developer is competent They may assume system is state of the art Not being state of the art is technical malpractice
Security and the Industry For many years most of the industry considered security a tiresome nuisance Microsoft only made security a top priority in 2002 After IIS web servers were hit by CodeRed and Nimda worms Other parts of the industry sold security solutions This is a market failure that casts a shadow on the future of the industry
C. A. R. Hoare, The emperors old clothes. Comm. ACM 24(2), pp. 75-83, February 1981. (Turing Award acceptance speech) Inventor of Quicksort (at age 26) Inventor of switch/case construct Took responsibility for null references Inventor of Hoare Logic Inventor of formalisms like CSP Recipient of 1980 Turing Award (and many other awards)
On Algol 60 Subset Implementation Every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
Nearly 40 Years Later: Source: NIST National Vulnerability Database
Making of an Apocalypse Software is ever more prevalent How many computerized systems have you used today so far? Software is ever more crucial All the infrastructure around you All the dynamics of a living modern society Software production is not improving enough Incentives favor time to market over quality Only a major catastrophe will change this
1987: Jerusalem Virus One of the first computer viruses Infected DOS systems (IBM PC) Upon execution: Becomes memory resident Infects any program that is run Deletes files if date is Friday the 13th of the month Omri Mann and Yuval Racavy (at HU) write one of the first anti-virus programs Then founded BRM with Barkat brothers Made Nir Barkat very rich
2007: Estonia DDoS Attacks Massive DDoS attacks on organizations and infrastructure Government offices Banks News media outlets First demonstration of country-wide disruptions Attributed to Russia (cyber warfare?)
2010: Stuxnet Cyber Weapon Cyber weapon used to disable centrifuges in Iran s nuclear program Computer worm propagating across the Internet targeting a specific configuration of Siemens software and controllers Attacks SCADA controllers controlling physical systems, e.g. factory assembly lines Alarming demonstration of potential to attack physical infrastructure remotely
2013: Yahoo! Hacked Data about all 3 billion user accounts stolen Names Email addresses Phone numbers Dates of birth Security questions Hashed passwords Biggest data breach of its kind Many many other such data breaches across the world
2016: US Elections Hackers break into DNC computers Steal and distribute confidential emails and documents Embarrass Democratic Party, possibly contribute to election of Donald Trump Demonstrates that hacking can have strategic impact
2016: IoT DDoS Attacks Attack executed using a botnet of 1.5 million Internet-connected devices Ironically mostly security cameras Targetted DNS provider Dyn Causing wide-spread disruptions to Internet access throughout the US Possibly by small-scale unsophisticated attackers Demonstrates vulnerability of Internet infrastructure
2017: WannaCry Ransomeware Infected more than 200,000 computers in 150 countries Encrypt files on Windows systems and demand a $300 ransom in Bitcoin for the key Caused major disruptions E.g. closing down of 16 hospitals in UK Put lives at risk Demonstrated global scale cyber crime Attributed to North Korea
Hacking There are many different ways to cause damage Denial of service prevent legitimate clients from receiving service by flooding it Execute unauthorized code Guess passwords using brute force Social engineering cause people to act irresponsibly, e.g. install malware Exploit system weaknesses and bugs buffer overflow / stack smashing Undermine system programming/execution model
The Devil is in the Details Hackers know low-level system details You don t They win Two detailed examples: Sending a fake email Stack smashing
Denial of Service (DoS) Flood a target with bogus requests Legitimate requests can t get through A networking issue more than a system/software issue DDoS(= distributed DoS): send requests from multiple sources to avoid identification Use botnets (which ARE a system/software issue)
Guess Passwords People choose common passwords 123456, 123456789, qwerty, password, 1111111, abc123 Dictionary words or names By trying them automatically a hacker can gain access Bad solution: require users to change passwords every month Bad solution: require passwords with at least 8 characters including upper/lower case, punctuation, and numbers Better: require humanly-memorable hard to guess passwords (e.g. multi-word) Better: don t allow multiple repeated requests
Social Engineering Send fake email to victim Opening an attachment implies a user action So the system does what the user asked Including to install malware Or to collect data and send it somewhere Need to alert user to the danger Problem: alerts are usually ignored automatically
Spoofed Email Attacks If you get an email from an unknown source in Russia suggesting you click on a link you might be suspicious But if it comes from a friend, you may click The danger: clicking the link can download malware etc. If it s from a company you do business with, you might divulge information This can be easily created even without breaking into the friend s/company s email
Email Stack Email client Email client SMTP SMTP (email handling) (email handling) TCP/IP Networking TCP/IP Networking Sender Recipient SMTP = Simple Mail Transfer Protocol
Email Stack Email client telnet SMTP (emulate email) (email handling) TCP/IP Networking TCP/IP Networking Attacker Recipient
SMTP Session open <mail server> 25 220 <mail server> welcomes you to the wonderful world of ESMTP MAIL FROM: <faked sender> 250 OK RCPT TO: <intended recipient> 250 Accepted DATA 354 Enter message, ending with "." on a line by itself From: <faked sender> To: <intended recipient> Subject: A really good one MIME-Version: 1.0 Content-Type: text/html Actual email Try this :-) LOL <a href= <target link> >Best cat video ever!!</a> . 250 OK id=<message ID> QUIT
Spoofed Emails By default, nothing is checked There is no authentication But servers can be configured to Not accept anonymous messages Not relay messages to other mail servers
Buffer Overflow Blindly copying data into a buffer may overflow onto adjacent memory locations Modify their values: a bug Can be engineered to run arbitrary code: a security threat Modern languages check at runtime C/C++ don t check Always check bounds when copying (use compiler option that does this) Never use unsafe functions (strcpy etc.)
Stack Smashing A process runs with user s privileges (possibly super user) Accepts external input Copies input to a local buffer Buffer is allocated on the stack Overruns the buffer and changes stack Including return address from the function Engineered to return to part of the input Thereby executing whatever code is there
Process Memory Layout Text and data are fixed at compile time Heap and stack may grow at runtime Can t know which needs more space Make them grow towards each other Stack Heap Program data Program text
Function Call Each function call creates a stack frame Parameters Return address (points to command after this function call) Local variables Previous frame Stack growth Parameter 1 Parameter 2 Return address Local 1 Local 2
Function Call Assume a local variable is a buffer Previous frame Stack growth Return address buffer
Function Call And the function copies input into this buffer Previous frame Stack growth Return address Address growth \0 R L D ! O W O H E L L
Function Call If it uses strcpy, it can easily overrun the buffer N G \0 Stack growth S T R I Address growth O N G R Y L And overwrite the return address! When the function returns we ll probably get an exception A V E I S T H I S
Function Call But if we re really smart, we can engineer the input to overwrite the return address with whatever we choose Stack growth ? ? ? ? Address growth
Function Call And in particular we can point back into the buffer Stack growth Point back Address growth WHERE WE PUT SOME REALLY BAD CODE! (example: activate the shell to execute any command we send it) BAD CODE
Function Call Of course it isn t easy to get the details right Stack growth Point back But with some experimentation it s possible Address growth BAD CODE And we can improve our chances
Function Call We can improve our chances: 1. Put multiple back pointers Hopefully one of them will be in the right place 2. Use a NOP slide before the bad code Wherever we land, we slide into the bad code Point back Stack growth Point back Point back Address growth BAD CODE NOP NOP
Stack Smashing A type of buffer overflow Allows attacker to run his code under your credentials Depends on legitimate programs that don t check array bounds Mitigated by making stack non-executable But there are other similar attacks
Unvalidated User Input Malicious input can be used to compromise the system Induce stack overflow and execute arbitrary code Escape designated area in file system and access unauthorized files (path with ..) Inject SQL commands to access database User input must always be validated before being accepted Check for meta-characters Check for code
Conflicting Goals Security Keep things safe Reduce attack surface Defensive programming, no trust Detailed error messages may disclose information Imperfect user input could be an attack Software Engineering Be user friendly Provide service Use trust to be efficient Provide detailed error messages Try to cope with imperfect user input
Error Messages Enter user name: Enter password: Let me in Possible error messages: Unknown user Wrong password Invalid credentials
Security is a Separate Expertise There are lots of things that can be made to go wrong There are very few generally applicable solutions Need to know and avoid many individual vulnerabilities New ones are constantly being found Get help from an expert on security
Guidelines and Regulation Known coding practices can reduce risk Example: the Motor Industry Software Reliability Association (MISRA) coding standards for C and C++ 143 rules and 16 directives, including things like: Don t use strcpy Put { } around single-statement if blocks Does your company have secure coding guidelines?