Tools update (6th May)

My slightly irregular update on new and updated Information Security tools that I have come across or use. The tools are mainly those for PenTesting although other tools are sometimes included. As a bit of background into how I find these tools, I keep a close watch on twitter and other websites to find updates or new releases, I also search for pen testing and security projects on Source Forge. Some of the best sites I have found for details of new tools and releases are http://www.toolswatch.org/ & http://tools.hackerjournals.com 

Cain & Abel 4.9.44
http://www.oxid.it/cain.html

Cain & Abel is a password recovery tool for Microsoft operating systems.
It allows easy recovery of various kind of passwords by sniffing the network, cracking encrypted passwords using dictionary and brute force attacks, decoding scrambled passwords, revealing password boxes, uncovering cached passwords and analyzing routing protocols.


Arachni v0.4.2 has been released
http://www.arachni-scanner.com/blog/new-release-v0-4-2-new-interface-new-website/
Arachni is a modular and high-performance (Open Source) Web Application Security Scanner Framework written in Ruby.

Kali 1.0.3
http://www.kali.org/kali-linux-releases/
Kali Linux is an advanced Penetration Testing and Security Auditing Linux distribution.
Kali is a complete re-build of BackTrack Linux, adhering completely to Debian development standards. All-new infrastructure has been put in place, all tools were reviewed and packaged,

Tools update (25th Apr 13)

My slightly irregular update on new and updated Information Security tools that I have come across or use. The tools are mainly those for PenTesting although other tools are sometimes included. As a bit of background into how I find these tools, I keep a close watch on twitter and other websites to find updates or new releases, I also search for pen testing and security projects on Source Forge. Some of the best sites I have found for details of new tools and releases are http://www.toolswatch.org/ & http://tools.hackerjournals.com

SSH Communications Security, the inventor of the Secure Shell and SFTP protocols, today announced the launch of SSH Risk Assessor (SRA), a free tool that provides users with a clear report on risk and compliance exposures in SSH environments. SRA will be available in May 2013, you can request it http://www.ssh.com/index.php/products/ssh-risk-assessor.html (registration required).

Nessus 5.2
http://www.tenable.com/products/nessus/new-in-nessus-52
Nessus 5.2 offers the ability to store attachments in the scan reports. Scan results now contain, among other things, remote screenshots via Remote Desktop Protocol (RDP) and VNC, as well as “pictures” of scanned websites.
The new attachments feature provides easy access to supporting information for vulnerability investigation and documentation, as well as offers other interesting information.

Identifying SSL/TLS Ciphers

Increasingly communication across networks and the Internet are using SSL/TLS to protect the transactions, this has been driven by a raft of legislation that is mandating the use of strong encryption, examples of such regulations, law and standards from around the world are listed below.

• PAYMENT CARD INDUSTRY DATA SECURITY STANDARD (DSS)
• GRAMM-LEACH-BLILEY ACT (GLBA)
• SARBANES-OXLEY ACT (SOX)
• BASEL II ACCORD
• EURO-SOX
• Financial Instruments and Exchange Law of 2006
• HEALTH INSURANCE PORTABILITY & ACCOUNTABILITY ACT (HIPAA)
• FDA TITLE 21 CFR PART 11 (1997)
• 95/46/EC EUROPEAN UNION (EU) DIRECTIVE
• BUNDES-DATENSCHUTZ-GESETZ (BDSG)
• CALIFORNIA SENATE BILL 1386 (SB 1386)
• PERSONAL INFORMATION PROTECTION & ELECTRONIC DOCUMENTS ACT (PIPEDA)
• DATA PROTECTION ACT (DPA) OF 1984 (AMENDED 1998)
• PERSONAL INFORMATION PROTECTION LAW (PIPL) OF 2003

The SSL/TLS protocols are used by the HTTPS protocol to encrypt web pages and data entered into them. There are a number of versions of SSL/TLS which are in use; SSL was developed by Netscape for transmitting private documents via the Internet. TLS was developed by the Internet Engineering Task Force (IETF) to provide similar functionality to SSL..

SSLv1 - Never Published
SSLv2 - released in February 1995
SSLv3 - released in 1996 (RFC 6101, Historical document)
TLSv1.0 - released in January 1999 (RFC 2246)
TLSv1.1 - released in April 2006 (RFC 4346)
TLSv1.2 - released in August 2008  (RFC 5246)

