SANS Pen Test Poster: Pivots Payloads Boardgame

 

We are excited to introduce to you the new SANS Penetration Testing Educational Poster, “Pivots & Payloads Board Game”! It is a poster and a board game. How is it a board game? You can lay it down on a table, cut out the game pieces and game modifiers, use a dice to move your piece around the board…and play with your friends, colleagues, and/or family.

The board game takes you through pen test methodology, tactics, and tools with many possible setbacks that defenders can utilize to hinder forward progress for a pen tester or attacker. The game helps you learn while you play. It’s also a great way to showcase to others what pen testers do and how they do it.

We have made the poster/board game available to download, with additional downloads of the cheat sheets, game pieces, and game modifiers. We will add additional content to this blog page as we continue to evolve the board game and improve on it in future versions.

Download PDF of Pivots & Payloads:

http://blogs.sans.org/pen-testing/files/2018/11/PEN-PR-BGP_v1_1018_WEB_11052018.pdf

PEN-PR-BGP_v1_1018_WEB_FINAL_11052018_web_front

PEN-PR-BGP_v1_1018_WEB_FINAL_11052018_web_back

Additional Pivots & Payloads:

Desktop Wallpaper

PEN-PR-BGP_v1_1018_wallaperV1

PEN-PR-BGP_v1_1018_wallaperV2

Game Pieces – Print PDF

Pieces

Cheat Sheets – Print PDF

HashCat

Recon

NetCat

Pen Test Cheat Sheets:

SANS Pen Test Training:

SANS Pen Test Posters:

Build your Skills (Free):

SANS Penetration Testing Webcasts (YouTube):

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

What’s the Deal with Mobile Device Passcodes and Biometrics? (Part 2 of 2)

By Lee Neely

In the first installment of this 2-parter, I discussed  the use of mobile device  fingerprint scanners to unlock the device.  As a follow-up, I’d like to discuss how a developer can integrate the scanner into their applications.  This discussion may provide some insights into how to secure mobile apps, or even inspire some hacking ideas (this is a pen test related blog, after all).  At the end of the article below, I’ll discuss some ideas for compromising this type of environment.

In part one, I introduced the secure environment used to manage fingerprints. This environment is called by a couple of names. Most commonly it’s called the Trusted Execution Environment (TEE) and Secure Enclave. In both cases, the terms describe a separate environment consisting of hardware and software, which performs specific tasks relating to managing and validating trusted information, isolated from the primary device applications and operating system.

Background

Global Platform, an international standards organization, has developed a set of standards for the TEE’s APIs and security services. These were published in 2010 and the corresponding APIs between the Trusted Application and Trusted OS was completed in 2011. The image below, from www.arm.com, describes the TrustZone standard.Blog 1

With this published, we saw the introduction of implementations from Apple and Samsung using a secure micro-kernel on their application coprocessor. A TrustZone enabled processor allows for hardware isolation of secure operations. Rooting or Jailbreaking the device Operating System does not impact the secure micro-kernel.

Both platforms are using the same paradigm. There is now a Normal World (NW) and Secure World (SW) with APIs for NW applications to access information in the SW. In both cases the Fingerprint Reader/Scanner is connected to the SW, so the fingerprint scan itself cannot be accessed by NW applications. Both platforms have API calls that mask the details of the implementation from an application developer, making it simple to incorporate this technology into applications.

Apple Implementation Details

Apple introduced their Secure Enclave when they released the iPhone 5S which included Touch ID and their A7 processor. Apple creates a Secure Enclave using encrypted memory and includes a hardware random number generator, and a micro-kernel based on the L4 family with modifications by Apple. The Secure Enclave is created during the manufacturing process with its own Unique ID (UID) that reportedly not even Apple knows. At device startup, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory. Secure Enclave data written to the file system is encrypted with a key that is entangled with the UID and an anti-replay counter. During device startup, the Secure Enclave coprocessor also uses a secure boot process to ensure the software is verified and signed by Apple. In the event the Secure Enclave integrity cannot be verified, the device enters device firmware upgrade (DFU) mode and you have to restore the device to factory default settings.

Using Touch ID with applications:

Third-party apps can use system-provided APIs to ask the user to authenticate using Touch ID or a passcode. The app is only notified as to whether the authentication was successful; it cannot access Touch ID or the data associated with the enrolled fingerprint.

Keychain items can also be protected with Touch ID, to be released by the Secured Enclave only by a fingerprint match or the device passcode. App developers also have APIs to verify that a passcode has been set by the user and therefore able to authenticate or unlock keychain items using Touch ID.

Apple APIs

After all that, it may seem like it’s hard to make a call to Touch ID for authentication. Apple is now publishing sample code and API documentation through the Apple iOS Developer Library. Note: Downloading the iOS SDK requires an Apple Developer Program membership.

This code sample Local Authentication Framework from Apple’s iOS Developer Library makes it pretty simple to add a Touch ID authentication prompt to an application:

 

Blog 2.2

Samsung Implementation Details

Samsung introduced their Trusted Execution Environment in the Galaxy SIII. Samsung uses a micro-kernel named Mobicore.  Developed by Giesecke & Devrient GmbH (G&D), it uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the “rich” operating system of the device. This isolation creates the TEE. Secure applications that run inside Mobicore are called trustlets. Applications communicate with trustlets through the Mobicore library, service and device drivers.

While third-party application developers can create their own trustlets, they need to be incorporated into Mobicore by G&D.

The following figure published by G&D demonstrates Mobicore’s architecture:

Blog 2

Using Samsung Fingerprint Scanner with applications:

Samsung’s fingerprint scanner can be used with Web sign-in and verification of a Samsung account. Additionally, it will be incorporated into the authorization process for the new Samsung Pay application.

