Off topic: Ruby

I have been working with Ruby on Rails (RoR), for a bit now, so I decided to extend my Ruby knowledge a bit and learn design patterns.

I read the original GoF design patterns book, but "Design Patterns in Ruby", by Russ Olsen, is much cleaner.

The Ruby code is easy to read in DPiR, but the book also has demonstrated the real power of Ruby.

Two things I have seen in the template, strategy and observer patterns that make Ruby so powerful are the following:
1) The ability to pass blocks of code to the strategy methods, so that the strategy and the implementation are loosely coupled.
2) Pervasive objects and "duck typing" make it easy to make more generic classes or modules that can handle more types of objects. Therefore, not only is the implementation independent of specific methods, but even the input classes can vary wildly.

I recommend DPiR as the second Ruby book to be read after O'Reilly's "Learning Ruby". Of course, DPiR does have a small Ruby tutorial, so one could just read it with the The Pickaxe Book as a reference.

Depressing CPE's

I have been doing some online seminars for my CISSP CPE credits, and I recently viewed one on the state of malware.

It was a bit depressing.

Botnets and polymorphic threats abound, as well as the "professional" level of the malware creators.

Additionally, traditional methods of protecting the desktop are not adequate.

Anti-virus, anti-spyware and desktop firewalls are inadequate, especially with hardware and kernel level rootkits.

Reliable detection is available when one uses a networks intrustion detection system (IDS), but the most effective strategy is keeping up-to-date with patches.

Of course, any and all applications and OS programs can be a vector, so the patching has to be comprehensive.

It seems that current OS architectures are inadequate since this new environment requires a high level of mediation.

Naturally, looking for the "bad" in this day is ineffective and the assertion of the "good" is the strategy with the best payoff.

Persystent Enterprise and Triumfant look like the best bets in this space.

New Squidoo Lens

I created a Squidoo Lens to cover some of the same material as this blog.

However, I did put some useful links to risk assessment methodologies and guides.

Don't Do Db Security By Yourself

Code reviews and static analysis of code, plus scanning tools, will only get you so far when securing your database-driven web application.

The best solutions of securing web applications are outside the scope of the programmer's control.

The best approaches include:

• Code randomization (or embedded host languages)
• Framework modification
• finite state machine/dynamic candidate evaluations/parse tree analysis (dynamic analysis)

The first method, code randomization creates "an executionenvironment that is unique to the running process, so that the attacker does not know the “language” used and hence cannot “speak” to the machine."(Keromytis et al, p. 272, 2003). Code injections made to a system using code randomization will appear to be gibberish to the machine executing the language. Such randomization requires modification to the execution environment (or compiler), as well as the code execution loading routines (to unpack the unique language).

Embedded host languages do not obscure the code, as in code randomization, but provide a translation layer that mediates access to the underlying (i.e. SQL) code, translating embedded commands into only well-known structured commands (Bravenboer 2007).

In any case, I grouped these two together because they have the pattern 'tainted code'->'magic transformation'->'good code'. These techniques obscure the language used, so that an attacker will know the language in code injection (and SQL injection), as well as cross-site scripting (XSS).

The next method, framework modification, is good only for XSS. An example of framework modification is checking the triple (host, protocol, port) for each object in a documents DOM for the same origin (Livshits et al, 2007). Many browsers already support this at a higher level, but this method means that every widget will get checked before each run (Livshits). Thus the XSS code is mediated and rejected if its triple is not shared with other widgets in the DOM.

The final methods are all types of dynamic analysis, where a model is created of SQL calls and calls that do not match the model are not allowed to execute.

What I call the 'finite state machine' method really is a result of a combination of static and dynamic analysis, where hotspots (i.e. code that calls SQL statements) are profiled and state machines are built for each call, showing all the allowed edge/vertices transformations (Halfond, 2005). This method enumerates all the allowed words that the application might employ (Halfond).

While finite state machines provide one type of graph-oriented analysis, dynamic candidate evaluations and parse tree analysis provide another. These methods take the SQL statements and tokenize them and their parameters, and create a tree to compare against a current invocation of the runtime SQL statements. Again, anomalous patterns are not allowed to pass.