Both SSL and TLS use cryptographic systems to encrypt data, the actual cryptographic system used is negotiated during the SSL/TLS handshake where the cipher suite is selected and encryption keys are generated and exchanged. Both use the asymmetric encryption using the website certificate to exchange the private keys for symmetric encryption.

In order for SSL/TLS to be acceptable for the encryption of cardholder data in order to comply with requirements for strong encryption such as section 4 of the PCI DSS, the negotiation phase should result in the use of a strong cipher. This requires the server to support versions of SSL and TLS that do not have well know vulnerabilities and use cipher suites based on strong cryptography. The capabilities of a server using HTTPS are advertised by the certificate and the initial phase of negotiating the key exchange.

TLS/SSL supports a large number of cipher suites, where the cipher suite is a combination of symmetric and asymmetric encryption algorithms used to establish secure communication.
Supported cipher suites can be classified based on encryption algorithm strength, key length, key exchange and authentication mechanisms. Some cipher suites offer a stronger level of security than others (e.g. weak cipher suites were developed for export to comply with US export law).

Understanding cipher suites

There are a number of different naming conventions

The Open SSL naming convention, which is probably the most common uses at least nodes in the naming of the ciper suite

• key exchange,
• server certificate authentication,
• stream/block cipher
• message authentication

For example

DHE-RSA-AES256-SHA

DHE for key exchange, RSA for server certificate authentication, 256-bit key AES for the stream cipher, and SHA for the message authentication.

Often the cipher name is prefixed with the protocol such as SSL or TLS and an additional node to indicate the mode used in the stream/block cipher such as

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Which indicates it is for TLS and uses cipher block chaining in the implementation of 256 bit key AES. Some additional terms that may be found are

• Anon - Anonymous cipher suites with no key authentication. Highly vulnerable to man in the middle attack.
• Export -  Intentionally crippled cipher suite to conform to US export laws. Symmetric cipher used in export cipher suites typically does not exceed 56bits.
• NULL - Null cipher suites do not provide any data encryption and/or data integrity

Auditing and compliance

One of the problems for those tasked with auditing or ensuring compliance with the regulations/standards is know what strength cryptography has been deployed on the servers.

Vulnerability assessment tools that assess the security profile of servers using SSL/TLS will integrator the server to assess its capabilities and will attempt to connect using all versions of SSL and TLS and a range of ciphers from the weak to the strongest. If the tool supports a PCI DSS test will report if the server is secure to the requirements of the standard. However even without a specific PCI DSS test for secure servers the tools will report the capabilities of the server which can be examined to see if the requirements of the standard are being met. The Nessus scanner has the capability of checking SSL services on arbitrary ports, and will report weak ciphers and includes a PCI DSS audit checks.

The nmap scanner, when used with the service/version scan “–sV” option will identify SSL services. Additionally tools such as openSSL can be used to manually audit

openssl s_client -no_tls1 -no_ssl3 -connect <server_Name>:443

Other tools are sslscan which is included in BackTrack and the ssl_tests script can be used.

References

http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://en.wikipedia.org/wiki/Cipher_suite
http://www.openssl.org/docs/apps/ciphers.html
http://www.iana.org/assignments/tls-parameters/tls-parameters.txt
http://www.pentesterscripting.com/discovery/ssl_tests

New Talk being developed

Been asked to give a talk on Internet Security to a group of  Occupational Health and Safety professional at one of their safety association meetings, so the talk will be low level on the technicality but the synopsis of the talk is given below

Title: How the web hacks you

The internet has become a feature of all our lives whether at work or at home. Recent developments such as cloud services and the government's push to move its activities online mean that more and more in our personal and work life we are conducting transactions over the web. The web has made a wide range of interactions from finding information to purchasing and banking activities so much more convenient for us. However it has also made it easier for us as individuals and organisations to be attacked via the web with phishing, scams, malware and hacking occurring. Not a day goes past when some form of attack via the web is reported in the news. This talk will outline the reasons why the web is vulnerable, explain some of the more frequent attacks and suggests countermeasures that make it less likely you will be hacked via the web.

WiFi talk Feb 2013

Received some pictures of the talk I did in Feb this year to the Bedford branch of the BCS at Bedford College.