Applications workflow for Fingerprint Authorization is as follows:

  1. User opens app (that uses fingerprint)
  2. User goes to authorize something (such as payment)
  3. App launches fingerprint Trustlet
  4. Secure screen takes over and provides UI for reading fingerprint
  5. Fingerprint scanner accepts input
  6. Trustlet verifies fingerprint by comparing it to stored scan data from registration and provides authorization back to App
  7. Authorization is completed

Samsung API

To access fingerprints on Samsung, you need to use the Pass SDK. It works with both the Swipe (S5, Note 4) and Touch (S6) sensor. The Pass SDK provides for not only checking a fingerprint but also has mechanisms to add, check, and even throw a handled exception in the event your application is run on a device that doesn’t support a fingerprint scanner.

Sample code from the Pass SDK to authenticate with a fingerprint:

Blog 3

Compromising

So now you know how the architecture works, and how to access it, the question becomes how can this be compromised? What are the risks?

The first option is to directly attack the fingerprint database. The FireEye team found HTC was storing the fingerprint database as a world-readable world-writable file, which means that any application could read or modify the contents. Reports of patches have been issued to address this.

The second option is to interfere with the communication between the fingerprint reader and the SW. If you could attach a process to that device, you could make your own collection of fingerprints accessing the device, or even more insidiously, insert your own fingerprint into the legitimate fingerprint database. Again, the FireEye team found cases where this was possible and the vendors issued patches.

The third option is to modify the device driver that’s between the NW and SW portions of the device. Potentially altering the behavior of the fingerprint scan checks to always return true. Other data, which is uniquely stored in the SW, cannot so easily be faked so there are limits to how successful this would be. As luck would have it, another presentation at Black Hat 2015 found an exploit.

Di Shen’s presentation from BH-15 shows how an insecure implementation of the TEE OS and driver in the Huawei devices with the Huawie HiSilicon chipset can be used to alter trusted memory, injecting shell code, accessing fingerprint data, and otherwise compromising the TEE. These compromises do require kernel (rooted) access to be successful.

A common thread in addressing these weaknesses is patches or updates. Android users have had a struggle getting these updates consistently and in a timely fashion. On August 5th, Google announced monthly Over the Air (OTA) security updates for their Nexus devices and Samsung announced a fast track OTA security update process. Samsung is negotiating with mobile operators worldwide to insure the process will be successful. With luck, other device manufacturers will follow suit. An important thing to note is the backward compatibility of the updates. Typically Android devices only have updates for eighteen months, if at all. By contrast, Apple iOS 8.4.1 is still supported on the four-year-old iPhone 4s. Once a platform with updates is chosen, it is still necessary to check for and apply the updates that are distributed.

To stay informed about security updates, subscribe to data feeds that carry announcements of updates and fixes. Google recently created an Android Security Updates Google Group. Apple announces their updates through their security page and security-announce mailing list.

Summary

When considering the use of biometrics either for device or application authentication, a risk-based decision has to be made, as with any external authentication service, whether to trust it. Fingerprint readers are still subject to bypass techniques as were described in part one. The simplest mitigation is to rely on device and application integrity checks which must pass prior to allowing the external authentication to either be enabled or succeed. Additionally, being aware of the physical security of the mobile device is paramount. Protect it like you would protect your wallet.

If the risk is acceptable, users are again provided with an authentication mechanism that cannot be merely observed to circumvent. The authentication information itself is securely stored, the application verifies it via calls through a secure API designed to detect tampering, and the application is no longer managing passwords.

One advantage an application developer has is they may elect to have layered authentication. If the target is a corporate application, working with the mobile device administration team to ensure a device level passcode is also configured would then ensure two levels of authentication prior to allowing access to your application.

One more option an application developer has is to require added authentication, within the application, prior to allowing access. Perhaps, that might be a PIN plus a Fingerprint. While this is appealing from a security perspective, from an end-user perspective this may be a tough option to accept.

Conclusion

In short, adding support for biometric authentication has a nominal impact and, as such, making a pitch for using it when developing applications should be an easy option for management to accept. I suggest seriously considering it for your next mobile application development project.

-Lee Neely

Want to learn more on this topic? You really should check out SEC575: Mobile Device Security and Ethical Hacking, an amazing course covering mobile device security, attacks, and much more!

References:
Apple iOS Security Guide: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Brute Force Android PIN:
http://www.brotherton.com/main/androidpinbruteforce

Samsung Fingerprint 4.4: http://www.samsung.com/us/support/howtoguide/N0000011/16610/225807

Samsung S5 Fingerprint Hacked:
http://www.tomsguide.com/us/samsung-galaxy-s5-fingerprint-hack,news-18655.html

https://www.pentestpartners.com/blog/brute-forcing-android-pins-or-why-you-should-never-enable-adb-part-2/

Samsung/Apple face-off:
http://www.cio.com/article/2454883/consumer-technology/fingerprint-faceoff-apple-touch-id-vs-samsung-finger-scanner.html

Improvements to iPhone 6 Fingerprint scanner:
http://9to5mac.com/2014/09/24/hack-test-shows-apple-improved-security-and-reliability-of-still-not-perfect-touch-id-sensor-in-iphone-6/

CCC how-to make a fake fingerprint: http://dasalte.ccc.de/biometrie/fingeradbdruck_kopieren.en

FAR/FRR Graph: http://www.securitysales.com/article/knowing-how-biometrics-can-be-beaten-helps-you-win

Entrust Blog:
http://www.entrust.com/bypassing-fingerprint-biometrics-nothing-new/

iOS Authenticate with Touch ID: https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/

Samsung Pass SDK:
http://developer.samsung.com/galaxy#pass

