•

You want a penetration testing job?

Posted on September 10, 2009 by mmarshall Leave a comment

We take hiring pretty seriously and have a rigorous screening and background check process to find the “A Team.”  While most of the process is uneventful, some of the applicants give us a good chuckle.   Here is a list of some of our favorite candidates who didn’t make the grade:

  1. Taking the wrong path First line of cover letter & resume: “I am required to inform you that I have a felony conviction for illegal hacking.  My plea bargain requires me to include this in my resume and cover letter for the next ten years.”

  2. Computer related indiscretions? “During a drunken brawl I hit a guy in the face with a computer.” Describing this as computer related doesn’t give you Mitnick like hacker creed.

  3. “I can’t believe they pressed charges” “Who would have thought I’d get in trouble for ebaying the stacks of equipment my old employer had laying around?”

  4. Good at research? After taking three days to email back our written questionnaire, we really loved this answer:  Describe your Penetration Testing experience and interests: “I am not really sure what penetration testing is, but am confident I would do a good job.” Ever heard of Google?

  5. Strategic career move? “I am trying to get into network security after three successful years as the founder and CEO of Happy Dog Pet Washing.”

  6. A bit presumptuous? “When you interview me I will bring you a signed copy of my latest security book.” It might have been worth doing the interview just to see how he would autograph an ebook.

  7. Bonus points for honesty? Primary reference: “My parole officer.”

  8. Timeliness - We once had a guy show up for an interview apologizing profusely for being 30 minutes late. We replied “don’t worry, your interview is not until tomorrow.” We still debate around the office if he was early or late.

Have some hiring stories to share?  Please post them in the comments.

Web Application Security

Posted on August 28, 2009 by admin in Main | Leave a comment

Customers often ask the following question:  What is the best approach to securing my web applications?  Of course, the answer to the question is what our web application security assessments are all about.  But if you haven’t yet engaged in that process, this post briefly outlines some ideas that you can institute to have a greater degree of confidence that your web applications are secure.

Fundamentally, secure web applications are a result of a secure software development lifecycle.  There are a number of books on the subject.  I have found that a useful reference can be found through OWASP: http://www.owasp.org/index.php/CLASP_Concepts.   What‘s necessary is for the software development team to have a structured set of guidelines to ensure that information security is kept as a key requirement as part of the development process.  Often it is helpful to maintain an implementation guide and templates that reflect best practices.  As with any endeavor related to security, I recommend a risk based approach where development effort to secure the application is guided by the risks to business.

In order to have an understanding of the risks associated with an application; developers must understand the threats that are present.  A common practice is to develop a threat model that characterizes the threats and risks to the application.  Microsoft has invested significant resources in formalizing this process.  They recommend a step by step process of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development.  To assist in this effort of threat and risk modeling Microsoft advocates a threat classification scheme known as STRIDE.  This scheme aims to characterize the threats with respect to the exploit that may be employed.  This clever acronym stands for:

  • Spoofing Identity
  • Tampering with data
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privilege

These areas provide a helpful mechanism for enumerating threats to the application.  Closely associated with this process is a scoring scheme to help evaluate risk to the application.  Another acronym applies to this problem as well: DREAD.

DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat.  It stands for

  • Damage potential
  • Reproducibility
  • Exploitability
  • Affected users
  • Discoverability

Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk.  As always risk needs to be evaluated in terms of both probability and impact.

During the development process the team can often benefit from using tools aimed at identifying security flaws.  The most prevalent approach used by security conscious developers is to employ source code analysis tools.  These tools automate the process of evaluating source code for common security vulnerabilities.  Many commercial tools have gained popularity and there are open source options as well, including RATS and Flawfinder.

As the application reaches the integration stage best practices call for black-box testing.  Many commercial tools address this method of testing applications from a security point of view.  Open source solutions exist as well including, Spike and WebScarab.  I have found that one of the more effective processes calls for integration of the black-box test with the build cycle.  In this fashion, when the application is built, the black box testing program is run as well.  Once complete, developers can review the results and address vulnerabilities that have been identified.

The techniques described above help secure new applications, but organizations must also be aware of the risks associated with applications that are running in production.  To assess these applications a different strategy must be employed.  One potential approach is to run a black-box test with a suite of attacks that are known to be non-invasive and likely will not take down the application.  Because this approach can miss many high impact vulnerabilities, I would recommend against it.  A better option, given that the application is deployed in a virtualized environment, is to take a “snapshot” of the application to be tested.  This image is then moved to a staging environment where it can be tested thoroughly.  When vulnerabilities are identified the application must be fixed, tested and then released back to production under change control.

Hopefully, these notes on securing applications have generated some ideas regarding how you can go about improving your application security process.

Enumerating SSL Ciphers with SSLScan

Posted on August 24, 2009 by Nathan Drier 2 Comments

SSLScan

You’d think that checking your email in a web browser is a simple task. Open up Firefox, plunk in your username and password, and start sending things to the SPAM folder. The truth is, when you load up your web mail in a browser, a flurry of activity takes place behind the scenes. One of the most interesting things that happens is how your web browser interacts with your web mail server (or any SSL-enabled service) to select a encryption protocol to use. While I won’t dive too deep into the mechanics of it all, I will try to explain why it is important.

Before the mail server will send any sensitive information to your browser, they need to agree on how they will encrypt the data. This gets boiled down to your web browser and the server listing their supported ciphers, and the two parties agreeing on the strongest cipher or protocol that they both support. The key here is supported protocols.  This means that your SSL-enabled service supports a wide array of encryption ciphers and protocols so it can play nice with all sorts of different browsers and operating systems.  In a perfect world, all ciphers and protocols are created equal, but like everything else; there is good encryption and there is bad encryption.

This is where a nifty little app called SSLScan steps in. It runs against SSL-enabled services and finds out exactly which protocols and ciphers are supported by the server.  This is handy for identifying potentially weak SSL ciphers or protocols (SSLv2, low-bitstrength ciphers, NULL ciphers, etc).  It also lists preferred ciphers and details about the SSL certificates.   (If all this is nothing new to you, see The Shell Shakespeare’s post on SSL vulnerabilities – that guy could make meatloaf with nothing but emacs and a bash prompt.)