"WiFi Networks: The Practicalities of Implementing A WiFi Network" is the topic of a talk by Geraint Williams, Information Risk Consultant and Trainer, IT Governance Ltd., and Honorary Visiting Fellow at the University of Bedfordshire.

Secure configuration is becoming ever more important as an increasing number of devices are incorporating wireless technology - from laptops, smartphones, tablets, projectors and cameras, to multimedia entertainment systems and games consoles. The growing demand for allowing BYOD ("Bring Your Own Device") within the corporate network means that larger numbers of organisations are implementing wireless networks.

The wireless network standard 802.11 was originally released in 1997 by the IEEE and, by computing timescales, is a mature technology with a large base of manufacturers and both commercial and domestic users. Despite initiatives like Wireless Protected Setup (WPS) to make installation easier, there are still issues in implementing a network using wireless technology in both the corporate and home environments.

The courts have already convicted paedophiles for piggybacking neighbours wireless networks to download material, and hackers for using wireless networks for pirating software, music and films and for spying on occupants using their own security cameras.

Wireless networks have a history of security problems with flaws in the implementation of WEP and recently with WPS. This talk will look at these issues, the (open source) tools that can be used, and how these apply to the wireless environment. The talk will include practical demonstrations of the tools and techniques discussed in the presentation and will unravel the alphabetic soup of the available standards.

Mar 2013 ADSL Router Analysis

The latest analysis of my ADSL logfiles and a new twist for March, China has dropped completely from the results and the new bad boys are the United States or rather Akamai Technologies, Inc. The underlying scans from Turkey continue.

2012			2013
Country	Source IPs	Attacks	Country	Source IPs	Attacks
Turkey	71	71	Turkey	58	58
China	2	40	United States	13	134
United Kingdom	2	29	Germany	3	25
Germany	1	13	France	2	21
Russia	1	1	United Kingdom	2	4
			Azerbaijan	2	2
			Russia	1	6

There is no clear correlation between the date of the attacks, although in 2013 the scans are concentrated on two days, the most prolific scanning IP addresses belonged to Akamai Technologies, Inc. who I have discussed previously on my blog.

My previous discussions on Akamai Technologies, Inc

• http://geraintw.blogspot.co.uk/2012/04/akamai-upd-ports-canning.html
• http://geraintw.blogspot.co.uk/2012/04/akamai-update.html 

Tools Update (2nd April 2013)

My slightly irregular update on new and updated Information Security tools that I have come across or use. The tools are mainly those for PenTesting although other tools are sometimes included. As a bit of background into how I find these tools, I keep a close watch on twitter and other websites to find updates or new releases, I also search for pen testing and security projects on Source Forge. Some of the best sites I have found for details of new tools and releases are http://www.toolswatch.org/ & http://tools.hackerjournals.com

Wireshark
http://www.wireshark.org/download.html
The current stable release of Wireshark is 1.8.6. It supersedes all previous releases, including all releases of Ethereal. You can also download the latest development release (1.9.2) and documentation.

Sysinternals
http://blogs.technet.com/b/sysinternals/archive/2013/03/27/updates-autoruns-v11-5-du-disk-usage-v1-5-procdump-v5-14-procmon-v3-04-ru-registry-usage-v1-0.aspx
Updates: Autoruns v11.5, Du (Disk Usage) v1.5, Procdump v5.14, Procmon v3.04, Ru (Registry Usage) v1.0

Scylla
http://code.google.com/p/scylla-v1/
Scylla is another tool that you can use for penetration testing protocols used by different applications.

Feb 2013 ADSL Router Analysis

I have now completed 12 months of collecting the log files from my ADSL router and moving into the second year of data collection. I will be looking at how 2013 data matches up against the 2012 data on a month per month basis.

Source IP addresses are the source address from the packet(s) detected, it is not necessarily the true source of the attack.

Year	Countries	Source IPs	Attacks
2012	8	60	76
2013	4	71	76

Attacks coming from Turkish owned IPs is consistent, however in Feb 2013 the rest of the attacks have no pattern.

2012			2013
Country	Source IPs	Attacks	Country	Source IPs	Attacks
Turkey	52	52	Turkey	66	66
Netherlands	1	16	United States	2	7
Ukraine	2	2	Azerbaijan	2	2
China	1	2	Ukraine	1	1
France	1	1
Egypt	1	1
South Africa	1	1
United Kingdom	1	1