The parse tree method works "by simply juxtaposing the intended query structure with the instantiated query" (Buehrer et al.,p. 112, 2005).

A similar approach works with a "SQL grammar and a policy stating the valid syntactic forms" (Su et al., p. 376, 2006).

I am sure I have oversimplified aspects of these techniques, but my goal in writing this is to argue that handling all of the potential XSS and code injection attacks in web applications is a complex endeavor . Shooting from the hip is not going to work.

It is worth noting that a company called Imperva has a product called SecureSphere that seems to work using one or more types of dynamic analysis.

One thing I did not discuss is detecting XSS and code injection; rather, I focused on preventative measures.

I don't want to let the cow out of the barn, then scramble to recover.



References:
Bravenboer, M., Dolstra, E., and Visser, E. 2007. Preventing injection attacks with syntax embeddings. In Proceedings of the 6th international Conference on Generative Programming and Component Engineering (Salzburg, Austria, October 01 - 03, 2007). GPCE '07. ACM, New York, NY, 3-12. DOI= http://doi.acm.org/10.1145/1289971.1289975

Buehrer, G., Weide, B. W., and Sivilotti, P. A. 2005. Using parse tree validation to prevent SQL injection attacks. In Proceedings of the 5th international Workshop on Software Engineering and Middleware (Lisbon, Portugal, September 05 - 06, 2005). SEM '05. ACM, New York, NY, 106-113. DOI= http://doi.acm.org/10.1145/1108473.1108496

Kc, G. S., Keromytis, A. D., and Prevelakis, V. 2003. Countering code-injection attacks with instruction-set randomization. In Proceedings of the 10th ACM Conference on Computer and Communications Security (Washington D.C., USA, October 27 - 30, 2003). CCS '03. ACM, New York, NY, 272-280. DOI= http://doi.acm.org/10.1145/948109.948146

Halfond, W. G. and Orso, A. 2005. Combining static analysis and runtime monitoring to counter SQL-injection attacks. In Proceedings of the Third international Workshop on Dynamic Analysis (St. Louis, Missouri, May 17 - 17, 2005). WODA '05. ACM, New York, NY, 1-7. DOI= http://doi.acm.org/10.1145/1083246.1083250

Livshits, B. and Erlingsson, Ú. 2007. Using web application construction frameworks to protect against code injection attacks. In Proceedings of the 2007 Workshop on Programming Languages and Analysis For Security (San Diego, California, USA, June 14 - 14, 2007). PLAS '07. ACM, New York, NY, 95-104. DOI= http://doi.acm.org/10.1145/1255329.1255346

Su, Z. and Wassermann, G. 2006. The essence of command injection attacks in web applications. In Conference Record of the 33rd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Charleston, South Carolina, USA, January 11 - 13, 2006). POPL '06. ACM, New York, NY, 372-382. DOI= http://doi.acm.org/10.1145/1111037.1111070

Database Security Secrets of the Ancients Revealed

A terrible aspect of information security is the propagation of trendy buzzwords and their use as
social signifiers in the community.

One could be completely competent with fundamental aspects of computer security, but be missing out on the trend-spinning.

For example, as network defenses and countermeasures have become more effective, attackers have had to rely on the only generally open TCP/IP port 80 (the World Wide Web service) to have an exploitable channel for attack.

This is a simple tautology; an attack can only be opened if there is a channel.

However, this basic fact has been obscured by the terms "cross site scripting" and "SQL injection attacks".

The flavor of the week in hip consultancy is to protect the "good" people from the "bad" people launching these attacks.

However, no matter what variety of forms these attack techniques come in, they really come down to simple and well-known computer principles.

Cross-site scripting is the failure to provide complete mediation for access to an object on every
access attempt. The net effect of this unmediated access is that during a step in the access sequence a substitution of identity or a substitution of code can occur. Such complete mediation was discussed in 1974-75 by Saltzer and Schroeder (Saltzer 1975).

While the Saltzer et al. paper was referring to operating systems, the application to all automata
should be obvious (in my opinion).

Cross-site scripting also has a strong correspondence to time-of-check to time-of-use (TOCTTOU) programming flaws where a "mediation is performed with a "bait and switch" in the middle" (Pfleeger 2007 p.110).

