Coding for Penetration Testers: Building Better Tools

( 6 )

Overview

Tools used for penetration testing are often purchased or downloaded from the Internet. Each tool is based on a programming language such as Perl, Python, or Ruby. If a penetration tester wants to extend, augment, or change the functionality of a tool to perform a test differently than the default configuration, the tester must know the basics of coding for the related programming language. Coding for Penetration Testers provides the reader with an understanding of the scripting languages that are commonly used ...

See more details below
Paperback
$27.88
BN.com price
(Save 30%)$39.95 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (11) from $15.87   
  • New (5) from $22.16   
  • Used (6) from $15.87   
Coding for Penetration Testers: Building Better Tools

Available on NOOK devices and apps  
  • NOOK Devices
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK Study
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$39.95
BN.com price

Overview

Tools used for penetration testing are often purchased or downloaded from the Internet. Each tool is based on a programming language such as Perl, Python, or Ruby. If a penetration tester wants to extend, augment, or change the functionality of a tool to perform a test differently than the default configuration, the tester must know the basics of coding for the related programming language. Coding for Penetration Testers provides the reader with an understanding of the scripting languages that are commonly used when developing tools for penetration testing. It also guides the reader through specific examples of custom tool development and the situations where such tools might be used. While developing a better understanding of each language, the reader is guided through real-world scenarios and tool development that can be incorporated into a tester's toolkit.

Read More Show Less

Editorial Reviews

From the Publisher
"Penetration testing is a profession that requires the mastery of dozens of tools; every job poses challenges that require these tools to be mixed, matched, and automated. The master penetration tester not only excels at using his or her toolbox, but also expands it with custom scripts and unique programs to solve the challenge of the day. This book provides a solid introduction to custom scripting and tool development, using multiple languages, with a penetration tester's goals in mind. This background can transform penetration testing from a manual, often repetitive task, to an efficient process that is not just faster, but also more accurate and consistent across large engagements."—HD Moore, Metasploit Founder and CSO of Rapid7

"Penetration testing requires that the tester understand the target as much as possible, and know how to perform various attacks while being as efficient as possible. Having the skill set to create and use a variety of scripts increases the penetration tester's efficiency and elevates him or her from the script kiddie to the professional realm. Ryan Linn and Jason Andress have created a guide that explores and introduces the techniques that are necessary to build the scripts used during a test. No matter the platform, this book provides the information required to learn scripting and become a world-class penetration tester. This is definitely a book that will remain close at hand for every test I perform!"—Kevin Johnson, Senior Consultant, Secure Ideas

Read More Show Less

Product Details

  • ISBN-13: 9781597497299
  • Publisher: Elsevier Science
  • Publication date: 10/7/2011
  • Pages: 320
  • Sales rank: 685,909
  • Product dimensions: 7.40 (w) x 9.10 (h) x 0.90 (d)

Meet the Author

Jason Andress (ISSAP, CISSP, GPEN, CEH) is a seasoned security professional with a depth of experience in both the academic and business worlds. Presently he carries out information security oversight duties, performing penetration testing, risk assessment, and compliance functions to ensure that critical assets are protected. Jason has taught undergraduate and graduate security courses since 2005 and holds a doctorate in computer science, researching in the area of data protection. He has authored several publications and books, writing on topics including data security, network security, penetration testing, and digital forensics.

Ryan Linn (OSCE, GPEN, GWAPT) is a penetration tester, an author, a developer, and an educator. He comes from a systems administation and Web application development background, with many years of IT security experience. Ryan currently works as a full-time penetration tester and is a regular contributor to open source projects including Metasploit, The Browser Exploitation Framework, and the Dradis Framework. He has spoken at numerous security conferences and events, including ISSA, DEF CON, SecTor, and CarolinaCon.

Read More Show Less

Read an Excerpt

Coding for Penetration Testers

Building Better Tools
By Jason Andress Ryan Linn

SYNGRESS

Copyright © 2012 Elsevier Inc.
All right reserved.

ISBN: 978-1-59749-730-5


Chapter One

Introduction to command shell scripting

INFORMATION IN THIS CHAPTER:

• On Shell Scripting

• UNIX, Linux, and OS X Shell Scripting

• Bash Basics

• Putting It All Together with bash

• Windows Scripting

• PowerShell Basics

• Putting It All Together with PowerShell

Shell scripts can be useful for a great many things in the penetration testing world, in the system administration world, in the network world, and in most any area that depends on computing technology to function. Shell scripts allow us to string together complex sets of commands, develop tools, automate processes, manipulate files, and more, while using a very basic set of development resources.

Particularly in penetration testing, the ability to write shell scripts can be a highly necessary skill. When we are attacking an environment, we don't always get to choose the tools we have at hand, and we may very well find ourselves in a situation where we are not able to, or are not allowed to, install tools or utilities on a system. In such cases, the ability to craft our own tools from the scripting resources already available to us can ultimately mean the difference between failure and success on a penetration test.