Retriving passwords /etc/shadow

Using Python to retrieve passwords from the /etc/shadow file on Backtrack 5R3 as an exercise in improving scripting skills.

Note: This is an educational exercise for those wishing to learning python as part of becoming a security professional in order to improve their skills and enable them to write or modify tools, a key part of any pen testers repertoire. A solution is not giving, however how to get to a working solution is laid out in the notes. By understanding how the shadow password system works, it is possible to write a script to solve the problem.

In the Violent Python book one of the first example is retrieving passwords from the /etc/passwd file and after describing their example it ask if those reading can modify the script to retrieving passwords in the /etc/shadow file, giving the hint that the shadow file uses SHA512 hashing, the functions for which are in the hashlib library. This is a red herring as the hashlib file only outputs either in Hexadecimal or a string containing non-printable ASCII characters, where as the shadow file contains only printable ASCII characters.

First thing is to understand the problem, on backtrack we know the default password is toor for the user root, this enable us to test our script quite easily. However lets us examine a line from the shadow file.

root:$6$1hjjWhtS$Or2xL2Eedes/ajatnSc0gqcxR0ZAJAIoYxqjPlvESDJX.XPXiydBPK7waQkpypcnsb5f7G6h7eVs8jlkHVptD0:15609:0:99999:7:::

We can see it consists of data separated by colons, the meaning of each segment can be found in the /shadow man page.

• login name
• encrypted password
• date of last password change
• minimum password age
• maximum password age
• password warning period
• password inactivity period
• account expiration date
• reserved field

We are only interested in the first two fields.

• The login name must be a valid account name, which exist on the system.
• The encrypted password refer to man page on crypt for details on how this string is interpreted.

The encrypted password file consist of a data segmented by the "$" symbol, these fields are

• Hash method
• Salt Value
• Encrypted Password

The hash methods are represented by the following keys

• $1$ - MD5
• $5$ - SHA256
• $6$ - SHA512

In the case of the example above, the fields are

• username = root
• hash method = $6$ (SHA512)
• Salt = 1hjjWhtS
• Encrypted password = Or2xL2Eedes/ajatnSc0g ..... 6h7eVs8jlkHVptD0

We still don't have enough information to retrieve the password, as the hashing algorithm, if it is SHA256 or SHA512 is repeated a number of times (rounds). We need to know the number of rounds that have been used as this can be changed, the more rounds, the longer it takes to hash the password which is inconvenient to the user but makes it harder for the attacker if they are brute forcing the password.

If we examine the /etc/login.defs file we will find section giving the number of rounds used.

#

# Only used if ENCRYPT_METHOD is set to SHA256 or SHA512.

#

# Define the number of SHA rounds.

# With a lot of rounds, it is more difficult to brute forcing the password.

# But note also that it more CPU resources will be needed to authenticate

# users.

#

# If not specified, the libc will choose the default number of rounds (5000).

# The values must be inside the 1000-999999999 range.

# If only one of the MIN or MAX values is set, then this value will be used.

# If MIN > MAX, the highest value will be used.

#

# SHA_CRYPT_MIN_ROUNDS 5000

# SHA_CRYPT_MAX_ROUNDS 5000

We know have enough information to attempt to write a script to retrieve the password, we can copy the shadow file to a text file "shadow.txt" and we need a dictionary file "dictionary.txt" contain a word per line.

We can read each line of the shadow.txt, parse the line to extract the username, salt and encrypted password. We can combine the salt with the word from our dictionary.txt file and hash the word and compare it to the encrypted password, if it matches we have guessed the password. In order to do this we need the correct hashing library, the hashlib is not suitable, the correct one is Passlib which is not installed by default on Backtrack 5R3 but can easily be added using the following command


easy_install passlib

To use passlib we can send it the guessed word, the salt value and number of rounds to be used, as shown in the following commands to import the hashing routine and call it.

from passlib.hash import sha512_crypt
sha512_crypt.encrypt(word,salt=salt, rounds=5000)

The lib passlib when it produces a hash digest the output consists of a number of fields and uses by default 60,000 rounds.

• Hash method
• Number of rounds
• Salt Value
• Encrypted Password

An oddity is that when the number of rounds is set to 5000, the number of rounds is not outputted, making it compatible with the shadow file format.

