SQL injection

The structured query language (SQL) is an ANSI standard language for accessing data from a relational database. SQL is commonly used to process user-supplied data from web pages and applications on the server side. SQL injection is a technique for inserting SQL commands as user input. If these are not properly filtered for escape character and commands, as attacker can potentially append data and commands to an SQL query, which many force the server to send back sensitive information, overwrite other user’s data on the server, or execute server commands.

The problem stems from the fact that SQL commands on a web server are typically constructed based on data received from users. As an example, consider a log-in mechanism in which usernames and passwords are stored in a database and a query is constructed based on authentication information supplied by a user on a web form. An example of such a string constructed on an active server page (ASP) may be

      QueryName = “select username from

authenticationtable where username = ‘ ” &

request.form(“name”) &  “ ’password = ‘ ” &

request.form(“password”) & “ ‘ ”

In the query above, if a valid username / password combination is entered, the name of that authenticated user is stored in the variable queryname. One simple check to see whether the username / password combination is valid is to check to see whether this variable contains any data. If it contains a nonempty string, the user is granted access and that user’s credentials are forwarded on. One easy way to subvert such a mechanism is to change the query to

      Select username from authenticationtbale where true

Which will result in the first username in the table being stored in the variable queryname. This can be accomplished by entering.

     Username           : ‘ or ‘1’ = ‘1

      Password            : ‘ or ‘1’ = ‘1

This will force everything after the where clause to equate to true and return the first name in the table to the variable queryname. 

There are many other tricks you can try with SQL injection. For example, many SQL commands are passed from page to page or the server using get. Get exposes data in the browser’s URL, which is then easily modified by an attacker. If you are testing any web-based applications or an application that send commands to a database, you need to try SQL injection attacks, or hackers will do it for you.

Buffers overflow Vs Escape-Character Attacks

On the surface, this attack seems very similar to the buffer overflow attack discussed earlier; indeed, they both the exploit the same flaw of unconstrained input. The difference is that with buffer overflow attacks, we attempt to send the applications a string that is too long for the memory allocated for it. With some careful appending of low-level commands to the end of this string, the operating system can be deceived into executing these commands rather than, or in addition to, applications instructions. To exploit a buffer overflow for the first time usually requires a fairly savvy attacker, because appended commands must be in machine language. Unfortunately, though attack string sometimes become widely distributed and then the so call “script kiddie” class of attacker can exploit these weakness, too. 

Escape character attacks use special characters embedded in strings of usually normal length to force the application to execute commands. Since many of these escape sequences are standard, a minimally skilled hacker can potentially craft a string which executed authorized commands. This means that the knowledge necessary to exploit an escape character vulnerability for the first time is minimal, which makes these types of bugs as or more dangerous than buffer overflows.

Code Red: an overflow of $2 billion

On July 18, 2002 the code red II worn was unleashed on the internet and analysts estimate that more than 359,000 machines were infected within fourteen hours. The worm continued to spread and caused more than an estimated $2 billion in damage worldwide. The   code red virus wan not written to case major damage to the host; rather, it devoured network bandwidth by searching out other vulnerable hosts on the network to infect. The worm exploits a buffer-overflow vulnerability in Microsoft’s Internet Information Server (IIS), which allows a remote user to execute arbitrary instructions remotely on an unpatched web server.

The dependency attack

1.       List the libraries that your application uses. For each one, try to (a) figure out what service it provides to the application and when the application loads the library for use, and (b) selectively deny the application access to these libraries and watch for failures.

2.       Find out which registry values your application reads and writes. The best way to isolate interesting registry key is to watch the application during installation and start up under Holodeck. After you have identified the keys, look for sensitive information stored in the registry and tamper with keys that may be read at start up to try to get the program to expose data or functionality.

3.       Watch your application run under Holodeck and look at documentation to uncover the files and file types your application reads. Next, start corrupting these files with long strings, escape characters, and commands and observe how the application responds. The potential pay-off is a “safe” file (like a music file) that a user downloads and trust that can exploit a vulnerability in the application to execute commands (through script, buffer overflows, etc).

4.       Using the file and libraries you identified in the previous attacks, try to alter then in such a way as to make the application behave insecurely.  Good targets are files use to storage configuration information or application data (such as cookies).

Launch your application under Holodeck and observe whether your software can securely handle disk, memory and network errors. The application may crash or hang, but watch for subtle symptoms of security breaches, such as sensitive data being written to the hand drive or dumped to the screen or a file.

What is SHODAN ?

SHODAN is a search engine that lets you find specific computers (routers, servers, etc.) using a variety of filters. Some have also described it as a public port scan directory or a search engine of banners.

Web search engines, such as Google and Bing, are great for finding websites. But what if you're interested in finding computers running a certain piece of software (such as Apache)? Or if you want to know which version of Microsoft IIS is the most popular? Or you want to see how many anonymous FTP servers there are? Maybe a new vulnerability came out and you want to see how many hosts it could infect? Traditional web search engines don't let you answer those questions. 

So what does SHODAN index then? Good question. The bulk of the data is taken from 'banners', which are meta-data the server sends back to the client. This can be information about the server software, what options the service supports, a welcome message or anything else that the client would like to know before interacting with the server. For example, following is a FTP banner: 