Debian users are lucky -  a version of SSLScan exists in the Squeeze repo (although its a version behind).  For everyone else, it should build easily on common systems.  I know other tools exist to enumerate SSL methods.  Most vulnerability scanners will flag weak ciphers. TSS will show you how to use OpenSSL and Bash to do it.  Does anyone have other favorites?

# ./sslscan 10.0.0.45
 _
 ___ ___| |___  ___ __ _ _ __
 / __/ __| / __|/ __/ _` | '_ \
 \__ \__ \ \__ \ (_| (_| | | | |
 |___/___/_|___/\___\__,_|_| |_|

 Version 1.8.0

http://www.titania.co.uk

 Copyright Ian Ventura-Whiting 2009

Testing SSL server 10.0.0.45 on port 443

 Supported Server Cipher(s):
 Rejected  N/A              SSLv2  168 bits  DES-CBC3-MD5
 Rejected  N/A              SSLv2  56 bits   DES-CBC-MD5
 Rejected  N/A              SSLv2  40 bits   EXP-RC2-CBC-MD5
 Rejected  N/A              SSLv2  128 bits  RC2-CBC-MD5
 Rejected  N/A              SSLv2  40 bits   EXP-RC4-MD5
 Rejected  N/A              SSLv2  128 bits  RC4-MD5
 Rejected  N/A              SSLv3  256 bits  ADH-AES256-SHA
 Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
 Rejected  N/A              SSLv3  256 bits  DHE-DSS-AES256-SHA
 Accepted  SSLv3  256 bits  AES256-SHA
 Rejected  N/A              SSLv3  128 bits  ADH-AES128-SHA
 Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
 Rejected  N/A              SSLv3  128 bits  DHE-DSS-AES128-SHA
 Accepted  SSLv3  128 bits  AES128-SHA
 Rejected  N/A              SSLv3  168 bits  ADH-DES-CBC3-SHA
 Rejected  N/A              SSLv3  56 bits   ADH-DES-CBC-SHA
 Rejected  N/A              SSLv3  40 bits   EXP-ADH-DES-CBC-SHA
 Rejected  N/A              SSLv3  128 bits  ADH-RC4-MD5
 Rejected  N/A              SSLv3  40 bits   EXP-ADH-RC4-MD5
 Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
 Rejected  N/A              SSLv3  56 bits   EDH-RSA-DES-CBC-SHA
 Rejected  N/A              SSLv3  40 bits   EXP-EDH-RSA-DES-CBC-SHA
 Rejected  N/A              SSLv3  168 bits  EDH-DSS-DES-CBC3-SHA
 Rejected  N/A              SSLv3  56 bits   EDH-DSS-DES-CBC-SHA
 Rejected  N/A              SSLv3  40 bits   EXP-EDH-DSS-DES-CBC-SHA
 Accepted  SSLv3  168 bits  DES-CBC3-SHA
 Rejected  N/A              SSLv3  56 bits   DES-CBC-SHA
 Rejected  N/A              SSLv3  40 bits   EXP-DES-CBC-SHA
 Rejected  N/A              SSLv3  40 bits   EXP-RC2-CBC-MD5
 Accepted  SSLv3  128 bits  RC4-SHA
 Accepted  SSLv3  128 bits  RC4-MD5
 Rejected  N/A              SSLv3  40 bits   EXP-RC4-MD5
 Rejected  N/A              SSLv3  0 bits    NULL-SHA
 Rejected  N/A              SSLv3  0 bits    NULL-MD5
 Rejected  N/A              TLSv1  256 bits  ADH-AES256-SHA
 Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
 Rejected  N/A              TLSv1  256 bits  DHE-DSS-AES256-SHA
 Accepted  TLSv1  256 bits  AES256-SHA
 Rejected  N/A              TLSv1  128 bits  ADH-AES128-SHA
 Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
 Rejected  N/A              TLSv1  128 bits  DHE-DSS-AES128-SHA
 Accepted  TLSv1  128 bits  AES128-SHA
 Rejected  N/A              TLSv1  168 bits  ADH-DES-CBC3-SHA
 Rejected  N/A              TLSv1  56 bits   ADH-DES-CBC-SHA
 Rejected  N/A              TLSv1  40 bits   EXP-ADH-DES-CBC-SHA
 Rejected  N/A              TLSv1  128 bits  ADH-RC4-MD5
 Rejected  N/A              TLSv1  40 bits   EXP-ADH-RC4-MD5
 Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
 Rejected  N/A              TLSv1  56 bits   EDH-RSA-DES-CBC-SHA
 Rejected  N/A              TLSv1  40 bits   EXP-EDH-RSA-DES-CBC-SHA
 Rejected  N/A              TLSv1  168 bits  EDH-DSS-DES-CBC3-SHA
 Rejected  N/A              TLSv1  56 bits   EDH-DSS-DES-CBC-SHA
 Rejected  N/A              TLSv1  40 bits   EXP-EDH-DSS-DES-CBC-SHA
 Accepted  TLSv1  168 bits  DES-CBC3-SHA
 Rejected  N/A              TLSv1  56 bits   DES-CBC-SHA
 Rejected  N/A              TLSv1  40 bits   EXP-DES-CBC-SHA
 Rejected  N/A              TLSv1  40 bits   EXP-RC2-CBC-MD5
 Accepted  TLSv1  128 bits  RC4-SHA
 Accepted  TLSv1  128 bits  RC4-MD5
 Rejected  N/A              TLSv1  40 bits   EXP-RC4-MD5
 Rejected  N/A              TLSv1  0 bits    NULL-SHA
 Rejected  N/A              TLSv1  0 bits    NULL-MD5

 Prefered Server Cipher(s):
 SSLv3  256 bits  DHE-RSA-AES256-SHA
 TLSv1  256 bits  DHE-RSA-AES256-SHA
...

Attacking Webmail User Accounts

Posted on August 4, 2009 by Nathan Drier 3 Comments

OWA

Webmail is absolutely everywhere.  I rarely come across a corporate network that doesn’t have Outlook Web Access, Groupwise, or some other variant of webmail listening.  Being able to get at email accounts from the Internet can save employees a lot of time and headache, but using those accounts with weak passwords can result in an even larger headache.  Knowing how the majority of the planet uses email (sending some pretty sensitive data) this creates a large risk for most any company.  I’ll run through a quick list of tools and processes that I use to test the strength of webmail logins.

The first part of any password attack is gathering valid usernames.  For attacks against webmail, this usually means scouring the target’s web sites looking for either specific usernames, or the naming structure for their accounts.  The latter is easy – you can dig through the targets website and collect names of employees, and rewrite them to fit the company’s standard account naming policy(Joe User becomes joe.user, juser, joeuser,  etc).  There are also  some tools that automate the gathering of this information:

  • Metagoofil – Metagoofil will search a particular domain or website, download all the documents from it, and parse the metadata looking for usernames, internal file locations, and lots of other info.  You can get an absolutely incredible amount of information from metadata.

  • FOCA – Much like Metagoofil, but appears to strip out even more information from documents.  This tool recently debuted at Defcon17.

  • theHarvester – This tool also does a good job of utilizing search engines to gather email addresses and usernames.  It searches social networking sites, the PGP key repositories, and uses general search engine tactics as well.

There are many other ways to enumerate usernames from public resources,  but these tools should give a good starting point.  Use them in combination along with some manual searching to create a username list.

Once we have our list of users, we can move on to creating a password list.  There are many ways to construct a valid password list for a specific target.  I like to start by grabbing the DPL (Default Password List) and stripping out any vendor specific stuff.  Ill then add in the old favorites such as all the variations on Password1.  Then, ill start looking for some more specific words.  Ill do some research on the target, and include things like the business name, local sports teams, addresses and universities.  Ill then use a application like John the Ripper to run permutations on the list we just created.  John lets you specify custom permutations rules, and can take the word ‘redspin’ and output redspin, Redspin, red-spin, redspin1, Red-spin1, etc.

Now that we have some valid usernames and a relevant password list, we can move into the attack.  There are few tools to help automate password attacks against webmail login pages, but the few that exist are quite handy:

  • OWABF – Outlook Web Access Brute Force.  A nice script that automates attacks against Outlook Web Access.

  • WMAT – Web Mail Auth Tool.  A tool that supports multiple ‘patterns’ for setting up attacks against different webmail services.  It currently includes patterns for horde, hordeIMP, kerio, mdaemon and squirrelmail.  The structure is pretty easy to write new patterns for if you need to test a unique login page.

That’s all there is to it.  We have collected valid usernames from the target, created some customized password lists, and have listed some tools you can use to tie it all together.  One thing to keep in mind is the use of lockout policies.  The last thing you want to do it lock out a bunch of live email accounts, so unless you know the lockout threshold (if there is one), you might want to limit the password guesses per account to something sane.

$ python owabf.py -s https://webmail.example.com -u userlist -p top100.pass
***********************************
***    OWA Brute Forcer    ***
***    OWABF v 1.3        ***
***    Dejan Levaja        ***
***    http://www.netsec.rs    ***
***    dejan.levaja@netsec.rs    ***
***********************************
Outlook Web Access Brute Forcer
Login unsuccessful
joe.user     654321
Login unsuccessful
joe.user     abc12345
Login unsuccessful
joe.user     123456
Login unsuccessful
joe.user     Password?
Login unsuccessful
joe.user     password
Login unsuccessful
joe.user     welcome1
Login unsuccessful
joe.user     Password1
Login unsuccessful
joe.user     Mailbox1
...

String Encoding in the Shell

Posted on July 24, 2009 by The Shell Shakespear Leave a comment

Data encoding in the shell is a quick and reliable method to parse input in one type of format to format of another type. This could be done in order to determine how an application has converted input, or to encode your input in such a way as to bypass a security filter. These include some valuable methods such as HEX, HTML, URL, various password representations, common hashes and even some compression encodings. What follows are some of my favourite methods to convert input on the command line. Some of these rely on commands that are non-standard, but typically available from your Linux Distribution’s repository. Lots of Python snippets are included as well. These examples can be run individually by or all together in a bash file encode.sh:

#!/bin/bash
 
if [ $# -ne 1 ]
then
  echo "Performs a number of encodings on the first argument string"
  echo "Usage: `basename $0` {string}"
  exit 1
fi
 
printf "\n# String Scrambles:\n"
printf "%-20s\t" 'Normal:'; echo "$1"
printf "%-20s\t" 'Reversed:'; echo "$1" | rev
printf "%-20s\t" 'Case Reversed:'; echo "$1" | tr '[A-Z][a-z]' '[a-z][A-Z]'
printf "%-20s\t" 'ROT13:'; echo "$1" | gcipher -c Rot -k 13
#printf "%-20s\t" 'Rot13:' ; python -c "print '''$1'''.encode('rot13')"
printf "%-20s\t" 'GIE:'; echo "$1" | gcipher -c Gie
printf "%-20s\t" 'Caesar:'; echo "$1" | gcipher -c Ceasar
printf "%-20s\t" 'Vigenere:'; echo "$1" | gcipher -c Vigenere -k vigenere
# printf "%-20s\t" 'Anagrams:'; wordplay -s "$1" | sort -u | sed -n '1h;2,$H;${g;s/\n/, /g;p}'
# Due to both terminal and editor encodings, this is better executed on a non-UTF8 terminal:
printf "%-20s\t" 'Leet (l334):'; echo "$1" | tr [a-z] [A-Z] | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' '4ß(Ð3ƒ9H1JK£MN0PQ®$7µVWX¥2' | sed 's_H_|-|_g;s_J_\_|_g;s_K_|{_g;s_M_|\\/|_g;s_N_|\\|_g;s_P_|°_g;s_Q_¶¸_g;s_V_\\/_g;s_W_\\/\\/_g;s_X_)(_g' #See http://www.albinoblacksheep.com/text/leet
 
printf "\n# Numerical Representations:\n"
printf "%-20s\t" 'INT:'; echo -n "$1" | hexdump -ve '/1 "%03i"'; echo
printf "%-20s\t" 'HEX:'; echo -n "$1" | hexdump -ve '/1 "%02x"'; echo
printf "%-20s\t" 'OCT:'; echo -n "$1" | hexdump -ve '/1 "%02o"'; echo
printf "%-20s\t" 'BIN:'; echo -n "$1" | xxd -b -g0 -c0 | cut -b10-56 | tr -d '\n '; echo
 
printf "\n# Passwords:\n"
printf "%-20s\t" "CRYPT w/o SALT:"; echo -n "$1" | openssl passwd -crypt -stdin -salt 00
printf "%-20s\t" "CRYPT w/ Random SALT:"; echo -n "$1" | openssl passwd -crypt -stdin
printf "%-20s\t" "DES w/ CR SALT:"; echo -n "$1" | openssl passwd -crypt -stdin -salt CR
printf "%-20s\t" "Shadow w/o SALT:"; echo -n "$1" | openssl passwd -1 -stdin -salt 00000000
printf "%-20s\t" "Shadow w/ RANDOM SALT:"; echo -n "$1" | openssl passwd -1 -stdin
printf "%-20s\t" "Apache w/o SALT:"; echo -n "$1" |  openssl passwd -apr1 -stdin -salt 00000000
printf "%-20s\t" "Apache w/ RANDOM SALT:"; echo -n "$1" |  openssl passwd -apr1 -stdin
printf "%-20s\t" "LM Password:"; python -c "import smbpasswd; print smbpasswd.lmhash(\"\"\"$1\"\"\")" #requires python-smbpasswd
printf "%-20s\t" "NTLM Password:"; python -c "import smbpasswd; print smbpasswd.nthash(\"\"\"$1\"\"\")" #requires python-smbpasswd
 
printf "\n# Digest Hashes (newline not included):\n"
#printf "%-20s\t" 'BINARY MD5:' ; echo -n $1 | openssl dgst -binary
printf "%-20s\t" 'MD5:'; echo -n $1 | openssl dgst -md5
printf "%-20s\t" 'MD4:'; echo -n $1 | openssl dgst -md4
printf "%-20s\t" 'MD2:'; echo -n $1 | openssl dgst -md2
printf "%-20s\t" 'SHA1:'; echo -n $1 | openssl dgst -sha1
printf "%-20s\t" 'SHA:'; echo -n $1 | openssl dgst -sha
printf "%-20s\t" 'SHA224:'; echo -n $1 | openssl dgst -sha224
printf "%-20s\t" 'SHA256:'; echo -n $1 | openssl dgst -sha256
printf "%-20s\t" 'SHA384:'; echo -n $1 | openssl dgst -sha384
printf "%-20s\t" 'SHA512:'; echo -n $1 | openssl dgst -sha512
#printf "%-20s\t" 'MDC2:' ; echo -n $1 | openssl dgst -mdc2
printf "%-20s\t" 'RIPEMD160:'; echo -n $1 | openssl dgst -ripemd160
printf "%-20s\t" 'CRC32:'; python -c "import binascii; print binascii.crc32('''$1''') & 0xffffffff"
 
printf "\n# Web Encodings\n"
printf "%-20s\t" 'URLQuote:'; python -c "import urllib; print urllib.quote('''$1''')"
printf "%-20s\t" 'URLEscape:'; echo "$1" | recode ..HTML
printf "%-20s\t" 'HTML HEX Entity:'; echo -n "$1" | hexdump -ve '/1 "&#x%02x;"'; echo
printf "%-20s\t" 'HTML Entity:'; echo -n "$1" | hexdump -ve '/1 "&#%02i;"'; echo
printf "%-20s\t" 'Javascript String'; echo -n "String.fromCharCode("; echo -n "$1" | hexdump -ve '/1 "%i,"' | sed 's_,$_)\n_'
printf "%-20s\t" 'SQL String'; echo -n $1 | hexdump -ve '/1 "char(%i)+"' | sed 's_+$_\n_g'
 
printf "\n# UTF Encodings\n"
printf "%-20s\t" 'UTF-7:'; echo $1 | iconv -t utf7
printf "%-20s\t" 'UTF-8:'; echo $1 | iconv -t utf8
printf "%-20s\t" 'UTF-16:'; echo $1 | iconv -t utf16
printf "%-20s\t" 'UTF-32:'; echo $1 | iconv -t utf32
printf "%-20s\t" 'Unicode:'; echo $1 | iconv -t unicode
printf "%-20s\t" 'ASCII:'; echo $1 | iconv -t ascii
 
printf "\n# Encodings\n" #http://docs.python.org/library/codecs.html#standard-encodings
printf "%-20s\t" 'Base64:'; echo -n $1 | openssl enc -e -base64
#printf "%-20s\t" 'Base64:'; python -c "import base64; print base64.b64encode('''$1''')"
printf "%-20s\t" 'Base32:'; python -c "import base64; print base64.b32encode('''$1''')"
printf "%-20s\t" 'Base16:'; python -c "import base64; print base64.b16encode('''$1''')"
#printf "%-20s\t" 'UUEncode:'; python -c "print repr('''$1'''.encode('uu_codec'))"
#printf "%-20s\t" 'UUEncode:';; echo -n $1 | hexdump -ve '/1 "#%02x"' | tr '#' '%'
printf "%-20s\t" 'UUEncode:'; python -c "import binascii; print binascii.b2a_uu('''$1''')" | tr -s '\n'
printf "%-20s\t" 'Punycode:' ; python -c "print '''$1'''.encode('punycode')"
printf "%-20s\t" 'Mime Quotable:' ; python -c "print '''$1'''.encode('quopri_codec')"
 
printf "\n# Compression Encodings\n"
#printf "%-20s\t" 'Bzip2:' ; python -c "print repr('''$1'''.encode('bz2_codec'))" | sed "s_^'\(.*\)'\$_\1_"
#printf "%-20s\t" 'Zlib (gzip):' ; python -c "print repr('''$1'''.encode('zlib_codec'))" | sed "s_^'\(.*\)'\$_\1_"
printf "%-20s\t" '7z:' ; echo -n "$1" | 7z a dummy -tgzip -si -so 2>/dev/null | hexdump -ve '/1 "%02x"'| sed "s_\(..\)_\\\x\1_g"; echo
printf "%-20s\t" 'Bzip2:' ; echo -n "$1" | bzip2 -f | hexdump -ve '/1 "%02x"'| sed "s_\(..\)_\\\x\1_g"; echo
printf "%-20s\t" 'GZip:' ; echo -n "$1" | gzip -f | hexdump -ve '/1 "%02x"'| sed "s_\(..\)_\\\x\1_g"; echo
printf "%-20s\t" 'Zip:' ; echo -n "$1" | zip 2>/dev/null | hexdump -ve '/1 "%02x"'| sed "s_\(..\)_\\\x\1_g"; echo
 
#printf "\n# OpenSSL Ciphers with empty passphrase, key and iv:\n"
#for line in `openssl enc -h 2>&1 | sed -n '/Cipher Types/,//p' | grep -v -e "Cipher Types" -e "^$" | tr -s [:space:] '\n'`; do printf "%-20s\t" "$line:"; echo -n $1 | openssl enc -k "" -e -a -p -K 0 -iv 0 "$line" | sed -n '1h;2,$H;${g;s/\n/, /g;p}'; done
 
#printf "\n# All iconv Output Encodings ~= 1153:\n"
#for line in `iconv -l`; do printf "%-20s\t" "$line"; echo -n $1 | iconv -t "$line" 2>/dev/null; echo; done

Example Run:

$ ./encode.sh '<strong>Hello World!</strong>'
 
# String Scrambles:
Normal:             	<strong>Hello World!</strong>
Reversed:           	&gt;b/&lt;!dlroW olleH&gt;b&lt;
Case Reversed:      	<strong>hELLO wORLD!</strong>
ROT13:              	Uryyb Jbeyq!
GIE:                	Svool Dliow!
Caesar:             	Khoor Zruog!
Vigenere:           	Pkpys Nsmtj!
Leet (l334):        	|-|3££0 \/\/0®£Ð!
 
# Numerical Representations:
INT:                	060098062072101108108111032087111114108100033060047098062
HEX:                	3c623e48656c6c6f20576f726c64213c2f623e
OCT:                	74142761101451541541574012715716215414441745714276
BIN:                	00111100011000100011111001001000011001010110110011011000110111100100000010101110110111101110010110110001100100001000010011110000101111011000100111110
 
# Passwords:
CRYPT w/o SALT:     	00H1EnAbbudEI
CRYPT w/ Random SALT:	/4tA4dY0Q8cJ6
DES w/ CR SALT:     	CRIFJgo.7OagA
Shadow w/o SALT:    	$1$00000000$PMrPd4yWfOkVwO2sHSqTv0
Shadow w/ RANDOM SALT:	$1$oJ0Qki6o$gNf/bXtOWA8Mi0wLa0SUp1
Apache w/o SALT:    	$apr1$00000000$XxCLeI7Ovl7HAPRfPavSe.
Apache w/ RANDOM SALT:	$apr1$Xr5GeJLw$Io1K0NZ0nvA4tClI77nyP/
LM Password:        	40033C993361335925522E685FA5299A
NTLM Password:      	E78EC9AB6886A6EADA6E61AAC053B93F
 
# Digest Hashes (newline not included):
MD5:                	26228b4d80d62285a839a475c9c7574f
MD4:                	1554d219d316077223f51c640d164ca6
MD2:                	f8057b72e7f174ef7cf80165fef67b37
SHA1:               	b44e743e733384dc8db8aa971f496ff3d22041db
SHA:                	e0053cc39e21839c3826c170b15a919d6a2c58e5
SHA224:             	08568694b48256a072ff5a1ed9e5b7ac52a0de09f93819d98e9d3188
SHA256:             	27889613b22d5c515af08ff865713664c4d53fcf9c9f7f280f6fa269177a6aac
SHA384:             	318e1f73428cb544afa1967328847fcc64a1c33d5f27319848ee203192b8b9e958c4417db4732499a848fb05107f0372
SHA512:             	fe1ab72b5677a17695134eb27f44548a0c02e4275997e364176c3adbac735ff73810a38b5674a311b97da81b16f35fa9e9618d0f02bbb0e5818cdd76b01a9dc3
RIPEMD160:          	cd47833973c967e0ff1d64b957adbaedcac2202a
CRC32:              	1574079884
 
# Web Encodings
URLQuote:           	%3Cb%3EHello%20World%21%3C/b%3E
URLEscape:          	&amp;lt;b&amp;gt;Hello World!&amp;lt;/b&amp;gt;
HTML HEX Entity:    	&lt;b&gt;Hello World!&lt;/b&gt;
HTML Entity:        	&lt;b&gt;Hello World!&lt;/b&gt;
Javascript String   	String.fromCharCode(60,98,62,72,101,108,108,111,32,87,111,114,108,100,33,60,47,98,62)
SQL String          	char(60)+char(98)+char(62)+char(72)+char(101)+char(108)+char(108)+char(111)+char(32)+char(87)+char(111)+char(114)+char(108)+char(100)+char(33)+char(60)+char(47)+char(98)+char(62)
 
# UTF Encodings
UTF-7:              	+ADw-b+AD4-Hello World+ACEAPA-/b+AD4
UTF-8:              	<strong>Hello World!</strong>
UTF-16:             	ÿþ<strong>Hello World!</strong>
UTF-32:             	ÿþ<strong>Hello World!</strong>
Unicode:            	ÿþ<strong>Hello World!</strong>
ASCII:              	<strong>Hello World!</strong>
 
# Encodings
Base64:             	PGI+SGVsbG8gV29ybGQhPC9iPg==
Base32:             	HRRD4SDFNRWG6ICXN5ZGYZBBHQXWEPQ=
Base16:             	3C623E48656C6C6F20576F726C64213C2F623E
UUEncode:           	3/&amp;(^2&amp;5L;&amp;\@5V]R;&amp;0A/"]B/@
Punycode:           	<strong>Hello World!</strong>-
Mime Quotable:      	<strong>Hello=20World!</strong>
 
# Compression Encodings
7z:                 	\x1f\x8b\x08\x00\x38\x5b\x6b\x4a\x00\x00\x01\x13\x00\xec\xff\x3c\x62\x3e\x48\x65\x6c\x6c\x6f\x20\x57\x6f\x72\x6c\x64\x21\x3c\x2f\x62\x3e\x8c\x8d\xd2\x5d\x13\x00\x00\x00
Bzip2:              	\x42\x5a\x68\x39\x31\x41\x59\x26\x53\x59\x59\x24\xfc\x0e\x00\x00\x02\x1f\x80\x60\x00\x80\x05\x00\x40\x00\x80\x16\x04\x90\x00\x20\x00\x21\xa9\xa3\x13\x68\xd0\x80\x68\x03\x0c\x3c\x90\xd3\xf8\xc2\x97\x82\x5a\x2e\xe4\x8a\x70\xa1\x20\xb2\x49\xf8\x1c
GZip:               	\x1f\x8b\x08\x00\xb8\x09\x6a\x4a\x00\x03\xb3\x49\xb2\xf3\x48\xcd\xc9\xc9\x57\x08\xcf\x2f\xca\x49\x51\xb4\xd1\x4f\xb2\x03\x00\x8c\x8d\xd2\x5d\x13\x00\x00\x00
Zip:                	\x50\x4b\x03\x04\x14\x00\x08\x00\x08\x00\xae\x62\xf8\x3a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x2d\xb3\x49\xb2\xf3\x48\xcd\xc9\xc9\x57\x08\xcf\x2f\xca\x49\x51\xb4\xd1\x4f\xb2\x03\x00\x50\x4b\x07\x08\x8c\x8d\xd2\x5d\x15\x00\x00\x00\x13\x00\x00\x00\x50\x4b\x01\x02\x17\x03\x14\x00\x08\x00\x08\x00\xae\x62\xf8\x3a\x8c\x8d\xd2\x5d\x15\x00\x00\x00\x13\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x80\x11\x00\x00\x00\x00\x2d\x50\x4b\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00\x2f\x00\x00\x00\x44\x00\x00\x00\x00\x00

Anyone else have some useful oneliner encodings that are not included here? Best post gets a cookie!

A Tale of Two Citi(bank)s

Posted on July 22, 2009 by John Abraham in Main | Leave a comment

It was the best of security, it was the worst of security. This story is not about Citibank, nor London or Paris for that matter, but two anonymous regional financial institutions that characterize an interesting aspect of security. Their IT footprints are very similar in terms of staffing capabilities, budget technology deployed, etc., yet one of them runs a remarkably secure IT environment and the other exists in the realm of insecurity.

Here, we take the opportunity to compare and contrast them to try and learn how one can be so secure with a similar set of circumstances. First, the similarities: Both have liberal IT budgets and don’t have significant constraints acquiring new technology for their data centers. Both run their own data centers internally. Both have open slots to bring in new IT staff and have a difficult time finding good talent to bring into their IT departments. Both IT departments are similar sized with about 50 people each.

What makes this so interesting is that in looking at these two IT departments, they had more similarities than differences, which is what makes the contrasts so interesting. Now, while there is a tremendous complexity in IT and no two environments can be equal (and small differences can have a big impact on security risk) it is still educational to isolate some key differences. So what was different?

After reviewing this question with some of our security team, the only significant delta was the culture of the two organizations.

The secure shop was very structured – lets call them London Bank. The reporting relationships were fairly static and IT projects were carried out in an orderly fashion. Yet in the insecure shop, lets call them Paris Bank, gear was acquired with little process to map requirements to necessary features and the initial deployments often seemed to forget about the initial needs and favor the whiz-bang extra features. Very little documentation was created for new systems and there was essentially no process for initial deployments, nor the ongoing maintenance or monitoring. There was no peer review or double checking for critical deployments and very little accountability for the quality of work. Certain individuals roamed around with a lot of critical knowledge in their heads about one-off custom configuration settings and other tid-bits about mission critical infrastructure.

So if culture is important, then we need to ask – where does culture come from?

Well, as far as we can tell, it starts from the top. We have noticed that in secure organizations, managers have both an awareness of security and a commitment to the often tedious process of secure operations. Aware and committed managers seem to recruit IT leads that share these values, who in turn bring in like-minded techies. Furthermore, it often seems the case, that all of these people are bound by a consistent vision documented in their security policies. These policies, by the way, had been created in a thoughtful way, where the importance and value of these policies were well understood… from the management on down.

ActiveX Causing More Trouble

Posted on July 13, 2009 by Nathan Drier Leave a comment

ActiveX seems to be getting some bad press once again, as its the target of recent exploits.  From SANS:

“Microsoft mentions that they are aware of active exploits against this vulnerability, although we at the SANS Internet Storm Center haven’t seen it used or mentioned in public as of yet. Which may tend to indicate it has been used in targeted rather than broad based attacks. At the moment there is no patch, there is a workaround, and it can be automated for enterprise deployment.”

The result of the exploit looks to be remote code execution with privileges of the logged-in user.  There are some quick fixes on the SANS site, but no patch from Microsoft yet.

Taking the Ethical out of Hacker

Posted on July 10, 2009 by admin 2 Comments

Security Review Site Really a Front for a Security Consulting Company?

The security space is a very interesting arena. For the customer, it’s often very difficult to separate fact from fiction in many aspects. There are security companies that sell you audits, and then sell you their “solutions”. There are security companies with flashy websites and huge marketing campaigns, only to be stocked with sub-par talent and less than average processes. There are security companies that praise their technical ability and hacker prowess, only to plug your website into a bulk vulnerability scanner and hand you output. Now, it appears that customers have yet another foggy metric to analyze:

Biased inner-industry security company reviews.

Recently, we were alerted that we are under review from a blog that “exposes” IT security providers. Due to popular demand, we were named as the next in line for review (http://secreview.blogspot.com/). Thinking something seemed a little fishy, we set off to track down some details that made us believe this review site was really a front for Netragard:

Also, check out this Google search that one of our engineers tracked down.

  • A Fox in the Henhouse. Some weeks ago, we were approached via echat from someone claiming to be a potential customer, but really turned out to be members of Netragard and Snosoft inquiring about our services. Netragard provides IT security services. Knowing that when a company in the same industry as yours comes calling and asking all about your services, its probably not because they need an audit, we were very leery about doling out any in-depth information. When you spend years refining a process that provides the best possible value to your customers, why hand it out to all your competitors?
  • No Hackers Allowed. We find part of our external IP space interestingly blacklisted from accessing www.netragard.com, aligning suspiciously with the blog posting on the Secreview site.
  • We are the Best! Interesting enough, Netragard gets the highest rank from the Secreview site. They get the only A+ (the plus must mean better) out of all the reviews. Most everyone else gets a C or below.
  • I Know your Way Home. Digging through our chat logs, we found an interesting little trail. The chatters claimed to be using a whitepaper from “one of our competitors” to ask questions regarding our services. At this point in the chat – we have a suspicious feeling that whoever is on the other end is with SnoSoft/Netragard. When asked about their relation to SS/NG – they replied:

“I’m not sure why you are asking me about snosoft/netragard other than the fact that these questions come from one of their white papers.”

  • Using the email they provided in our chat session – we got down to work. The email is referenced in a Google-indexed PDF. We search the PDF to find end notes that reference the email address to a current high-ranking employee of Netragard. We found multiple social networking accounts, all belonging to employees of SS/NG, with the same user name as the initial email.
  • I Got My Reviewing Degree Online. Even if this reviewing site was from an unbiased team, the review methodology is a little questionable. I’m not sure how you can forecast about a security company’s technical abilities by analyzing the copy on their website, but it appears to be a valid metric on the Secreview site. I’d rather see some actual, real world work from the company in question to make my decision.
  • Spikes! A nice spike in traffic from Netragard LLC IP space to the redspin.com website.

Hits

So let me ask you this, If I got to grade all my peers in my Art History class – would you believe the results? Forget the reviews you read, as the industry has apparently progressed (or regressed) to the point where reviews by “Real World Ethical Hackers” are nothing more than biased marketing shouts by false-fronts to other security companies. Why not try the following to REALLY audit the auditors:

  • Communication. If you feel dirty after talking to an auditor, chances are they aren’t for you. Call up and chat with an engineer or sales rep. They should be helpful and willing to answer your questions if you are legitimate customer.
  • References. Ask your auditor for some references, and chat up those references about the quality of work, the communication process, and the technical ability of the auditor. Nobody will give you a better review of a company than someone who paid for their work.
  • Contributions to the security community. Does your auditor do research, write relevant articles and papers, or stay on the cutting edge? Ask for education histories and recent research to be sure.
  • Objectivity. Does your auditor sell firewalls and managed services? If so, you can expect their number one finding to be that you need them. Make sure your auditor is purely objective and doesn’t try to sell you solutions.

See here for more information: http://www.redspin.com/research_eight_questions.html

In the end, it comes down to you to make the decision. Know the right questions to ask, build relationships with your vendors, and take an active part in the choices your organization makes regarding security. Stay safe, its stormy out there.

P.S. Our CEO has contacted the Secreview blog site and is waiting for a response. If anyone has experience with Secreview and wants to chat, don’t hesitate to contact us.

Sed, Grep and Awk

Posted on July 8, 2009 by The Shell Shakespear 2 Comments

Sed, Grep and Awk are true *nix tools, known for their awkward names and equally awkward syntax. They represent the most immediate access to Regular Expressions (REs) which are themselves worthy of knowledge. Even their attempted replacement, Perl, is also known producing useful yet unreadable code. Though I acknowledge their awkward natures, their usefulness cannot be ignored, and learning how to use each will aid you in your ascension to line processing supremacy. Each is best used in the following manner:

  • Grep: Matching
  • Sed: Replacing and Line Manipulation
  • Awk: Advanced Line Processing
# Insert 'Beginning' at the start of a file, and 'Ending' at the end
sed "1s/\(.*\)/Beginning\n\1/;\$a\\Ending"
 
#Escape shell metacharacters active within double quotes
sed 's/\([\\/\\`\\"$\\\\^.\\+\\{\\}]\)/\\\1/g'
 
