RSSHeffner

Plug-N-Play Network Hacking

| December 1, 2008

upnp-logo-exploded_sm.jpgUniversal Plug-N-Play (UPnP) is a protocol that allows various network devices to auto-configure themselves. One of the most common uses of this protocol is to allow devices or programs to open up ports on your home router in order to communicate properly with the outside world (Xbox, for example, does this). The UPnP protocol is built on top of pre-existing protocols and specifications, most notably, UDP, SSDP, SOAP and XML.

This article will address some of the security issues related to UPNP, briefly describe the inner workings of the protocol, and show how to identify and analyze UPNP devices on a network using open source tools. While we will be specifically focusing on IGDs (Internet Gateway Devices, aka, routers), it is important to remember that there are many other devices and systems that support UPNP as well, and they may be vulnerable to similar attacks.

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:heffner}

 

Continue Reading

Intercepted: Windows Hacking via DLL Redirection

| September 9, 2008

windows-security_ico.png

In Windows, all applications must communicate with the kernel through API functions; as such, these functions are critical to even the simplest Windows application. Thus, the ability to intercept, monitor, and modify a program’s API calls, commonly called API hooking, effectively gives one full control over that process. This can be useful for a multitude of reasons including debugging, reverse engineering, and hacking (in all interpretations of the word).

While there are several methods which can be used to achieve our goal, this tutorial will examine only DLL redirection. This approach was chosen for several reasons:

  1. It is relatively simple to implement.
  2. It allows us to view and modify parameters passed to an API function, change return values of that function, and run any other code we desire.
  3. While most other methods require code to be injected into the target process or run from an external application, DLL redirection requires only write access to the target application’s working directory.
  4. We can intercept any API call without modifying the target (either on disk or in memory) or any system files.

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:heffner}

 

Continue Reading

Intro to Reverse Engineering – Part 2

| October 19, 2007

assembler.jpg

In Part 1, Intro to Reverse Engineering – No Assembly Required, we extended the series of coding articles for non-programmers with an area of high interest in the infosec community. We’re proud to be able to bring you the highly anticipated follow-up complete with screen shots, sample code and applications. This one is long and detailed, so strap yourselves in for some great educational content.

This paper is designed to outline some essential reverse engineering concepts, tools and techniques – primarily, debuggers and using the debugging process to reverse engineer application functions and algorithms. It is assumed you have knowledge of basic assembly and C programming. An understanding of Win32 programming and API calls is also helpful. This tutorial does not necessarily have to be read in order (although it is strongly advised), as some sections do not contain information that directly relates to subsequent sections. However, if you begin skipping around and find that you have trouble understanding a concept, or feel like you missed an explanation, it would be best to go back to previous sections of the tutorial and read them first.  

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:Heffner}

Continue Reading

Intro to Reverse Engineering – No Assembly Required

| August 6, 2007

assembler.jpgLast time we went over the C programming language in an introductory article specifically focusing on getting the security professional on the road to coding (or at least the road to understanding). This time around we extend the series of coding articles for non-programmers with an area of high interest in the infosec community, reverse engineering.

This paper is intended as an introduction to reverse engineering for someone who has no experience whatsoever on the subject. You should have some basic knowledge of C programming, and access to a Windows or Linux box (preferably both) using the x86 architecture (i.e., your average computer). No knowledge of assembly code, registers, or the like is assumed, although it helps. The "Introduction" section of the paper is intended for the newcomer who has little or no understanding of what reverse engineering is and may be skipped by those looking for more technical details.

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:Heffner}

Continue Reading

Intro to C

| June 11, 2007

c.jpg

Editor’s Note: We’re proud to be able to bring you the first article in this great, new column from Craig Heffner. This column is aimed squarely at those in the InfoSec field who are tired of hearing that you truly can’t be a security professional without knowing how to code.

Why even learn to program at all?

Not everyone will have a need to learn programming. I’m sure there are many people who are quite accomplished in the field of computer security and have never written a program. Personally, I constantly find myself modifying programs to add or change their functionality, or just writing my own. And needless to say, if you are going to be doing any type of exploit discovery, you will need some programming knowledge.

Without raising the "to code or not to code" argument, here is the way I look at it: hacking is about controlling a computer and making it do what you want – often when it is not designed to do so. A computer by itself is nothing but a bunch of silicon, wires, and metal. Software controls the computer, and, if you can control software, well…there ya go. :)

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:Heffner}

Continue Reading

Smashing The Modern Stack For Fun And Profit

| March 23, 2007

brokenpiggybank1By Craig J. Heffner 

When it comes to buffer overflows, ‘Smashing The Stack For Fun And Profit‘ by Aleph One is still the first resource many people are directed towards, and for good reason; it is thorough, well written, and chock-full of examples. However, the GNU C Compiler (gcc) has evolved since 1998, and as a result, many people are left wondering why they can’t get the examples to work for them, or if they do get the code to work, why they had to make the changes that they did. Having these same problems myself, and being unable to find an updated version of Aleph One’s document on the web, I set out to identify the source of these variations on my own.

I have taken the liberty of writing this paper to share my findings with others who are experiencing the same problems I did, but it is meant only to be a modern supplement to Aleph One’s paper. You should read Smashing The Stack first, as it is assumed that you understand the concepts and code presented there, as well as some standard buffer overflow techniques.

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:heffner}

Continue Reading