In this chapter we will discuss some of the basics of shell scripts. We will talk about how to use the shells that exist in operating systems such as UNIX, Linux, Apple's OS X, and Windows. Finally, we will build a couple of port scanning tools using shell scripting languages for both UNIX-like operating systems and Microsoft operating systems.

ON SHELL SCRIPTING

Unlike any programming language we might choose to use, or any development tools we might like to have access to, we can almost always depend on some sort of shell being present on a system. While we may not always have access to the particular flavor of shell we like, there will usually be something present we can work with.

What is a shell?

A shell is the interface between the user and the operating system, allowing us to run programs, manipulate files, and perform a number of other operations. All operating systems use a shell of one type or another, some of them graphical and some of them text-based. Many operating systems provide access to both graphical and nongraphical shells, and each is useful in its own way.

A shell might consist of a graphical user interface (GUI), as in the case of the Microsoft Windows desktop interface, and Gnome or KDE on Linux. Such graphical shells are convenient, as they allow us to use fancy graphical menus, show us colorful icons to represent files, and allow us to interact with items by clicking them with a mouse.

Text-based shells, such as that shown in Figure 1.1, allow us to communicate with the operating system via a variety of commands and features built into the shell, as well as running other programs or utilities. Text-based shells are the ancestral user interface of many operating systems and still enjoy a great following today among the technically inclined.

On some operating systems, such as Windows, we are likely to find only the built-in graphical and text-based shells, although we may potentially find more added by a particularly technical user. On UNIX-like operating systems, such as the many varieties of UNIX and Linux, or OS X, we may find a wide variety of graphical and text shells. This broad choice of interface is very common on such operating systems, and we may find that the users or administrators of the system have customized it heavily in order to suit their particular tastes. Commonly, however, we will find at least Gnome or KDE as a graphical shell, and bash as a text-based shell. For purposes of penetration testing, text-based shells tend to be the more useful for us to access.

What is a script?

A script, short for scripting language, is a programming language like any other, and may be similar in nature to other languages such as C++ or Java. The primary difference between a scripting language and other programming languages is that a program written in a scripting language is interpreted rather than compiled.

When we look at a traditional programming language, such as C++, the text we write that defines the commands we want to run is processed through a compiler and turned into machine code that is directly executable by the kernel/CPU. The resultant file is not human-readable. Any changes to our commands mean we have to send the changed text through the compiler again, resulting in a completely new executable. In interpreted languages, the text we create that contains our commands is read by an interpreter that does the conversion to machine code itself, as it's running the script. The text here is still human-readable, and does not have to be recompiled if a change is made.

Normally, scripting languages have their own interpreters, so we need to install a separate interpreter for Python, another for Ruby, and so on. Shell scripts are a bit of a special case, as the scripts are interpreted using the shell itself, and the interpreter is already present as part of the shell.

NOTE

The various languages we discuss in the course of this book, including shell scripts, Python, Perl, Ruby, and JavaScript, are all interpreted languages. With many scripting languages, multiple interpreters are available from different vendors, often with somewhat different behaviors and sets of features.

Scripting languages are used daily in the execution of many different tasks. We can see scripting languages at use in printers, in the case of the Printer Control Language (PCL) created by Hewlett-Packard [1], in AJAX, JavaScript, ActiveX, and the many others that are used to generate the feature-rich Web pages we enjoy today, and in video games, such as Civilization V and World of Warcraft that make use of Lua.

A great number of scripting languages are available on the market, with more being created all the time. Some of the more useful become widely adopted and enjoy ongoing development and community support, while others are doomed to be adopted by only a few stalwart developers and quietly fade away.

Shell scripts

One of the most basic and most commonly available tools we can add to our penetration testing tool development arsenal is the shell script. A shell script is a program, written in a scripting language, which is used to interface in some way with the shell of the operating system we are using. While it is possible to script our interactions with a graphical shell, and indeed there are many programs and utilities that will allow us to do so, the term shell script is commonly used to refer to programs that interact with text-based shells.

As we discussed earlier in the chapter, scripts are processed and executed by a utility called an interpreter. In the case of shell scripts, our script is interpreted directly by the shell and, in fact, there is often no difference in the tools used to process our shell scripts and those used to handle single commands. If we look at the text-based shell called bash, a shell common to most UNIX-like operating systems, it serves to process single commands such as ls, which is used to list the contents of a directory, and more complex scripts.

In most cases, although they are not typically classified as a "real" programming language, shell scripts do possess a very similar set of features as any other language. They often include the same or very similar capabilities to those that we might use to store data in variables or other data structures, create subroutines, control the flow of the program, include comments, and so on. It is entirely possible to develop large and complex programs as shell scripts, and many examples of such constructions can be found with a brief search on the Internet. In such cases, we may actually be better off, in terms of efficiency of resource usage and ease of maintenance, using a more feature-rich scripting language such as Ruby or Perl, or even a compiled language such as C++.

Where shell scripting is useful