Samsung KNOX Security Overview: https://www.samsungknox.com/en/system/files/whitepaper/files/An%20Overview%20of%20the%20Samsung%20KNOX%20Platform_V1.11.pdf

MobiCore description:
https://www.sensepost.com/blog/2013/a-software-level-analysis-of-trustzone-os-and-trustlets-in-samsung-galaxy-phone/

BlackHat Presentation:
https://t.co/GblBcEN9a4

https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf

http://www.theregister.co.uk/2015/08/10/htc_caught_storing_fingerprints_as_worldreadable_cleartext/?mt=1439215037342

Attack TrustZone:
https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Attacking-Your-Trusted-Core-Exploiting-Trustzone-On-Android-wp.pdf

 

 

What’s the Deal with Mobile Device Passcodes and Biometrics? (Part 1 of 2)

By Lee Neely

Introduction

Mobile device administrators and end users need to be more cognizant of the risks of allowing unauthorized access to their smartphones and take steps to raise the bar on accessing those devices to mitigate those risks.

This is part one of two articles on securing mobile device access. In this article, I am going to focus on securing access to the physical device itself. In part two, I will discuss on-device security APIs and how one would know they are still in place.

The case for a strong passcode

When the first smartphones were introduced, they were corporate owned, managed, and secured to business standards. Device access was on par with accessing corporate laptop systems. The number, variety, and quantity of applications and personal or sensitive information stored on the device was far less than we see in modern   iOS, Android, Windows Mobile, and other devices. While there were some devices owned and managed by end users, it was not as significant as it is today. The seminal events that tie to explosion of content, applications, data and personal use are the introduction of the iPhone in 2007 and Android in 2008. With this change of use, device administrators, and end users, we now need to worry about access to the information on their smartphone, and usually have less control over the device.

When the first iPhone lock-screen bypass “bug” was announced in 2008, I found the reaction was unexpectedly blasé. Further research indicated, at that time, that the majority of users weren’t setting a passcode any way, so there was no lock screen to bypass. A 2014 survey by Consumer Reports found that while 47% of users surveyed were setting a passcode, gesture or other mechanism to lock the device screen, 77% of those users were only using a four digit PIN. Further, users were unlikely to do anything more, such as configuring an automatic wipe after a specified number of passcode failures. Observation indicates that while setting a passcode is becoming more standard, a four-digit PIN remains the de-facto setting chosen by users.

While the use of a passcode is better than a device that has no screen lock, a four digit PIN is relatively simple to bypass using one of the following techniques:

  • Observing the numbers used:
    • SANS instructor Chris Crowley has found that he can reliably observe the numbers used in a four digit PIN from across a room, quite a feat but not at all implausible.
  • Finding a likely four-digit PIN
    • Searching social media, phone directories, and other on-line sources for four digit numbers of significance to the given user.
    • Users typically pick passcodes that are easy to recall, such as a birth or anniversary date, home address or a simple pattern, such as 1111, four corners, etc.  For more on the most common PINS, check out   http://www.datagenetics.com/blog/september32012/
  • Brute force:
    • Devices that connect to an iOS device, such as an IP-Box, can try all 10,000 four digit PINs in about 17 hours.
      • Users often don’t configure the device to wipe after ten failed passcode attempts. Additionally, there were several scenarios prior to iOS 8.3 that allow the device wipe on ten failed attempts to be bypassed.
    • Devices that connect to an Android, such as a  USB Rubber Ducky  (using a USB OTG cable) can try all 10,000 four digit PINs in about 16 hours.
      • Default behavior on the Android is forcing a 30 second pause after five failed passcode attempts, so the brute force tools simply pause as well.

The argument for stronger authentication

So, as the four digit PIN can be compromised, and with the current uses including email, shopping, banking, payment, contacts, notes, and social media applications, many configured to login as the owner without prompting for additional credentials, the need for a strong device passcode becomes increasingly more important.

The need for a strong passcode to access their smartphone and all the potentially sensitive information on it is not hard for users to understand. Yet, device administrators don’t get support when they suggest strong passcodes. My experience is most users get stuck on the idea of using, and more specifically entering, a complex password on this device they have significant personal interaction with and control of. I have found that if using more secure options is too difficult for users, they will find ways to use simpler, less secure ways to get the job done. Entering a long, complex passcode, every time they want to use their smartphone, is not something that is done quickly and easily; an alternate secure authentication mechanism is needed.

A mentor once told me “We hire the smartest people on the planet to solve problems; don’t be a problem they solve.”

Biometrics

Enter biometric authentication: authentication based on some intrinsic characteristic of the user. Biometrics used for authentication include fingerprints, retina scans, face recognition and voice prints. Enabling biometric authentication can offset the impact of requiring a strong passcode, a win for device administrators and users. While also reducing the times where a passcode can be observed and subsequently entered.

When the Android OS 4.1 was introduced, an option appeared to allow the smartphone to unlock when it saw the configured user’s face. The big challenge with that option is a photo of the users face would work as well as the real face. Updates were made to require the user to blink their eyes as a differentiation from a photograph. This option generally means that the device camera is on and watching full time, which may not always be appropriate or desirable. I recommend disabling this option.

Another popular form of biometric authentication has emerged, namely fingerprint readers (queue bionic sound-effect from the Six Million Dollar Man television series). These appear in one of two styles, a finger press or finger swipe. The finger press style has seen a large degree of user acceptance because it is easier to use than either a finger swipe or passcode entry and has fewer false rejections.

While biometric authentication is not free from issues, it has removed most of the situations where a user has to enter the passcode; and therefore is seeing increased adoption and acceptance.

Biometric Sensitivity

