Please be aware there is a Samba remote code execution vulnerability that has been published today in Metasploit and mass exploitation is likely to follow or be used to self-propagate in the form of a worm.

The vulnerability affects all versions of Samba over the past 7 years, the open source Unix/Linux implementation of the Microsoft File and Print Sharing service, and a patch was released yesterday.

The vulnerability is triggered by connecting to a writeable file share (it can be abused as an anonymous user or with credentials) then uploading a Unix .so shared object file which is then executed on the server.

Many Linux and Unix based operating systems are vulnerable, as are products like NAS (Network Attached Storage) file servers such as Synology, mediacentres and modems etc.

CVE-2017-7494 has been assigned to this issue and reports indicate over 100,000 internet accessible systems are currently vulnerable.
​
If you are unable to patch immediately, the vulnerable feature can be disabled by setting the 'nt pipe support = no' directive within the /etc/samba/smb.conf file and restarting the service.

By default the Play! Framework web service will disclose the version number used which can aid an attacker in conducting targeted attacks using known vulnerabilities.

To hide the version number, modify the conf/application.conf file and set the directive http.exposePlayServer to equal ‘false’.

The HTTP Strict-Transport-Security standard (HSTS) is a HTTP server header sent by SSL/TLS enabled websites to prevent communication over HTTP in order to protect content and authentication cookies from interception or alteration.

To enable this header on the nginx web server, modify the nginx.conf file. Within the server block, find and edit the location block and set the "add_header" directive with a value of e.g. Strict-Transport-Security "max-age=31536000"; (for 365 days).

E.g:

server {
 location / {
  add_header Strict-Transport-Security "max-age=31536000";
​ }
​}

This is just a quick email to let you know we now have SSL enabled for our test malware attacks, so not only can you test your firewall, IDS/IPS, proxies, content filtering and desktop antivirus, but you can also check if you are protected against payloads delivered over HTTP/S or verify your SSL-inspection products are working.
​
Simply open the Test Malware page and click the [SSL] hyperlink to conduct the test over SSL to ensure your organisation is adequately protected (most attacks today are delivered over SSL to get around proxy inspection).

​Juniper have just released a product security alert regarding their NetScreen / ScreenOS devices. During an audit, it was discovered that their source code was compromised and an unknown attacker planted a backdoor within the firewall code.
The backdoor permitted:

1. Unauthenticated remote administrative access over SSH or telnet.
2. IPSec VPN traffic decryption (possibly by leaking private keys to the attacker).
Detailed information can be found in JSA10713.

Am I vulnerable?

The ScreenOS firmware was compromised in August 2012.

Only ScreenOS versions 6.2.0r15 to 6.2.0r18, and 6.3.0r12 to 6.3.0r20 are known to contain the backdoor. If you are running a version number below this release, earlier than August 2012, then your network should be secure. Juniper recommends that anyone using these firmware versions should upgrade immediately.
Fixes are included in: 6.3.0r12b, 6.3.0r13b, 6.3.0r14b, 6.3.0r15b, 6.3.0r16b, 6.3.0r17b, 6.3.0r18b, 6.3.0r19b

CVE-2015-7755 has been assigned for this issue.
​
This is a timely reminder to employ "defence in depth" techniques, such as installing layered firewalls from different vendors, to protect your internal assets in the event one is defeated.

Have a safe and relaxing holiday season,

This is a quick email to bring your attention to a recently publicised OpenSSL security vulnerability known as "Heartbleed". The Common Vulnerabilities and Exposures list has assigned CVE-2014-0160 for this issue.

The vulnerability is currently being exploited in the wild on a small scale.

The vulnerability is a memory disclosure bug. That is, a malicious user can send a trigger packet to an HTTPS service with a vulnerable OpenSSL instance, and the server will respond with the raw memory contents of the HTTP server (such as Apache) or OpenSSL.

Examples include:

1. Revealing the SSL private key, such as .PEM file.
2. Disclosing cached contents of the HTTP/S server, such as username and password sent over SSL to authentication forms.
3. Data stored within the HTTP/S server, such as source code, database connection strings, and information normally only accessible as an authenticated user logged in to the system.
4. Internal memory addressing and security defence mechanisms.

The issue is not only HTTP/S related, but may include other protocols which implement OpenSSL functions (such as SMTP/S, POP3/S etc).  

Am I vulnerable?

Only OpenSSL versions 1.0.1, 1.0.1a through to 1.0.1f are vulnerable. Version 1.0.1 was released March 2012. Version 1.0.1g was released today and is immune (many distributions have not yet released updates, but they should become available within 24 hours). Versions prior to 1.0.1, such as 1.0.0 and the 0.9.x variants do not include this specific vulnerability.

You can check what version you have by running openssl with the version switch:

# openssl version
OpenSSL 1.0.1f 6 Jan 2014 (vulnerable)

This bug is specific to OpenSSL only. Microsoft products may not be affected, however Windows products which utilise OpenSSL may be affected. Most Linux and unix variants utilise OpenSSL. 

