This is a write-up on how I hooked my JJP Hobbit Pin to the Internet, enabling live streaming directly from the pinball machine, and allowing people to interact with my pin by displaying messages and images through the Internet on my pinball backglass.
All changes were to software, with the exception of plugging in a few cords.

http://lachniet.com/hobbit

TLDR; 7-minute overview video @ https://www.youtube.com/watch?v=8T524GXsVJY

-Bede

Medusa 2.2 is the first release in over three years. While there are no major changes to the core of the application, it does include many bug-fixes throughout the code base and numerous incremental improvements. The following significant module updates are also included:

HTTP. The module now supports NTLM2 session responses and allows for the inclusion of custom headers. In addition, it can report the target host’s default domain when using NTLM authentication.

RDP. This is a new module and uses the FreeRDP library to test RDP (Terminal Services) on Microsoft Windows 2008/7 and later hosts. It also supports pass-the-hash testing depending on the version of FreeRDP installed. It is recommended that if you are using the RDP module, it be built against a current version of FreeRDP. The FreeRDP-Nightly site provides binaries for several platforms and can be installed side-by-side with the released version. Medusa will detect and use the nightly version during its build process.

SMB. The module now includes a check of the ADMIN$ default share. The purpose of this is to test whether the valid credentials have administrative or user-level access to the host.

SMTP-VRFY. The module now supports EXPN and RCPT bruting.

SSH. The module should now be stable on OS X due to several bug fixes with thread safety.

Medusa is now hosted at GitHub – https://github.com/jmk-foofus/medusa.

See doc/medusa.html for Medusa documentation. For additional information:

http://foofus.net/?page_id=51
http://foofus.net/goons/jmk/medusa/medusa.html

Please feel free to send me questions, bug reports, or patches directly or through the foofus-tools mailing list.

Enjoy!
Joe

—————————————————————————————————————————————-
1. Summary

The Client Access Server (CAS) that services Autodiscover and Outlook Web App (OWA) has been found to be vulnerable to time-based authentication attacks. It has been discovered that when sending authentication requests to the CAS, behavior in the timing of the responses can be used to verify Active Directory (AD) realms and usernames within those realms. Authentication timing issues have been found in specific IIS file paths and OWA form-based authentication. This issue can allow an attacker to confirm the existence of a specific username in the directory, and will make other attacks such as password guessing or social engineering attacks more successful.

—————————————————————————————————————————————-
2. Description

When analyzing the response times of authentication requests, there is a noticeable time delay between realms and usernames that exist or don’t exist. It is believed that the underlying issues exists in Windows Kerberos. When the CAS sends authentication requests to the domain controller (KDC) the pre-authentication process is staged in such a way that noticeable time delays exist. OWA form-based authentication and IIS file paths were found vulnerable to this timing delay. The services and authentication paths that have been found vulnerable can be seen below in Table 1.

TABLE 1—VULNERABLE SERVICES
timing_table1

During the testing of the IIS file paths, HTTP NTLM authentication requests were being used. Typically, the realm name, username, and password is required for authentication. There is a case where the CAS can be configured so that the realm name isn’t required and authentication can be accomplished with just a username and password. In this case, the realm name doesn’t need to be known and usernames can be enumerated. Table 2 below details the Windows Kerberos process and approximate response times seen when sending requests to vulnerable services. It should be noted that system resources and network configurations can play a role in response time variations seen. During authentication, when the realm exists but the username doesn’t exist, these times can vary from system to system but the resulting time response is the same average time. For example, it has been seen on a OWA/Forefront TMG 2010 setup that when sending authentication requests to the EWS path, every authentication request will take approximately 60 seconds to respond. When sending form-based authentication requests to OWA 2013, every authentication request can take approximately 15 seconds to respond but another system running the same configuration with more system resources could take approximately 5 seconds to respond. As seen above, the response times in different environments may have different response times but the pattern in the timing response behavior patterns still exist.

TABLE 2—WINDOWS KERBEROS REVIEW
timing_table2

• Non-existing realm – It has been seen that when a non-existing realm names are being tested, that the first request takes 2-3 seconds, and then all requests thereafter take less than one second. What is believed to be happening here is that the first request is searching for the realm and fails but the search response is cached on the CAS for 30 seconds. Thus, the 2-3 second response is seen every 30 seconds.

• Realm exists but username doesn’t exist – A pre-authentication ticket is created to verify the username exists in the realm. The average time of the request can vary depending on resources but the resulting time response is consistent. This could be either approximately 5 seconds or higher. The highest response time seen is approximately 60 seconds.

• Realm and username exists – A pre-authentication ticket is created to verify the password. The time in seconds has been seen to take less then 2 seconds but in most cases this response time is under one second.

Table 3 below details an example of the timing attack analysis. This test was completed against a fully patched Exchange 2013 environment running Windows 2008 R2 server. The OWA 2013 form-based authentication response times were being monitored. The domain CORP is a valid realm and the usernames user_exist_1, user_exist_2, and user_exist_3 are valid account names.