It is important to remember that regardless of the biometric system used, if it determines that the user is not who they claim to be, they will need to enter the device passcode. Vendors work hard to adjust the False Accept Rate (FAR) and False Reject Rate (FRR) to ensure that fake users are turned away and genuine users are able to authenticate. The Crossover Error Rate (CER) is the rate at which the FRR and FAR are equal, and sometimes called sensitivity or the Equal Error Rate (EER.) The graph below illustrates this phenomenon. When the vendor delivers a product that operates with a good CER, user acceptance is high, and widespread adoption is possible.
Blog 1

Why focus on Android/iOS?

According to data from International Data Corporation (IDC) in Q4 of 2014, 96% of the worldwide smartphone market is comprised of Android and iOS devices. Given the substantial margin over other options, I am going to focus on iOS and Android device solutions.

Blog2

Current Solutions

The iPhone 5s and Samsung Galaxy S5 both introduced fingerprint readers to enable biometric authentication. In both cases, groups such as The Chaos Computer Club (CCC) devised mechanisms for creating a fake fingerprint that would unlock the device.  Joshua Wright, author of the SANS Institute SEC575 course on Mobile Device Security and Ethical Hacking,  illustrates the CCC process for creating a fake fingerprint to trick Touch ID, as shown in the course except below. A similar process can be used against Samsung devices. With the introduction of the iPhone 6 and Samsung Galaxy S6, the sensitivity of the readers has increased, meaning marginal fake fingerprints will no longer work, and at times it may pick up the fingerprint behind the fake, again causing the fingerprint to be rejected. This change in sensitivity also means some legitimate fingerprints will be rejected.

Blog3

Protection of Biometric information

One of the most important security measures in biometric authentication is protection of the biometric information. In both Samsung and Apple implementations, the fingerprint scan is not actually stored. Instead, a mathematical representation of the fingerprint is made which is then stored in a secure location on the device that is not replicated to the cloud or backups. This is of critical importance since, unlike passwords, fingerprints cannot be simply changed if they are compromised.

Samsung Fingerprint Scan Data Security

Samsung devices use a trusted execution environment to protect fingerprint data. Per Samsung, the fingerprint framework works as follows:

  • Actual fingerprints or biometric data is not stored. A hash is created from the scan and the resulting hash is stored in Trustzone which is the ARM architecture TEE (Trusted Execution Environment)
  • Fingerprint scanner & UI are in TEE
  • Fingerprints cannot be accessed outside the TEE
  • Fingerprint scanner hardware cannot be accessed outside TEE
  • Scanner is connected such that only TEE can access it physically
  • TEE takes over display to show trusted UI for input
  • Fingerprint data is not accessible outside TEE
  • Trustlet provides results of scan, possibly some key protected by successful scan, but no scan information

Apple Touch ID Fingerprint Data Security

On Apple iOS devices, fingerprint representations are stored in the Secure Enclave. The Secure Enclave is a co-processor with its own boot and update processes, as well as encrypted memory with a unique key that is assigned during fabrication. The Secure Enclave maintains the security of the data contained within it, even if the main kernel is compromised. Apple provides limited System APIs for applications that wish to use Touch ID for authentication, restricting access to how the fingerprint reader is used.

Biometric Impacts on Daily Use

Using Biometric authentication has impacts, both good and bad, on how users access their devices and on privacy.

While the fingerprint readers appear to eliminate the need to enter the device passcode, there are still a few times you need to enter it. Here is a comparison of where Touch ID and Samsung’s Fingerprint Scanner still require the password:

Scenario Apple Touch ID Samsung Fingerprint Scanner
Reboot/Power Cycle Must Enter Only required if on device encryption enabled
Idle more than 48 hours Must Enter Can still use fingerprint
After five unsuccessful attempts to match a fingerprint Must Enter Must Enter. This is new with Samsung’s S6.Previously, no limit was set.
Enrolling/managing fingerprints Must Enter. Must have passcode prior to enrolling. Maximum five fingerprints stored Either may be used. Must have a minimum of six character “Backup Password”, including one digit and one number configured. Maximum four fingerprints stored
Device receives a remote lock command Must Enter Passcode Must use configured lock password. Note remote lock changes the screen lock to password instead of fingerprint.

Device administrators and users should consider the table above when debating the use of biometrics in conjunction with strong passcodes.

Beyond the fingerprint replication threats publicized by CCC, using fingerprint authentication also introduces privacy concerns for some users. For example, Law Enforcement Agencies (LEA) can compel a suspect to turn over “something you have”, but the restrictions for turning over “something you know” are more difficult. Applied to biometric authentication, LEA can compel you to unlock your phone with a fingerprint, but do not have the US legal authority to compel you to reveal a PIN or password used to lock a device

If the stored fingerprint is connected to Apple Pay, PayPal, or Samsung Pay on your mobile device, potential impacts of using a fake fingerprint are increased.

Peace of Mind – Practical Recommendations

It is important to remember that creating a fake fingerprint takes time, resources, and skills. This means the chances of an attacker  or street thief getting into a user’s device before they or the device administrator have had a chance to remotely wipe it are low. Additionally, the device is protected by a strong passcode that can’t be easily guessed, falling back to compromising the device passcode is also non-trivial.

Other things that must be done:

Enable on-device encryption on Android devices. (This is always on for iOS devices.) This ensures the data on the device cannot be retrieved by merely dumping the NVRAM to another computer for analysis or use.

In addition to any corporate Mobile Device Management (MDM) solution in use, verify the device is setup for either Find My iPhone  or Android Device Manager. This gives the users the ability to remotely locate, ring, lock and/or wipe their device in the event something happens.

Configure the device to wipe after a pre-set number of failed passcodes. Don’t give bad guys unlimited license to try passcodes. Device administrators should set this number high enough to account for difficulties entering a passcode so as to avoid accidental data wiping. I suggest ten. If that is an unacceptable risk, set it to no lower than five.