It is worth determining what risks this presents to your organisation. As the private key can be compromised and traffic decrypted, consider whether a new private key should be issued and signed by CA (once the server has been patched).

Introduction:
At some point you may be required to audit the configuration of a SonicWALL device.
If you have physical/admin access to the management interface, then this is probably the easiest method - drill down every option and check for misconfiguration.

If not, obtain a configuration export file (file name is generally 'sonicwall-name-date.exp') such as sonicwall-SydneyDC-20100607.exp.

You will notice the file is a single line of Base64 encoding.
​
Method:
Either use software such as nipper (a tool to automatically decode multi-vendor firewall, router, switch etc.. configurations then analyse the settings and make recommendations in a pretty report) or Base64 decode it yourself and read the variables.

Linux: 'base64 -d file'
Windows (if you have ActiveState Perl): 'c:\bin\decode-base64.bat file'
​
Recommendation:
Often issues such as SSH v1 and SNMP will be present. Also check the firmware as SonicWALL is notorious for format string bugs.

Introduction
Visit www.openspf.org for more information on this technology.
​
Method
It is held within a TXT record for the domain. You can query this with the host command under Linux/POSIX.
$ host -t txt [victim].com
[victim].com descriptive text "v=spf1 a mx include:[victim].com"
​
Recommendation
Consider adding SPF records to allow MX records to send email.
SPF helps prevent forging of the FROM address on the receiver end.
Customer MTAs which support SPF will reject fraudulent emails because the SPF record will not match the spammers IP source addresses when forging @[victim].com FROM addresses.

Introduction
By default BIND DNS reveals the version number when queried for a certain TXT record.

Command
# dig chaos txt version.bind @ns.[target].com

Result
An example is below:

; <<>> DiG 9.7.1-P2 <<>> chaos txt version.bind @ns.[target].com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18628
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.3.6-P1-RedHat-9.3.6-4.P1.el5"
;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.
;; Query time: 329 msec
;; SERVER: [ip]#53([ip])
;; WHEN: Sat Aug 21 03:55:28 2010
;; MSG SIZE rcvd: 87

Recommendation
Using the 'version' directive in the 'options' section will block the 'version.bind' query - usually in /etc/named.conf.

The server is running the PHP programming language which is configured to expose details about the target host. This information may be useful to an attacker in determining the software versions installed.

Example HTTP response header:

• X-Powered-By: PHP/5.4.16

Example URLs:

• https://[target]/?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 
• https://[target]/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 
• https://[target]/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 

Recommendation:
Modify the php.ini file and set the directive 'expose_php' to 'Off' and restart the service.

Risk:
Low.

Intro
The server reveals its internal IP address when specifying a WebDAV PROPFIND request.

Method
Issue a PROPFIND request with a HTTP v1.1 empty Host header:

telnet example.com 80
Trying 123.123.123.123...
Connected to example.com.
Escape character is '^]'.
PROPFIND / HTTP/1.1

Host:
HTTP/1.1 302 Redirect
Content-Length: 140
Content-Type: text/html
Location: /
Server: Microsoft-IIS/6.0
Date: Tue, 08 Jun 2010 07:05:08 GMT
Document Moved
Object Moved This document may be found here

Recommendation
Reconfigure IIS to return the FQDN value instead:
http://support.microsoft.com/kb/q218180/
​
Refs
OSVDB 13431

Introduction
IIS + .NET may reveal sensitive information when an exception occurs.
Often this information may include the system path to the webroot (i.e. C:\Inetpub\wwwroot) which may further aid in attacks where a malicious user may upload content, but is not sure where the file is located on the remote system.

Method
By requesting a document with an .ashx extention, the server reveals the path (e.g. D:\sites\secret\uploads). It also reveals the version of .NET in the footer, such as "Microsoft .NET Framework Version:1.1.4322.2407; ASP.NET Version:1.1.4322.2407". The Framework version can then be used to check for known vulnerabilities, such as NULL byte issues.

Recommendation
Within the Machine.config or Web.config file, specify a directive of "customErrors" of either "RemoteOnly" or "On".
See also: http://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx

Introduction
The portal requires users submit a username and password to authenticate. This communication is not encrypted.

Method
Check the HTML source code on the form page, and examine whether the FORM ACTION is GET/POST to a HTTPS:// URI.
​
Recommendation
1) Enable SSL and disable HTTP for the portal
2) Use two-factor tokens (one time password) for strong authentication.
3) Modify the HTML source to ensure the data is POST'ed to a HTTPS URL.

1.In Microsoft Windows, open Administrative Tools, and then click Internet Information Services (IIS) Manager.
IIS Manager appears.

2.Under Internet Information Services, expand Servername (local computer), expand Web Sites, right-click either Websitename or Default Website, and then click Properties.
The Web Site Properties dialog box appears.

3.Click the Home Directory tab, and then click Configuration.
The Application Configuration Settings dialog box appears.

4.Click the Debugging tab.
​
5.Change the radio button from "Send detailed ASP error messages to client" to "Send the following text error messages" and specify an error.