SQL injection is even easier to explain; unchecked input can do unexpected (and exploitable things).

SQL injection can occur, for example, when the contents of a search box are appended to a SQL statement that is then passed on directly to the database.

The Ruby on Rails(RoR) security forum has an excellent post on using bindings to prevent extra SQL commands from being concatenated to a command and sent to the database server.
http://www.rorsecurity.info/2007/05/19/sql-injection/

The provided examples show that this a classic validation error as discussed in Landwehr, et al's "A taxonomy of computer program security flaws", circa 1994.

So, how can the ephemeral buzzwords be controlled.

Taxonomies, like Landwehr's et al.

If taxonomies are de facto standardized, then new attacks can be classified and information security professionals and decision makers can gauge their response.

The alternative is confusion, marketing poser consultants and the historically ineffective scramble.

A well motivated attacker could learn a lot by reading old papers, because the lessons are repeatedly forgotten.

It just isn't cool to know the basics.


References:
Landwehr, C. E., Bull, A. R., McDermott, J. P., and Choi, W. S. 1994. A taxonomy of computer program security flaws. ACM Comput. Surv. 26, 3 (Sep. 1994), 211-254.

Pfleeger, C.P., Pfleeger, S.L., (2007) Security in Computer, Fourth Edition. Prentice Hall: Upper
Saddle River, New Jersey.

Saltzer, J. H. and Schroeder, M. D., "The Protection of Information in Computer Systems," Proc. IEEE Vol. 63(9) pp. 1278--1308 (Sept. 1975).

The Personal Firewall

At one place where I had the opportunity to work, the external connections to the web and external partners were all protected by firewalls.

Depending on the requirements of the customers, the firewalls could be implemented on Linux, or be a name-brand system such as Cisco's PIX or Checkpoint's Firewall1.

This is all well-and-good, but the essential doctrine of defense in depth was ignored.

The state of the internal Window Firewall on everyone's office system was not know, and I question its protection value anyway.

You see, someone had got a Trojan through a website or off of some external media.

The graphics arts department was notorious for being ground-zero for Trojans...

In any case, even with a famous name brand virus scanner and the Windows Firewall, the Trojan still spread.

I was able to isolate the general type of Trojan using Ethereal, RegMon and FileMon, but the virus company took about 10 hours to generate an emergency signal.

My feeling is that a better and verifiable installation of Personal Firewalls would have stopped the spread of the Trojan on the internal network, although it would not have stopped the initial infection.

In any case, the event cost was way more than the cost of having Personal Firewalls on each workstation.

Furthermore, some strategic deployments of Snort probably would have helped us isolate the origin of the event.

Thank goodness one of the other IT staffers went and disconnected the internal networks from the customer resources.

For the most part, a severe event was avoided, but the event was still disruptive.

Stovepiping Madness

"We use professional judgement, a pinch from COBIT, a jot from FISCAM, two tablespoons of NIST baked in with meat from the Institute of Internal Auditors."

This was the answer [paraphrased for dramatic effect] I got from the senior auditor for a major governmental entity (MGE) when I asked what standards agencies under the audit scope of the MGE could use to improve their security.

This MGE has more than half-a-million people in its retirement program.

So, basically, agencies that have little money for non-mission related functions have to scour dozens of standards in preparation for the bi-annual audit.

What I was hoping to hear was that the MGE had developed a set of written guidelines for agencies in its scope.

Unfortunately, this was not the case.

Furthermore, where state, local and federal laws and regulations were referenced, the most guidance that one could get was the law itself (despite some of the laws having been on the books since the mid 1970's).

It eludes me how this system actually improves the security and operational credibility of any of its organizations.

While I understand the need for adversarial audits on audit day, I do not understand the unwillingness to put up a standard and judge by the standard.

Instead, no guidance comes, and the smaller organizations give up with half-hearted risk mitigation strategies; why bother to attempt a comprehensive program when you are going to get reamed during the audit any way?

Well, I promised myself I would not just bring up problems here.

I want to propose solutions.

I want the smaller organizations to put together their own team of adversaries and create their own standards.

I can only dream.