Repetition / continue from last lecture

Links

A soft link is a file with a string reference to a relative or absolute path of another file on the file system. They persist even if the pointed to file is deleted, renamed or moved. They can link to files on other file systems.

A hard link is a pointer directly to data on the file system. Every file is a hard link and usually there is only this one to a specific data area in the file system. On Linux a link counter is incremented for every hard link created, and decremented on unlinking (deletion). When the counter reaches 0 data are marked unallocated. If the file is being used by a process, it would be bad to "pull it under it's feet", so the file entry it's kept until no one else is using it. One way to exploit this (used back in the Morris worm) is for an executable to load itself into memory and then delete (all) hard-links to itself. The file would not be visible, but could still be used (and possible be added back to disk then computer shuts down).

The main reason for having hardlinks on Linux was because there are so many flavors of Linux, each placing configuration files in different areas. With hardlinks an administrator could rearrange entry points to files without altering the system itself. Usage of links can also be used to trick another user to run something they believe is benign. Restrictions on link creation in shared folders is often a counter measure.

Client side code injection
Java code, media codecs (like jpeg, png, gif, avi, mpeg..), adobe flash. Latest HTML 5 comes with media codecs bundled. Inter tab separation in browsers. When a shared library outside of the browser is used, even sandbox in the browser won't protect you.

Race conditions
Simultaneous resource access leads to undeterministic execution because the operations are not atomic. Addressed by mutex, semaphores and locks: ToCToU is closely related.

Root kits
Binary / user-land root kits replace binary's, avoid inconsistencies. Methods might be code injection in DLL's and path substitution.
Kernel root kits modify kernel components. Direct Kernel Object Manipulation (DKOM). In order to be persistent, root kits can use registry keys (database), startup files, addons to commonly used programs, boot loader and even rewriting of firmware.

How to develop safer
Testing:

• Paranoid input validation
  
• Test for edge cases "off by one"
  
• Formally specify input and output that are tested
  
• Fuzzing (gray or black box)
  
• Automated tools: FlawFinder, RATS, ITS4, PreFix, Splint, SPARK
  

Detection:

• Explicit model checking: Finite state machine, reachability, behavoir and relational (??)
  
• Anomaly for control flows and data flows
  

Full disclosure
Legislations like DMCA and EU Copyright Directive (initiated by WIPO) tries to make it illegal to possess exploits. Even proof-of-concept code. Important to be careful when traveling (air port checks), avoid doing testing against anything not self owned and not try to "help" other organizations to find vulnerabilities.

Malware

• Malware "Malicious software" doing unwanted changes to a computer system
  
• Virus is self reproducible code performing malicious functions. Traditionally they were spread by floppy disks. Macro-viruses are a special case when the virus is hidden inside typical document files containing some scripting functionality.
  
• Worm is a "virus" that can spread automatically (typically via a network)
  
• Trojan horse is a cover to hide a "virus". The cover might be a program that serves a purpose for the user.
  
• Trap door (back door) is a hidden pathway to get access to a system. Placed by developer (like debug mode) or other malware.
  
• Logic bomb is also triggered, but often by a timer or an external event in order to break something, being used in ransomware and for "job security"
  

When malware is run by the (fooled) user it will be run with the users privileges. Mandatory access control can help limit the damage compared with discretionary, unless a privilege escalation is performed. A worm by definition does not require any user action. The definition of worm and virus are a little diffuse and the other mentioned are more or less special cases.

A walkthrough of the Morris worm...

Some comments on using different (3) exploits (fingerd, sendmail..), hiding techniques, being discovered since the author (PhD student at Cornell) was sloppy and did not terminate the old copy then forking to avoid resource usage detection, 10% of machines were infected, no maliciousness in code, but usage of resources. Smart searching for new hosts to attack. Some comments on needle in a haystack when we go for IPv6.

Continued on a discussion on antivirus solutions, "sliding window" of checks since there are so many different viruses. String search vs behavior antivirus. Definition of a "dropper" code that "smuggle" inn malware.

"Droppers are used by malware creators to disguise their malware. They create confusion amongst users by making them look like legitimate applications or well known and trusted files." Symantec

A walkthrough of stuxnet...

A multi stage worm created by the US and two other countries, targeting Iran's uranium enrichment infrastructure. Several zero day exploits were used and it targeted (after some intermediate steps) Siemens simatic programmable logic controllers making the centrifuges run to fast, stop and start again and again and at the same time telling the controllers "everything is fine" (man in the middle attack). By this ruining the time consuming task of separating the isotopes.

Lecture for day 3

Database security
The most difficult aspect according to teacher is the integrity aspect. Databases allow for greater granularity of access. The focus is on relational databases.
Important principles: views, constraints and triggers. A view is a predefined query presented to the database user as a table with the purpose of hiding parts of the data. Can restrict both columns and rows (tuples). A constraint is a rule that forces entered data to follow certain rules. Like "not bigger than 50" or "product of item 1 and item 2 must match with item 3". Triggers are rules that automatically apply when a field is changes. Like for updating other fields in other tables.

Permissions are given on users for update, select, insert, etc for tables or views. One issue is that most web applications run all SQL from a single high privileged user. In the following security models this is neglected. Another issue is "blind writes" where a user might only see a part of the table (a view) and wants to insert a new entry without being able to see all the data being inserted.

Role based access control framework:
primary keys, unique fields, minimality on primary key (when spanned over many fields). No foreign keys allowed if primary key does not exist.

Multilevel security:
"No write down" ("controlled write down")
Extra labels are added to every field, plus and additional for the tuple.

Statistical attacks
How to protect aggregated data from user specified queries from being formed in a way that individual (or a small group) can be identified. Use of trackers can work in the short term:

...but it gets complicated unless all search history is kept. Better to anonymize the data before making it available.

SQL injections
Escape the string and use comments "--" to alter the structure.

"SELECT email FROM members WHERE email = ’$EMAIL’";
$EMAIL = x’; DROP TABLE foo; --
"SELECT email FROM members WHERE email = ’x’; DROP TABLE foo; --’";

Malware (part II)
Not examinable, but hopefully we will have time to go through some of it tomorrow (Friday)

Development assurance
The same goes for this one...