220 kcg.cz FTP server (Version 6.00LS) ready. 

This tells us a potential name of the server (kcg.cz), the type of FTP server (Solaris ftpd) and its version (6.00LS). For HTTP a banner looks like: 

HTTP/1.0 200 OK
Date: Tue, 16 Feb 2010 10:03:04 GMT
Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a mod_ssl/2.8.9 OpenSSL/0.9.6g
Last-Modified: Wed, 01 Jul 1998 08:51:04 GMT
ETag: "135074-61-3599f878"
Accept-Ranges: bytes
Content-Length: 97
Content-Type: text/html

Environmental Foult Injection

This chapter discusses simulating failures in the application's environment, a process known as environment fault injection. When extraordinary conditions occur because of stress and the failure of dependencies,   error-handling routines, if present, are executed. These are pathways thought  the application that do not add to its functionality but are designed to keep the  functional code from failing. Error-handling routines thought are notoriously subjected to far-less testing than the functional code that they are designed to protect. They are underrepresented because in the past causing environment faults has meant modifying the application's code directly and hard-coding bogus return values. To compound the problem, many failure situations are not envisioned during the designed stage, and error handlers are added as afterthought as vulnerability situations are encountered in the test lab.

With such limited exposure to testing, these code parts are fertile breeding grounds for bugs. Software can only be considered secure if it operated securely in all reasonable operating environments. Thus to have any realistic picture of an applications security vulnerabilities, it must be exposed to environmental failures.

There are three basic approaches to simulating environmental failures in a lab situation :

1. Source-based fault injection : source-based   fault injection can be complicated to achieve but is easy to explain : source statements are modified so that specific faulty behavior is attained. When faults are injected to trigger exceptions, source statements are added, so that internal data can be set values that cause exception conditions to   evaluate to true. However, source based fault injection requires access to source code and, in most cases, the corporation of the original developers, which is not always given.
2. Run-time fault Injection : Applications access external resources thought functions calls to the operating system, such as requesting memory, disk space etc. Run-time fault injection involved getting between the application and the OS and intercepting these calls.

What is software security ?

Security concern are different for any given application.

Some software publishers are concern with piracy of their application, in whole or in part. They want to sell their application to every user and not have it copied illegally and sold on the black market. To these publisher, security means keeping their binaries safe from illegal copying.

Some publishers present their software for free but only allow access to certain parts of the applications  to registered users. These publishers are interested in ensuring that every user gets only the access they paid for and are thus concerned about access control.

They want everyone to have their software, but they want only authorized users to be able to access the part that they paid for.

Some publishers are concerned about their applications vulnerability to malicious input.  publishers of server applications that listen to network ports or desktop applications that execute mobile code are particularly worried about buffer overruns and malicious use. These publishers are intent on ensuring that their applications cannot damage local resources or cause malicious code to execute.

Other software  publishers are worried about the data that their software processes. The data must remain secret for all but authorized users. These  publishers must worry about data being stored in plain text or data that has predictable pattern of residence in memory.

Their concern is to keep their data secret.

Indeed, there are many concern that software publishers have. Thus any bug that causes a CERT advisory or has the potential to cause harm must be considered a security vulnerability.

Information Systems Security and Computer Crime in the IS Curriculum: A Detailed Examination

Foltz, C. Bryan, and Janet S. Renwick. "Information Systems Security and Computer Crime in the IS Curriculum: A Detailed Examination." Journal of Education for Business 86.2 (2010): 119. MasterFILE Premier. EBSCO. Web. 10 Feb. 2011.

Within this article, the Arthur talks about computer crime within the information systems. It explains how computer crime is rising and what are some different ways that we can do to reduce computer crime.

How and Why I Blog

"How and Why I Blog." Out of My Gord. Mar.-Apr. 2010. Web. 10 Feb. 2011. http://www.outofmygord.com/archive/2010/03/06/How-and-Why-I-Blog.aspx

In this blog, the author explains about what he blogs about. He explains that he most often sets aside one hour per day to blog. He usually blogs about whatever is going through his mind or what is going on in his life. He also goes on to tell about how a lot of people blog just to plug in their company, he however does not plug in his company.

Picture a World without Pens, Pencils, and Paper: The Unanticipated Future of Reading and Writing

Bromley, Karen. "Picture a World without Pens, Pencils, and Paper: The Unanticipated Future of Reading and Writing." Journal of College Reading and Learning 41.1 (2010): 97-108. ERIC. EBSCO. Web. 9 Feb. 2011.

Bromely describes a contrast between the process of writing in the past and the present. She goes on to describe the impact current technology has had, and will have on writing in the future. She describes how some newspapers and articles have become entirely online already. She also details how many are embracing the use of computer generated news stories instead of those written by new staff members. She believes that teachers should not only make use of programs that detect plagiarism such as turnitin.com, but also embrace text speak as it is becoming a large part of the next generation's form of communication. It also discusses the benefits of shared information that is publicly edited such as Wikipedia, and the convenience of speech recognition. I like how she describes the somewhat sudden shift from physically to digitally written works as a natural inevitable progression.