Lastly, regardless of using a passcode, fingerprint, or any other authentication mechanism, physical possession of the device is always important. Train users to treat their smartphone as they would their wallet: don’t leave it where others can easily take it and use caution revealing authentication mechanism details.

Conclusion for Part 1

Following these recommendations, access to a user’s device and the corresponding sensitive information on it become much harder. Further, shoulder surfing a fingerprint read and then replicating it to access a device are much harder than simply capturing the PIN or password a user is entering.

Raising the bar on accessing the sensitive information on mobile devices, particularly as we find more places they enable actions and protect a greater amount of our personal information, helps us be a little more certain about who has access to that information. But, this approach also raises the question of how else these security mechanisms could be used.

Part 2

In part two, we will talk about how applications access fingerprint data, how the security of those APIs are maintained, and how one would know they were still in place.

-Lee Neely

Want to learn more on this topic? You really should check out SEC575: Mobile Device Security and Ethical Hacking, an amazing course covering mobile device security, attacks, and much more!

 

 

Ever Crack a Password using a Cisco Device?*

[Editor’s Note: Here’s a short but sweet article by Tim Medin on using Cisco IOS’s own capabilities for decoding Type 7 passwords.  Now, you might think — “Why don’t I just use one of the conversion websites on the Internet for decoding that?”  Or, “I know a free  downloadable hacker tool that does just that.”  But, in some environments, taking sensitive passwords from devices and pasting them into free web-based tools or even downloaded computer attack tools is a BIG HUGE no-no, as you may be leaking some sensitive info to places you shouldn’t be.  Tim’s technique lets you use the router itself to decode the password.  Simple, fun, and effective.  Thanks, Tim!  –Ed.]

If you’ve done penetation testing for a while, you probably already know that the Cisco Type 7 password is easily reversible. The password is encrypted (not hashed) using the Vigenère cipher, which dates to 16th century. Moreover, the static key is known to the world (it’s dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87, if you are wondering.  You can memorize that if you want and impress your friends at the next Hacker Jeopardy event you attend).

There are plenty of tools to reverse this password, but who needs them when you have a Cisco device handy. Yes, you can reverse the password right on the Cisco device!  Lemme show you how.

If we have the encrypted value of 0539030E2D405725490B10220A1F173D24362C72 here are the commands to decrypt the password on your Cisco device:

cisco# conf t
cisco(config)# key chain thisisatest
cisco(config-keychain)# key 1
cisco(config-keychain)# key-string 7 0539030E2D405725490B10220A1F173D24362C72
cisco(config-keychain)# ctrl+z
cisco# show key chain
Key-chain thisisatest:
    key 1 -- text "ReallyL0ngPassword!"

We start by entering configuration mode via “conf t” (short for configure terminal). We then create a new key chain named “thisistest” (the name doesn’t matter). We then tell the device that we are providing a key-string and that it is a type 7 password. Finally, exit configuration mode with ctrl+z and display the key chain. Boom, the password is ReallyL0ngPassword!.

Since you were likely not born in a barn, and your mom doesn’t work here, you should clean up after yourself. To do this simply enter back into configuration mode and remove the keychain with the “no” prefix to the command.

cisco# conf t
cisco(config)# no key chain thisisatest
cisco(config-keychain)# ctrl+z

Super easy, and you don’t have to download a tool or expose the password to some random site on the internet.

*For pedantic people: No, it isn’t technically cracking, but the title of “Have you ever decrypted terrible, 1500s era enciphered passwords on a Cisco Systems, Inc.** network device?” would have been terrible.

** Cisco® and Cisco Systems, Inc® are registrered trademarks registered trademarks in the United States and certain other countries.***

*** Yes, Canada is another country. I learned that when I went through Canadian customs.****

**** Never tell a customs agent, “You take this whole other country thing very seriously, huh?”

Join me for SEC560: Network Penetration Testing and Ethical Hacking at
SANS Boston 2013!  Boston, MA on Monday, Aug 5 – Saturday, Aug 10, 2013 or
SANS Golden Gate 2013  San Francisco, CA on Dec 16, 2013 – Dec 21, 2013.

–Tim Medin
Counter Hack

SMB Relay Demystified and NTLMv2 Pwnage with Python

By Mark Baggett

[Editor’s Note: In this _excellent_ article, Mark Baggett explains in detail how the very powerful SMBRelay attack works and offers tips for how penetration testers can operationalize around it.  And, bet yet, about 2/3rds of the way in, Mark shows how you can use a Python module to perform these attacks in an environment that uses only NTLMv2, a more secure Windows authentication mechanism.  Really good stuff!  –Ed.]

The SMB Relay attack is one of those awesome tactics that really helps penetration testers demonstrate significant risk in a target organization; it is reliable, effective, and almost always works.  Even when the organization has good patch management practices, the SMB Relay attack can still get you access to critical assets.  Most networks have several automated systems that connect to all the hosts on the network to perform various management tasks.  For example, software inventory systems, antivirus updates, nightly backups, software updates and patch management, desktop backups, event log collectors, and other processes will routinely connect to every host on the network, login with administrative credentials and perform some management function.

In some organizations, active defense systems such as Antivirus Rogue host detection will immediately attempt to login to any host that shows up on the network.  These systems will typically try long lists of administrative usernames and passwords as they try to gain access to the unknown host that has mysteriously appeared on the network.  SMB Relay attacks allow us to grab these authentication attempts and use them to access systems on the network.  In a way, SMB Relays are the network version of Pass the Hash attacks (which Ed Skoudis described briefly in the context of psexec in his Pen Tester’s Pledge article).  Let’s look at how these attacks work.