TABLE 3—TIMING ATTACK ANALYSIS
timing_table3

The results are described below.
• Non-existing realm – This can be seen in response # 1 and 2.
• Realm exists but username doesn’t exist – This can be seen in response # 3, 6, and 7.
• Realm and username exists – This can be seen in response # 4, 5, and 8.

—————————————————————————————————————————————-
3. Impact

The issues detailed allow an attacker to enumerate AD realms and usernames which could lead to further compromise. There are many ways to identify realms and username formats, such as searching public databases, stripping metadata from published documents, by reviewing SMTP mail headers and services, or even by obtaining wordlists of the top most popular first and last names and creating a list of correctly formatted usernames to try with a brute force attack. The impact should be categorized as an information disclosure vulnerability.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2010/Forefront TMG 2010
Microsoft Exchange CAS 2007

—————————————————————————————————————————————-
5. Time Line

02/14/2014 Reported Vulnerability to the Vendor
03/10/2014 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
6. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

—————————————————————————————————————————————-
1. Summary

The Microsoft Exchange Client Access Server (CAS) that services Autodiscover has been found vulnerable to an information disclosure. It has been discovered that a standard domain user without Exchange permissions can enumerate Autodiscover configuration files of Exchange users by an XML SOAP parameter injection. This issue can allow an attacker to confirm the existence of a specific email addresses. The type of information that is disclosed are things such as, legacy accounts and their username formats. The end user’s full name is also revealed which could aid in locating a user’s account. Exchange services, permissions, and the location of the domain controller that handles authentication are revealed as well.

—————————————————————————————————————————————-
2. Description

Autodiscover is a CAS service that is used to configure remote or internal mail clients for use with Exchange systems. Using a compatible mail client, the user can configure their client by providing an email address and password. The mail client goes through a discovery process to locate the remote CAS server hosting the Autodiscover configuration file. The configuration file is hosted on an IIS web server. By default the configuration file path is “/Autodiscover/Autodiscover.xml”. To access the Autodiscover.xml configuration file, an XML SOAP request is sent to the server using an HTTP POST method. Server side application controls require the User-Agent header of the request must represent that of an Outlook client, such as “Microsoft Office/12.0”. The body of the SOAP request can be seen in Figure 1.

FIGURE 1—XML SOAP REQUEST BODY

autodiscover_xml_request

By examining the body of the SOAP request made, it was found that modifying the “EmailAddress” parameter to utilize another existing email address, the user’s configuration data can be enumerated. Using a single set of valid credentials, it is possible to inject the “EmailAddress” parameter to discover valid email addresses and gather data about the users and the environment. It was also found that even though valid Active Directory credentials are required to access the Autodiscover.xml file, it is not required to be a valid Exchange account with mailbox permissions. There are many ways to build an email address list that can be used when injecting the “EmailAddress” parameter, such as searching public databases, stripping metadata from published documents, by reviewing SMTP mail headers and services, or even by obtaining wordlists of the top most popular first and last names and creating a list of correctly formatted email addresses to try with this enumeration attack.

—————————————————————————————————————————————-
3. Impact

Allows an attacker to enumerate Exchange user and environment information which could lead to further compromise such as password guessing attacks, social engineering, and learning about internal systems. The impact should be categorized as an information disclosure vulnerability.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2007

—————————————————————————————————————————————-
5. Time Line

05/27/2014 Reported Vulnerability to the Vendor
06/26/2014 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
6. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

—————————————————————————————————————————————-
1. Summary

Multiple issues have been discovered that make it possible to disclose internal IP addresses of remote Microsoft Exchange environments. This includes internal addresses of the Client Access Server (CAS) which hosts services such as Outlook Web App (OWA) and Autodiscover. This also includes internal addresses of the proxy or gateways processing requests for the OWA.

—————————————————————————————————————————————-
2. Description

Attack #1 – OWA / Autodiscover

When sending a crafted GET requests to the web server with empty host header and using the HTTP protocol version 1.0(HTTP/1.0), the internal IP addresses of the under lying system is revealed in the header response. This flaw is believed to be an IIS issue and has been found in Microsoft Exchange systems such as Outlook Web App (OWA) and the Client Access Server (CAS). The flaw has been seen in Basic Authentication response headers on a 401 web server status and the Location headers on a 302 web server status. It’s possible this flaw exists in other products that run on IIS. An example of normal behavior can be seen when performing a HTTP/1.1 request to a protected page such as:

“https://autodiscover.example.com/Autodiscover/Autodiscover.xml”

The Basic Authentication HTTP header response normally reveals a public facing IP address or hostname of:

WWW-Authenticate: Basic realm=”autodiscover.example.com”

A proof of concept example can be seen below in Figure 1. All the vulnerable IIS paths discovered and there affected product versions can be seen in Table 1. Note that some of the file paths disclosed are vulnerable if default settings have not been changed. Some of the paths have been found vulnerable based on system administrator changes.

TABLE 1—VULNERABLE PATHS
exchange_internal_ip_table1

FIGURE 1—BASIC AUTH HEADER REVEALS INTERNAL IP ADDRESS

