Monday, March 21, 2011

Buffer Overflow attack

Description: Buffer overflow errors are characterized by the overwriting of memory fragments of the process, which should have never been modified intentionally or unintentionally. Overwriting values of the IP (Instruction Pointer), BP (Base Pointer) and other registers causes exceptions, segmentation faults, and other errors to occur. Usually these errors end execution of the application in an unexpected way. Buffer overflow errors occur when we operate on buffers of char type.

How to use buffer overflow errors in a different way?
Generally, exploitation of these errors may lead to:
  • application DoS
  • reordering execution of functions
  • code execution (if we are able to inject the shellcode, described in the separate document)
How are buffer overflow errors are made?
These kinds of errors are very easy to make. For years they were a programmer's nightmare. The problem lies in native C functions, which don't care about doing appropriate buffer length checks. Below is the list of such functions and, if they exist, their safe equivalents:
  • gets() -> fgets() - read characters
  • strcpy() -> strncpy() - copy content of the buffer
  • strcat() -> strncat() - buffer concatenation
  • sprintf() -> snprintf() - fill buffer with data of different types
  • (f)scanf() - read from STDIN
  • getwd() - return working directory
  • realpath() - return absolute (full) path
Use safe equivalent functions, which check the buffers length, whenever it's possible. Namely:
  1. gets() -> fgets()
  2. strcpy() -> strncpy()
  3. strcat() -> strncat()
  4. sprintf() -> snprintf()
Those functions which don't have safe equivalents should be rewritten with safe checks implemented. Time spent on that will benefit in the future. Remember that you have to do it only once.
Use compilers, which are able to identify unsafe functions, logic errors and check if the memory is overwritten when and where it shouldn't be.

Friday, March 18, 2011

Interesting Internet Security Horror stories

when trusted IT individuals go wrong: Importance of Security can be well revised by these horror stories. These well composed story contains three real time scenarios where internal employees were trusted more than what they should and how much they can affect a business.
Scenario 1: Failure to prevent dual control/ shared knowledge of critical assets/ Lack of Separation of duties and lack of monitoring of administrative functions caused a company a total of $250,000 to $300,000 to get it back to normal operations.
Scenarios 2: How a Sys Admin misused her privilege to plant an logic bomb in her company's internal network and costed 7 million USD loss to the company...
Scenario 3: When this Fortune 100 company upgraded its security, it made a nasty discovery. One of its senior system admins, who had been there at least eight years, had surreptitiously added a page to the company's e-commerce Web site.
A very well written story by Tam Harbert on how important is it to look at the basics when it comes to security.. For full  on How could Security fail: when trusted people go bad.

Friday, March 11, 2011

Wednesday, March 2, 2011

USB Cable as an attack tool

Angelos Stavrou, an assistant professor of computer science at George Mason University, and student Zhaohui Wang wrote software that changes the functionality of the USB driver so that they could launch a surreptitious attack while someone is charging a smartphone or syncing data between a smartphone and a computer.
Basically, the exploit works by adding keyboard or mouse functionality to the connection so an attacker can then start typing commands or click the mouse in order to steal files, download additional malware, or do other things to take control of the computer, Stavrou told CNET in an interview. The exploit is enabled because the USB protocol can be used to connect any device to a computing platform without authentication
Continure Reading: Here...