NTLM is a challenge/response protocol.  The authentication happens something like this:  First, the client attempts to login and the server responds with a challenge.  In effect the server says, “If you are who you say you are, then encrypt this thing (Challenge X) with your hash.”   Next, the client encrypts the challenge and sends back the encrypted challenge response.  The server then attempts to decrypt that encrypted challenge response with the user’s password hash.  If it decrypts to reveal the challenge that it sent, then the user is authenticated.  Here is an illustration of a challenge/response authentication.

With SMB Relay attacks, the attacker inserts himself into the middle of that exchange.     The attacker selects the target server he wants to authenticate to and then the attacker waits for someone on the network to authenticate to his machine.  This is where rogue host detection, vulnerability scanners, and administrator scripts that automatically authenticate to hosts become a penetration tester’s best friends.  When the automated process connects to the attacker, he passes the authentication attempt off to his target (another system on the network, perhaps a server).   The target generates a challenge and sends it back to the attacker.  The attacker sends the challenge back to the originating scanning system.  The scanning system encrypts the hash with the correct password hash and sends it to the attacker.  The attacker passes the correctly encrypted response back to his target and successfully authenticates.  This process is shown in the next illustration.  The BLUE arrows are the original communications and the RED arrows are slightly modified versions of those communications that the attacker is relaying to his target, so that he can gain access to it.

Although this may seem complicated, it is actually very easy to exploit. In this example, the attacker (let’s say he’s at IP address 10.10.12.10) wants to gain access to the server at the IP address 10.10.12.20 (perhaps a juicy file server). There is a nightly software inventory process on the server at 10.10.12.19 that inventories all the hosts on the network.

 Scenario

Attacker IP – 10.10.12.10
Target IP – 10.10.12.20
Nightly Inventory Scanner IP – 10.10.12.19

Metasploit has an SMB Relay Module and it works wonderfully.   The attacker at 10.10.12.10 sets up Metasploit as follows:

I’ll use a simple Windows FOR loop to simulate an administrative server scanning the network and doing inventory.  On host 10.10.12.19 I run the following command.

When the scanner (10.10.12.19) connects to 10.10.12.10 (our Metasploit listener) the authentication attempt is relayed to the target server (10.10.12.20).  The relayed authentication happens like magic and Metasploit automatically uses the authenticated SMB session to launch the meterpreter payload on the target.  Notice in the figure below that Metasploit sends an “Access Denied” back to the inventory scanner when it attempted to connect to 10.10.12.10.  However, the damage is done and we get a Meterpreter shell on the attacker’s machine running on the target (10.10.12.20).

Today, Metasploit’s SMB Relay only supports NTLMv1, so organizations can protect themselves from this attack by changing the AD policy from this setting (available in secpol.msc) …

To this…

After we make the change to NTLMv2, we try Metasploit again.

Now when we run the exploit, Metasploit gets a “Failed to authenticate” error message.  DRAT, our dastardly plan has been foiled by modern security protocols.  Metasploit has support for NTLMv2 in other exploits such as http_ntlmrelay, so I imagine this exploit will eventually support NTLMv2.

But, don’t worry.  We’ve got you covered.  Until then, it is PYTHON TO THE RESCUE!    Two weeks ago, I showed you psexec.py in my blog post about using a Python version of psexec at http://pen-testing.sans.org/blog/2013/03/27/psexec-python-rocks)  It is a Python implementation of psexec that is distributed with the IMPACKET modules.  The team writing the IMPACKET module for Python is doing some really awesome work.  First of all, the modules they have written are awesome.  Beyond that, they have created several example programs that demonstrate the power of their Python modules.  Best of all, the SMBRELAYX.PY script that comes with IMPACKET supports NTLMv2!  Sweetness, thy name is IMPACKET!

Getting the script running will take a little bit of work.  You’ll need to download the latest version of IMPACKET and fix the module paths to get it up and running.  To fix this, I put all of the examples in the same directory as the other modules and then change the import statements to reflect the correct directories.   SMBRELAYX needs an executable to run on the remote host after it authenticates.  What could be better than the meterpreter?  Let’s use msfpayload to create a Meterpreter EXE and then setup SMBRELAYX.   Smbrelayx.py requires two parameters: -h is the host you are going to attack and -e is the process to launch on the remote host.  You just provide those options and sit back and wait for that inventory scanner to connect to your system.  Below, I show msfpayload creating the Meterpreter executable, and the invocation of smbrelayx.py:

Because we are using a meterpreter reverse shell, we also have to setup Metasploit so that it is ready to receive the payload connection after it executes on the target.  That is what the multi/handler exploit is for, as shown below:

Now, I’ll simulate the scanner by attempting to connect to the C$ of our attacker’s Linux box (10.10.12.10) from the scanner server (10.10.12.19).

Instead of getting back an “Access Denied” like we did from Metasploit, we get back a “System cannot find the path specified” error.  I like this error message.  I think a system admin might question why his username and password didn’t work on a target before he would question why the path doesn’t exist.  The smbrelayx.py script’s message back to the admin seems therefore more subtle than the Metasploit message and less likely to get noticed.  Immediately we see the relay occur in the Python script.  It authenticates to 10.10.12.20 and launches the meterpreter process as a service using the username and password provided by 10.10.12.19.

The payload is delivered to the target after authenticating over NTLMv2 and meterpreter is launched on the target.  To keep our shell, we need to quickly migrate to another more stable process (to help automate that migration, we could use one of the migration scripts available for the meterpreter).

Ah, the delicious smell of a brand new meterpreter shell.  And of course, because it is a Python module, you can incorporate this script into your own automated attack tools.