When we are assembling a program or utility, we might choose to create a shell script rather than use another scripting language or a compiled language, for a variety of reasons. One of the primary reasons might be that our need is very simple and we only want to quickly accomplish our task, rather than taking the time to develop a full application. For example, we might want to quickly iterate through the entire file system on a server used for storage in order to find and delete MP3 files stored by users in order to free up a little disk space. While we might want to develop this into a full application at some point, for the time being we just need to get the job done.

We may also need to put together a chain of tools in order to carry out our task, commonly known as gluing the tools together. For example, if we wanted to create a list of all the printers in our office and their accompanying serial numbers, we might want to ping the range of IP addresses in order to find the devices that were up, then query each of those devices with snmpget in order to retrieve the device descriptions so that we can find the printers. We could then use our refined list of printers and snmpget again to retrieve the serial numbers. This would certainly not be the most elegant or efficient method to use, but sometimes quick and dirty is just what we need.

As we mentioned earlier in the chapter, particularly when working with a penetration test, we may have limited development resources to work with on the target system. A common step in hardening a server is to remove any tools not needed for the server to function, so we may not necessarily find Perl, Python, or our language of choice installed on the system. We can, however, generally depend on the presence of a text-based shell that will allow us to create a shell script, or make use of one we were able to move to the machine. One of the nice features of scripting languages is that the source code files are plain text and do not need to be compiled before we can run them. This means that even if our only access to the target system is through a terminal connection, we can often create a new file, paste our script into it, and be off and running.

UNIX, LINUX, AND OS X SHELL SCRIPTING

When we look at the tools we have available to develop shell scripts, there are two main categories: UNIX-like shells and Microsoft shells. In this section, we will discuss UNIX-like shells, and we will cover Microsoft shells later in this chapter.

Shell availability and choices

UNIX-like systems, including the many varieties of UNIX and Linux, as well as Apple's OS X, have a few common text-based shells. We can typically find the Korn shell, Z shell, C shell, and Bourne-again shell either already present or easily installable on the vast majority of the UNIX-like systems we might encounter.

NOTE

As of OS X, first seen in 1999 and continuing to the present, Apple's operating system is based on a UNIX-like kernel called XNU, which stands for "X is Not Unix". OS X is effectively a modified UNIX operating system behind its stylish interface, and is compatible in many areas with similar UNIX and Linux derived operating systems, including the text-based shells it uses.

C shell-compatible shells

The C shell, commonly known as csh, is written in the C programming language and uses a scripting style generally similar to the C programming language. Csh was created with an emphasis on use at the command line. It provides features to aid in such efforts, such as command history and filename completion, functions much rarer in the world of shells when it was developed. Due to differences in the way the shell functions and the way scripts are written, csh is almost entirely incompatible with shells outside of those immediately related to it.

A descendant of csh, the TENEX C shell, otherwise known as tcsh, was released by Ken Green in 1983. Ultimately, tcsh is csh with the added or enhanced features for command history, editing, and filename completion merged in. For systems that ship with a csh-like shell installed by default, we are likely to find that this shell is actually tcsh, as this is the most actively developed and maintained shell in the C shell family at this point.

Bourne-compatible shells

The Bourne shell, often called simply sh, was developed by Stephen Bourne in the late 1970s, and is a common ancestor of several other shells, including the Bourne-again shell, K shell, and Z shell, just to name a few. Among these shells we can find a variety of common features.

(Continues...)



Excerpted from Coding for Penetration Testers by Jason Andress Ryan Linn Copyright © 2012 by Elsevier Inc.. Excerpted by permission of SYNGRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Foreword by Ed Skoudis

Chapter0:Introduction

Chapter1:Introduction to Command Shell Scripting

Chapter 2: Introduction to Python

Chapter3: Introduction to Perl

Chapter 4: Introduction to Ruby

Chapter 5: Introduction to Web Scripting with PHP

Chapter 6: Manipulating Windows with PowerShell

Chapter 7: Scanner Scripting

Chapter 8: Information Gathering

Chapter 9: Exploitation Scripting

Chapter 10: Post-Exploitation Scripting

Appendix: Subnetting and CIDR Addresses

Read More Show Less

Customer Reviews

Average Rating 4
( 6 )
Rating Distribution

5 Star

(4)

4 Star

(1)

3 Star

(0)

2 Star

(0)

1 Star

(1)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 – 5 of 6 Customer Reviews
  • Anonymous

    Posted June 6, 2014

    8730-8750

    &#8730&#8731&#8732&#8733&#8734&#8735&#8736&#8737&#8738&#8739&#8740&#8741&#8742&#8743&#8744&#8745&#8746&#8747&#8748&#8749&#8750

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted July 8, 2013

    &hearts

    &clubs &spades &clovers &#2335 &#1234 &#6278 &#1739 &5268

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 22, 2013

    &hearts

    &hearts &spades

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted November 4, 2011

    No text was provided for this review.

  • Anonymous

    Posted January 5, 2012

    No text was provided for this review.

Sort by: Showing 1 – 5 of 6 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)