All we need to do is parse the returned line and compare the encrypted value of the guessed word to the value retrieved from the shadow file.

Security point

Changing the default number of rounds to a higher value can considerable delay an attacker and often make tools that use the default value unusable. Assuming 250ms to hash a word using 5000 rounds, changing to 60,000 rounds will increase the time to 3 secs, over a dictionary attack using several thousand words this will dramatically increase the time to try every word.

Learning outcome

Understanding an operating system and how it is configured will help the security professional develop techniques and tools for testing the security posture of the operating system. The exercise in the book was impossible to complete without understanding how the shadow password system was configured.

Remote procedure call (RPC)

is an inter-process communication that allows a computer program to execute a subroutine or procedure in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the connection for this remote interaction.

The idea of treating network operations as remote procedure calls can be traced back to the ARPANET in the 1980s.  Xerox under the name "Courier" implemented one of the first business uses of RPC in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), this was used as the basis for Network File System (NFS).

The RPC (Remote Procedure Call) mechanism allows an application to seamlessly invoke remote procedures, as if these procedures were executed locally. There are two main implementations of the RPC mechanism:

• ONC RPC 
• DCE RPC (MSRPC)

RPC allows one program to request a service from a program located in another computer in a network without having to understand network details. RPC uses the client/server model. The requesting program is a client and the service-providing program is the server. A number of interesting services run as Remote Procedure Call (RPC) services using dynamically assigned high ports. 

Portmappers

To keep track of registered endpoints and present clients with accurate details of listening RPC services, a portmapper service listens on known TCP and UDP ports and maps RPC program numbers and versions to Internet port numbers.

• The ONCRPC portmapper (also known as rpcbind within Solaris) can be queried using the rpcinfo command found on most Unix-based platform and listens on TCP and UDP port 111
• The Microsoft RPC endpoint mapper (also known as the DCE locator service) listens on both TCP and UDP port 135

ONC RPC

Open Network Computing (ONC) Remote Procedure Call (RPC)  was originally developed by Sun Microsystems as part of their Network File System project. It was orginally described in RFC 1831, published in 1995. RFC 5531, published in 2009, is the current version. Authentication mechanisms used by ONC RPC are described in RFC 2695, RFC 2203, and RFC 2623. In 2009, Sun relicensed the ONC RPC code under the standard 3-clause BSD license and then reconfirmed by Oracle Corporation in 2010 following confusion about the scope of the re-licensing.

The port mapper (rpc.portmap or just portmap, or rpcbind) is an Open Network Computing Remote Procedure Call (ONC RPC) service that runs on network nodes that provide other ONC RPC services.

The port mapper service always uses TCP or UDP port 111; a fixed port is required for it, as a client would not be able to get the port number for the port mapper service from the port mapper itself. The port mapper must be started before any other RPC servers are started.

MSRPC

Microsoft RPC (Microsoft Remote Procedure Call) is a modified version of DCE/RPC. Additions include support for Unicode strings, implicit handles, inheritance of interfaces (which are extensively used in DCOM). Examples of Microsoft applications and services that use port 135 for endpoint mapping include Outlook, Exchange, and the Messenger Service.

Depending on the host configuration, the RPC endpoint mapper can be accessed through TCP and UDP port 135, via SMB with a null or authenticated session (TCP 139 and 445), and as a web service listening on TCP port 593

Enumeration

Both ONC RPC and MSRPC portmappers can be interrogated to provide information on the services that are running through them.

The rpcinfo tool can be used on Unix systems to enumerate the services running on port 111 (rpcbind) or 32771 (Sun's alternate portmapper). For windows systems tools such as edump can be used. Nmap has a number of useful scripts

• msrpc-enum
• rpc-grind
• rpcap-brute
• rpcap-info
• rpcinfo
• msrpc
• msrpctypes
• nrpc

In addition to those listed above a number of the smb scripts use RPC to enumerate services. When enumerating the services we are looking for interesting services such as nfs, rusers, mountd along with information on smb.

In networks protected by firewalls and other mechanisms, access to the RPC portmapper service running on port 111 is often filtered. Therefore, determined attackers can scan high port ranges (UDP and TCP ports 32771 through 34000 on Solaris hosts) to identify RPC services that are open to direct attack.
You can run nmap with the -sR option to identify RPC services listening on high ports if the portmapper is inaccessible.