Learn about GIAC’s new Python Coder certification
GPYCwww.giac.org/gpyc 

Thank you!

–Mark Baggett

 

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

A Penetration Tester’s Pledge

by Ed Skoudis

Over the weekend, I was thinking about the wonderful psexec capabilities of tools like Metasploit, the Nmap Scripting engine smb-psexec script, and the psexec tool itself from Microsoft Sysinternals.  It’s my go-to exploit on Windows targets, once I have gained SMB access and admin credentials (username and password, or username and hash for pass-the-hash attacks).  It works on a fully patched Windows environment, giving you code execution with local system privileges of a program or Metasploit payload of your choice.  That’s especially helpful in a penetration test once you gain access to an internal network that is relatively well patched.  We talk a lot about how to leverage this capability creatively and effectively in my SANS SEC560 course on Network Penetration Testing and Ethical Hacking.

During my class, this lesson sinks in with some students faster than others.  Where it doesn’t sink in, target crashing inevitably ensues as people try other service-side exploits to hammer a target.  To help make the lesson of the usefulness of psexec a little more memorable, I’ve created the following Despair-like poster, titled “A Penetration Tester’s Pledge”:

*Photo credit: Wiki Commons, User Grj23

Don’t get me wrong: I love service-side exploits as much as the next guy.  But, some of them could crash target processes or even entire systems.  Further, psexec is so wonderful because it comes in handy once you’ve compromised one target (perhaps with a client-side exploit), escalated privileges, grabbed some juicy-licious admin credentials, and are looking to spread to more prey.   Now, you can target other fully patched Windows systems in the environment with psexec, your new besty-best friend forever.

The psexec capability just completely rocks, and we have several different variants to choose from:

  • If you want super flexibility in making the target machine run a Metasploit payload of your choosing, such as the mighty Meterpreter, use Metasploit’s psexec module (windows/smb/psexec), which also supports pass-the-hash for authentication (no need to know what the password is; instead, just set SMBPass to the LM:NT hashes). You can also choose a custom RPORT besides TCP 445, so you can port-forward pivot other ports through to your ultimate target’s TCP port 445.
  • If you want to run something at scale across a large number of machines you’ve scanned, consider using Ron Bowes’ psexec Nmap Scripting Engine script on targets where you’ve found TCP port 445 open, which also supports pass-the-hash sweetness.
  • If you are in an environment that prohibits you from running third-party attack tools like Metasploit or Nmap (oucha, I know), you might want to use Microsoft SysInternals’ own psexec program, which typically doesn’t flag anti-virus tools because it comes from Microsoft itself and is regularly used for system administration.  This version doesn’t explicitly support pass-the-hash, but you can use Hernan Ochoa’s excellent Windows Credentials Editor (WCE) to inject your hashes into your Windows machine’s memory, and then use Sysinternals psexec with the new credentials.

Regardless of the variant you use, psexec leverages your credentials to make an SMB connection to the target machine, writes into its file system some code you want to execute, creates a service on the box, and uses the service to execute your code. If you use the Metasploit or NSE versions of psexec, it then cleans up after itself, by deleting the service and removing the code from the file system (both the service and code have a pseudo-random name in Metasploit and NSE).  Yaaaayyyy, Metasploit and NSE!  Thanks for doing it right.

Important note: the Microsoft Sysinternals psexec program doesn’t remove the service that it creates.  Thus, as a penetration tester, you’ll either leave behind an installed service on the machine, or you’ll need to remove it after you are done.  I like to remove it, restoring the environment to what it was like before I was there, lest I slightly increase the attack service of the target machine by leaving behind the psexec service and its related code.  You can remove it using the Microsoft service control (sc) command, as follows:

C:\> sc \\<RemoteTarget> stop psexesvc

C:\> del \\<RemoteTarget>\admin$\psexesvc.exe

C:\> del \\<RemoteTarget>\admin$\system32\psexesvc.exe

C:\> sc \\<RemoteTarget> delete psexesvc

And, one more SUPER IMPORTANT NOTE: The Sysinternals psexec has an option to allow you to specify a different user and password other than your current credentials (the -u <user> and -p <password> command flags).  If you don’t use the -u <user> and -p <password> option with the Sysinternals psexec, the tool uses whatever Microsoft Windows authentication your client and the target support (such as NTLMv2), passing through your existing credentials via a challenge/response protocol.  However, if you use -u and -p with Sysinternals psexec, it will PASS THROUGH THESE CREDENTIALS IN CLEAR TEXT (as described brilliantly by Mike Pilkington here and in Section 4 of this article by Jean-Baptiste Marchand  here).  That’s why I recommend you NEVER use -u and -p with psexec, unless you are comfortable passing through admin-level creds in cleartext.  Your best bet it so use it without the -u and -p options.

So, there you have it. Psexec… a great capability and trusted friend, along with a few notes on its safe usage.

Thanks!

–Ed Skoudis

//
SANS Institute Fellow
Counter Hack Challenges Founder

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

This is the Winter2012 of our Discontent: Guessing Bad Rotating Passwords

[Editor’s Note: Sometimes the most effective and lethal penetration testing and ethical hacking techniques are shockingly straight-forward.  Tim Medin offers hugely useful advice in this article on fine-tuning your wordlists based on the target organization’s password policy.  Read it and live it — these techniques will make your password guessing attacks much more effective. –Ed.]

When walking into a client, I like to have a number of attacks ready to rock while I let the (usually obligatory) Nmap and/or Nessus scans run. This gives me something interesting to do while I wait for the coffee to replace the blood in my veins. Once I get that engine running and the coffee shakes start, you better stand back.