$ openssl s_client -host autodiscover.example.com -port 443

—SNIP—
GET /Autodiscover/Autodiscover.xml HTTP/1.0
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-SOAP-Enabled: True
X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-AspNet-Version: 2.0.50727
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm=”10.1.1.10″
X-Powered-By: ASP.NET
—SNIP—

Attack #2 – Reverse Proxy / Gateway

It has been shown in OWA 2007 and 2010, that it’s possible to reveal the internal IP address of the reverse proxy or gateway processing requests for OWA. Such proxies or gateways include Forefront TMG 2010. This attack can be performed using a web browser. When attempting to trigger ASP.NET debug and making a GET request to the OWA path “/owa/auth/trace.axd”. The OWA throws a server side exception with a web server status of 403. The verbose error reveals the internal IP address of the proxy or gateway. Example output can be seen below in Figure 2.

FIGURE 2—REVERSE PROXY/GATEWAY INTERNAL IP DISCLOSED

An error occurred and your request couldn’t be completed. If the problem continues, contact your helpdesk with this HTTP Status code: 403.

Request
Url: https://mail.example.com/owa/auth/trace.axd
User host address: 10.1.1.1
OWA version: 14.2.318.3

—————————————————————————————————————————————-
3. Impact

Allow an attacker to gather information about the internal network.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2010/Forefront TMG 2010
Microsoft Exchange CAS 2007
Microsoft Exchange OWA 2003

—————————————————————————————————————————————-
5. Solution

Only attack two is fixed in current versions. Apply the latest supplied vendor patches.

—————————————————————————————————————————————-
6. Time Line

12/17/2012 Reported Vulnerability to the Vendor
01/03/2013 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
7. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

Overview
——————-
Certain Lexmark devices are vulnerable to unverified password changes and stored cross-site scripting attacks.

Description:
——————-
Unverified Password Change – CVE-2013-6032
Certain models of Lexmark laser printers and MarkNet devices are vulnerable to an attack which allows a remote unauthenticated attacker to change the administrative password of the printer’s web administration interface. The interface does not perform sufficient validation of the vac.255.GENPASSWORD parameter in POST requests to the /cgi-bin/postpf/cgi-bin/dynamic/config/config.html page, allowing an unauthenticated remote attacker to reset the administrative password to an empty string.

Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) – CVE-2013-6033
Certain models of Lexmark laser printers are vulnerable to stored cross-site scripting attacks. The printers’ administrative web interface does not perform sufficient validation of user input to the “Location” and “Contact Name” fields in the “General Settings” configuration page.

Impact:
——————-
An attacker may be able to run arbitrary script in the context of a victim’s browser. The attacker may also be able to gain full administrative control of the printer.

Solution:
——————-
Apply an Update

Lexmark advises users to update to the latest firmware version. A list of affected models and firmware versions, as well as accompanying fixes, can be found at Lexmark’s advisory page.
Vendor Information: http://support.lexmark.com/alerts/

CVSS Metrics:
——————-
Group Score Vector
Base 9.0 AV:N/AC:L/Au:N/C:P/I:P/A:C
Temporal 7.4 E:F/RL:OF/RC:C
Environmental 1.9 CDP:N/TD:L/CR:ND/IR:ND/AR:ND

Vendor Date Notified: 16 Oct 2013

I was informed last month of the release of the new “Faraday” penetration testing framework. A key feature of this framework is its ability to parse the output from various other security tools, including Foofus.Net’s Medusa! Here is the official release from the Infobyte folks:

We are happy to announce our first release of Faraday (beta), an open source collaborative Penetration Test IDE console that uses the same tools you use every day.

Faraday introduces a new concept (IPE) Integrated Penetration-Test Environment

We built a plugin system, where all the I/O from the terminal gets interpreted, if we have a plugin for the command, the output is processed and added to a knowledge base in a transparent way.

Our idea was to build a tool that helps from the perspective of a pentester without changing the way you work, adding the support for multi user collaboration on security testing projects.

Developed with a specialized set of functionalities that help users improve their own work adding collaborative data sharing, indexation and analysis of the generated knowledge during the engagement of a security audit.

[Features]
* +40 Plugins (Metasploit, Amap, Arachini, Dnsenum, Medusa, Nmap, Nessus, w3af, Zap and More!)
* Collaborative support
* Information Highlighting
* Knowledge Filtering
* Information Dashboard
* Conflict Detection
* Support for multiple Workspaces
* IntelliSense Support
* Easy Plugin Development
* XMLRPC, XML and Regex Parsers

Get it now:
http://www.faradaysec.com
https://github.com/infobyte/faraday

[Contact]
@faradaysec
#faraday-dev on irc.freenode.net

We hope you enjoy it!

Francisco Amato
http://www.linkedin.com/in/famato
http://twitter.com/famato

Infobyte LLC.
2699 S. Bayshore Dr #300.
[33133], Miami, FL
Phone: +1 305 851 3373
http://www.infobytesec.com
http://blog.infobytesec.com
http://twitter.com/infobytesec