#Replace all literal newlines with their representation '\n'
sed -e :a -e '$!N;s/\n/\\n/;ta'
 
# Filter out URL parameters
sed 's_=[^&amp;]*\(&amp;\|$\)_=\1_g'
 
# Get rid of regular expressions in a variable
sed 's:[]\[\^\$\.\*\/]:\\\\&amp;:g'`
 
#Replace last comma(,) in each line with 'and'
sed 's#\(.*\),\([^,]*\)#\1 and\2#'
 
#Match phone numbers with area code in any given format and output in format: (nnn) nnn-nnnn
# SED DOES NOT RESPECT the shorthand character classes \c\s\S\d\D\w\W
sed -e 's#[^0-9]*\([0-9]\{3\}\)[^0-9]*\([0-9]\{3\}\)[^0-9]*\([0-9]\{4\}\)#(\1) \2-\3#'
grep -o '(\?[0-9]\{3\})\? \?[0-9]\{3\}-\?[0-9]\{4\}'
 
# Match CVE Numbers
grep -o 'CVE-[0-9]\{4\}-[0-9]\{1,5\}'
 
# Match input fields with a hidden input type in an HTML file
grep -io ']*hidden[^&gt;]*&gt;' hidden.csv | sed 's#""#"#g;s#value="[^"]*"#value=""#g' | sort -u | less
 
#Parse IIS Logs for a certain IP ADDRESS (127.0.0.1)
grep 127.0.0.1 *.log | grep -v -e ".gif" -e ".jpg" -e ".ico" -e ".css" -e ".pdf" -e "404" | cut -d' ' -f2,4,5,6,10 | awk '{printf "%s %-04s http://site.com%s?%s  Ref:(%s)\n",$1,$2,$3,$4,$5}' | tr -d '-' | sed 's/Ref:()//g' | sed 's/\? //g' | awk '{printf "%s %-04s %-70s\t%s\n",$1,$2,$3,$4}'
 
#Find all links in a file
egrep -IRo '(((http(s)?|ftp|telnet|news|gopher)://|mailto:)[^\(\)&lt;\"'\''[:space:]]+)'
 
#Pretty printing fields with awk
awk -F':' '{printf "%-16s %-16s\n",$1,$2}'
 
# 'uniq' the file using only the first field
awk '!x[$1]++'
 
# uniq 3rd field in a file
awk '{ if (! third_col[$3]) print $0;  third_col[$3]++; }'
 
# Lists directories where the tree contains one or more files:
find ./ -type f | awk -F/ '{$NF=""} d[$0]++==0' OFS=/
 
# How many lines in a file that do not start with # and are not empty would fit in a tweet (140 characters)?
grep -v '^#\|^$' shell1liners.sh | awk '{if (length&lt;141) {print "Tweet("length"): " $0;}}'
grep -v '^#\|^$' shell1liners.sh | awk '{if (length&gt;140) {print "No Tweet("length"): " $0;}}'

Checking for SSL Vulnerabilities on the Command Line

Posted on July 3, 2009 by The Shell Shakespear 2 Comments

While Nessus is a wonderful vulnerability scanner, sometimes it is too slow and resource heavy for individual issues. The following 2 equivalent scripts perform checks for the following SSL related Nessus plugins:

  • 20007: SSL Version 2 (v2) Protocol Detection
  • 26928: SSL Weak Cipher Suites Supported
  • 31705: SSL Anonymous Cipher Suites Supported

The first is the curl version:

#!/bin/bash
# phaas at redspin.com: Never us a 'sh when a bash is necessary
# Checks the Equivalent of Nessus Plugin 20007, 26928 and 31705 (10863+21643)
 
if [ $# -lt 1 ]
then
  echo "List SSL Weakness present for a given website"
  echo "Usage: `basename $0` website {port}"
  exit 1
fi
web=${1-'www.redspin.com'}
port=${2-'443'}
 
# Check for the insecure SSLv2 version
curl -m1 -Ik "https://$web:$port" --ciphers sslv2 &amp;&gt; /dev/null
if [[ "$?" -eq 0 ]]; then echo -e "$web:$port: (ssl2) Weak SSLv2 encryption enabled"; fi
 
# Enumerate weak SSL ciphers using curl
IFS=$'\n' # Loop across lines, rather than words
ciphers='LOW:EXP:eNULL:aNULL' # Include EXP (Export Ciphers)
for line in `openssl ciphers -v $ciphers | tr -s ' '`; do
	version=`echo "$line" | cut -d' ' -f2 | tr [:upper:] [:lower:]`
	cipher=`echo "$line" | cut -d' ' -f1`
	auth=`echo "$line" | tr -s ' ' | grep -o "Au=[^ ]*" | cut -d'=' -f2`
	strength=`echo "$line" | sed 's#Kx=[^ ]*##' | grep -o '([0-9]*)' | tr -d '()' | grep -v 'None'`
	if [[ "$auth" == 'None' ]]; then auth="no"; fi
	if [[ -z "$strength" ]]; then strength="without encryption"; else strength="at $strength bit encryption"; fi
 
	#echo "curl -m1 -Ik https://$web:$port --ciphers $cipher -$version &amp;&gt; /dev/null"
	curl -m1 -Ik "https://$web:$port" --ciphers "$cipher" -$version &amp;&gt; /dev/null
	if [[ "$?" -eq 0 ]]; then
		echo -e "$web:$port: ($version) $cipher = Supported $strength with $auth authentication support"
	fi
done

And the following is the openssl version:

#!/bin/bash
# phaas at redspin.com: Never us a 'sh when a bash is necessary
# Checks the Equivalent of Nessus Plugin 20007, 26928 and 31705 (10863+21643)
 
if [ $# -lt 1 ]
then
  echo "List SSL Weakness present for a given website"
  echo "Usage: `basename $0` website {port}"
  exit 1
fi
web=${1-'www.redspin.com'}
port=${2-'443'}
 
# Check for the insecure SSLv2 version
sslv2=`echo -e '' | openssl s_client -connect $web:$port -ssl2 -no_ssl3 -no_tls1 2&gt;/dev/null | grep -i 'SSLv2'`
if [ -n "$sslv2" ]; then echo -e "$web:$port: (ssl2) Weak SSLv2 encryption enabled"; fi
 
# Enumerate weak SSL ciphers using openssl
IFS=$'\n' # Loop across lines, rather than words
ciphers='LOW:EXP:eNULL:aNULL' # Include EXP (Export Ciphers)
for line in `openssl ciphers -v $ciphers | tr -s ' '`; do
	version=`echo "$line" | cut -d' ' -f2 | tr [:upper:] [:lower:] | tr -d 'v'`
	cipher=`echo "$line" | cut -d' ' -f1`
	auth=`echo "$line" | tr -s ' ' | grep -o "Au=[^ ]*" | cut -d'=' -f2`
	strength=`echo "$line" | sed 's#Kx=[^ ]*##' | grep -o '([0-9]*)' | tr -d '()' | grep -v 'None'`
 
	if [[ "$auth" == 'None' ]]; then auth="no"; fi
	if [[ -z "$strength" ]]; then strength="without encryption"; else strength="at $strength bit encryption"; fi
 
	#echo "openssl s_client -connect $web:$port -$version -cipher $cipher"
	supported=`echo "" | openssl s_client -connect $web:$port -$version -cipher $cipher 2&gt;&amp;1 | grep DONE`
	if [[ -n "$supported" ]]; then
		echo -e "$web:$port: ($version) $cipher = Supported $strength with $auth authentication support"
	fi
done

I decided to include both because while openssl is usually included by default on most Linux distributions, curl is easier to obtain on Windows machines.

« Previous   1 2 ... 16 17 18 19 20 21   Next »