Password guessing, when done right, is one of the attacks with a high success rate. You may not get an admin account, but it is almost guaranteed that you will get at least one account as a solid foothold. To do this right you need to be mindful of the lockout threshold, the amount of time the systems remember failed attempts, and the password complexity requirements. But, one of the most useful bits of information to have when guessing passwords is the rotation frequency.

You may be wondering, “How in the world would it help to know the password rotation frequency?” Well, the short answer is, the more often passwords must be changed, the greater the likelihood users will use a formula to derive the passwords. We pen testers can use this frequency to our advantage.

If users have to change their passwords every quarter and they can’t reuse a password for six years (remembering the previous 25 passwords is common, so 25 / 4 = 6.25). Coming up with 25 good, unique passwords is hard, so many users will derive their password from their surroundings. A user thinks to himself, “I have to change my password this quarter, what else changes every quarter?” The answer, the season; and the season+year will never repeat.

Given it is currently November, good guesses are Autumn2012, Fall2012, or Autumn12 (Fall12 is probably too short to be allowed but don’t rule it out). Some users will still have their password from the summer, so Summer2012 or Summer12 are viable options; as are Winter2012 and Winter12 for users who recently change their password.

If the rotation policy is every 30 days then likely candidates would be the past, current, and next month combined with the year, such as, October2012, October12, November2012, November12, December2012 and December12. These passwords meet the typical complexity requirements that require three of the four sets of character types (upper case, lower case, number, and special character). Users will usually skip the special character if they can. If the organization requires four of the four classes, just append ! to the end of the password.

Of course, don’t discount the serialized passwords using base words followed by a sequential numbers that increment each rotation period (e.g. baseword20, baseword21, baseword22). Common base words are the company name (CounterHack10) and local sports teams (Pirates12). You could try every team, but the local teams are usually good for at least one correct hit.

These rotation policies are put in place to limit the amount of time that compromised credentials can be used in an environment or to (hopefully) rotate the password before the password can be cracked. However, cracking the password doesn’t matter in the Windows world as pass-the-hash and tools like mimikatz remove the requirement to crack the password. As for the limiting the time a compromised credential can be used, how long would it take for an attacker to extract all the sensitive data from your environment using valid credentials? Days, hours, maybe even minutes? My tests are usually a week (or two) long and I can get all the data I need in that amount of time.

To perform automated password guessing we can use a tool like medusa. To do this we need to create list of possible usernames and passwords (two files). The password file we generate from our guesses above, BUT do NOT meet or exceed the lockout threshold or you could cause a widespread lockout and an RGE (Résumé Generating Event). I usually use n-2 where n is the lockout threshold.

Prior to arriving on-site, you can use tools to extract usernames from publicly available sources. I like the Recond-NG (http://ptscripts.googlecode.com/svn/trunk/recon-ng.py)> tool by Tim Tomes (aka LaNMaSteR53), which finds employee names and uses those names to generate possible usernames. Once we have our two files, we can use medusa like this:

medusa -h targetipaddress -U UsersFile.txt -P PasswordGuessesFile.txt -M smbnt -m GROUP_OTHER:MyDomain

The command above we use -U to specify a file containing usernames and -P to specify our password file. The -M specifies the authentication mechanism (SMB) and the “-m GROUP_OTHER” is used to specify the Windows Domain. Now, to select the system to authenticate against.

On internal tests I like to find a file server, as most users can authenticate against it as it will give me useful information once I get a hit. The web-form module works well on perimeter tests when SharePoint or Outlook Web Access is available.

Depending on the target system and the number of users and passwords I’m trying I usually get at least one hit within an hour. Now, how do you as a defender prevent this?

The big issue here is that the and passwords are allowed and considered “complex.” I’m a big proponent of longer, more complex passwords and changing them less often. In the Microsoft’s paper “So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users” (http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf) it says “users have decided that the cost [of rotating complex passwords] is far too great for the benefit offered. If we want a different outcome we have to offer a better tradeoff.” The solution put forth is to increase the complexity and length requirements but let the users keep the password longer (year).

Happy Autumn2012!


Tim Medin | tim@counterhack.com

[Special Announcement: SANS Security 560 in SMELL-O-VISION!  

Ed Skoudis and I will be co-teaching the SANS Security 560 Course using SANS across-the-Internet training platform, vLive in January and February 2013.  Register by November 28 and get a free MacBook Air or Ultrabook.  Details of the special offer are available here: http://www.sans.org/vlive/specials

To take advantage of this offer, enter one of the following discount codes at checkout: 
1108_MAC (MacBook Air) 
1108_TOSH (Toshiba Portege Ultrabook) 
1108_850 ($850 Discount)

So, what’s SMELL-O-VISION?  Keep reading, please.

The class will be offered via the Internet over a 6-week span
using SANS’ vLive infrastructure, giving you plenty of time to study,
review, and master the skills and numerous hands-on labs.  Classes begin
on January 7 and will meet on Monday and Wednesday nights.
Full details can be found at http://www.sans.org/info/116182.

Regardless of whether your job is penetration testing, security
operations, system administration, incident handling, or another security
area, this course will show you how you and your organization can get the
most value out of penetration testing, with in-depth technical excellence
and business smarts.

And, yes, there will be Smell-O-Vision.  How?  In your registration
package, you’ll receive detailed books, course exercises, and a course DVD
for all of the hands-on labs, which include access to a target environment
across the Internet through a VPN.  But you’ll also get a special
scratch-n-sniff scent kit which Ed and I will seamlessly integrate into
the lectures, indicating the proper time to smell each item to help hammer
your memory receptors with knowledge of given skills.

Yes, this is going to be a special event indeed.

We hope you’ll be able to join us!  For more information, please visit
http://www.sans.org/info/116182.  Register soon, because Smell-O-Vision
will be arriving right after the holidays!]