Madrock

The problem has been discovered in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.

In addition to the unpatched hole in Internet Explorer, a now published hole in Windows allows users with restricted access to escalate their privileges to system level – and this is believed to be possible on all 32-bit versions of Windows from Windows NT 3.1 up to, and including Windows 7. While the vulnerability is likely to affect home users in only a minor way, the administrators of corporate networks will probably have their hands full this week.

The problem is caused by flaws in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.

Ormandy has also published a suitable exploit which functions under Windows XP, Windows Server 2003 and 2008, Windows Vista and Windows 7. When tested by the The H’s associates at heise Security, the exploit opened a command prompt in the system context, which has the highest privilege level, under Windows XP and Windows 7. No patch has become available, although Ormandy reports that Microsoft was already informed of the hole in mid 2009. The developer decided to publish the information regardless because, in his opinion, there is a simple workaround: to disable the MS-DOS subsystem.

The workaround requires users to start the group policy editor and enable the “Prevent access to 16-bit applications” option in the Computer Configuration\Administrative Templates\Windows Components\Application Compatibility section. When tested with these settings by the heise Security team, the exploit no longer functioned. The settings reportedly don’t cause any major compatibility problems for most users while no 16-bit applications are being used.

Update – The above option is only available through the group policy editor on Windows 2003 systems. Some versions of Windows do not include a group policy editor. As an alternative, users can also create a registry key under \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat with a D-Word value of VDMDissallowed = 1. Under Windows XP, to prevent the system from being vulnerable to the exploit, users can place the following text:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

“VDMDisallowed”=dword:00000001

into a file called vdmdisallow.reg and double click the file. Windows will then automatically import the key (admin rights are required to perform this action).

Update 2 - Microsoft has now confirmed the privilege escalation hole in Windows. The company says that it wants to complete its investigation of the vulnerability and will then decide whether, how and when to close it.

See Also:

• Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack, security advisory from Travis Ormandy.

REDMOND — When it rains, it pours. Especially in the Seattle area. Tavis Ormandy has published full details on a privilege escalation hack of all versions of Windows including Windows 7.

The exploit takes advantage of a bug in the Windows implementation of the ‘virtual DOS machine’ used to run legacy 16-bit programs. The exploit can be avoided by turning the VDM ‘feature’ off but the danger of course is that enough Windows lusers won’t know about the bug and/or bother turning the ‘feature’ off.

16-bit applications need BIOS support; the Windows kernel supports virtual BIOS interrupts in its ‘Virtual-8086′ mode monitor code. The code is implemented in two stages. The #GP trap handler transitions to the second stage when CS:EIP faults with specific ‘magic’ values.

The transition requires (subsequent to authentication) restoring the context and the call stack from the faulting trap frame. But the authentication process is flawed, relying as it does on three incorrect assumptions.

• Setting up a VDM context requires SeTcbPrivilege.The barrier to getting a VDM context can be subverted by requesting the NT VDM subsystem and then using CreateRemoteThread() to run code in the context of the VDM subsystem. The VDM subsystem already has the necessary flag set.
• Ring 3 (unprivileged) code cannot install arbitrary code segment selectors.Using the two least significant bits of CS/SS to calculate the privilege of a task doesn’t work when it comes to Virtual-8086 mode. The 20-bit addressing (by adding CS << 4 to the 16-bit IP) is also used to map onto the protected linear Virtual-8086 address space. If CS can be set to an arbitrary value, then the privilege calculation can be circumvented.
• Ring 3 (unprivileged) code cannot forge a trap frame.Returns to user mode are through IRET. An invalid context can cause IRET to fail pre-commit, which in turn forges a trap frame. And even with address randomisation it’s trivial to use NtQuerySystemInformation() to obtain the address of the second stage BIOS handler.

Affected Systems

This bug dates back 17 years and affects all systems released since 27 July 1993 – Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7. See the links below for further details.

See Also
MITRE: CVE-2010-0232
Windows plagued by 17-year-old privilege escalation bug
NEOPHASIS: Trap Handler Allows Users to Switch Kernel Stack

This is a presentation I gave on SCADA security some time ago. It was originally set for about 2 hrs, although I broke it into 2 halves so if time permitted (or the partisipants wanted more inforamation), the backend of the presentation has many more areas and guidence relaing to SCADA, devices, environment security, etc.

I defined the following outcomes for the presentation:

• Broaden the awareness and necessity of security within the SCADA environment.
• Understanding of business role in the governance/risk identification process.
• Heighten the understanding of technology risks.

I hope people find the material interesting and useful.

SCADA Security Presentation Derek Grocke

I have been working in the SCADA engineering, network design, project governance and security area for lots of years.

As a result I have many documents and techniques I will be sharing here. This is the first of many documents which I hope others will find informative and help others to understand and shape their approach to these environments.

Local file

SCADA Presentation

A cool document I thought I would share. It shows some good understanding and presents some good ideas.

General Questions

• How can users gain access to the SCADA application?
• Objective to consolidate access to all information sources – i.e. to make access available to all users via a single interface
• Are any RAS modems utilised within the SCADA environment?
• Is the RAS call back feature utilised?
• Is the mandatory RAS encryption feature used?
• Are users allowed multiple attempts at authentication on the RAS?
• Has the RAS auditing feature been enabled?
• How is access between the business / corporate network and SCADA network controlled?
• How is the administrator password controlled?
• How is vendor access to the SCADA network controlled – i.e. password changes after contract has been completed?
• Are SLA’s for outsourced support agreements reviewed on a periodic basis?
• Are critical components of the SCADA Network supported by a UPS and are these batteries tested on a regular basis to ensure that they are reliable?
• What capacity management and monitoring of critical SCADA network systems is performed (i.e. CPU utilisation and hard disk drive space)?
• Are legal captions utilised during the login process to the SCADA application and associated infrastructure / devices?
• Has an intrusion detection system (IDS) been deployed within the SCADA environment?
• Has security been a focus within the development and deployment of the SCADA network?
• Is there additional staff screenings performed when staff are hired to work within the SCADA environment (inclusive of vendors etc)?

Policies & Procedures

• Is there a defined security strategy for the SCADA environment?
• Who is responsible / accountable for security management within SCADA environment? Has the ownership of this responsibility been clearly defined and/or stated in any documentation?
• Are there any periodic security reviews of the SCADA network performed?
• What procedures are in place to handle the disposal of SCADA network media and devices? Additionally, is there a process in place for the disposal of confidential information / documentation?
• Are there any policies or procedures covering the introduction of new devices to the SCADA environment?
• What formal change control procedures exist for the SCADA environment?
• Does a formal disaster recovery plan exist for the SCADA environment?
• Does a formal business continuity plan exist for the SCADA environment?
• Do physical and logical security standards differ significantly between SCADA sites?
• Has a standard operating environment (SOE) minimum baseline standard been developed for systems being introduced into the SCADA environment?
• What security logs are maintained for critical computer equipment and how often are the logs reviewed?
• Who is responsible for the reviewing of security logs?
• Has access to event logs been restricted?
• Upon commencement of employment, are users provided with IT security information as part of the induction process? Additionally, are users provided with further information on security issues on a periodic basis?
• What procedures exist to monitor dial-in access?
• Is there a formally defined backup and recovery procedure?
• Are encryption techniques and/or passwords applied to backup tapes?

Physical Access

• How is physical access to SCADA terminals controlled?
• Are SCADA control rooms segregated from other rooms?
• What building security exists at remote sites to prevent unauthorised access?
• What authentication methods are used at remote sites to allow access – i.e. swipe cards?
• Are external windows at remotes sites barred?
• What alarm systems have been employed at remote sites?

Network Security

• Have all deployed routers been configured to ensure the filtering of communications that are unauthorised or not required?
• What traffic control and monitoring capabilities have been deployed – i.e. all communication travels to a central point before traversing further on the network.
• How are dial-in facilities to the SCADA environment secured?
• How is suspicious or unusual activity on the SCADA WAN detected?
• What firewall configurations have been set up to segregate the SCADA WAN from the United Water corporate network?
• Are all key filtering devices on the network (such as routers and firewalls) configured to log all attempts to access the network? If so are they reviewed on a regular basis?
• Have the auditing features of all routers and firewalls been enabled?
• Has access to event logs been restricted?
• How is the management of patches / hot fixes controlled in regards to firewalls and routers?
• What backup and recovery measures are in place for network resources – firewalls and routers?
• Has SNMP been implemented on core infrastructure?
• Has any wireless equipment been deployed within the SCADA environment – has this been configured to a secure state?
• Are all default passwords removed from SCADA devices after implementation?
• Does a development environment exist to test changes prior to deployment into the SCADA network production environment?

Workstation Security

• What operating systems (version) are installed on SCADA terminals?
• Have operating system level passwords been activated on all SCADA terminals?
• Do passwords have an indefinite expiry date?
• What file and directory permission controls have been implemented on SCADA terminals to restrict unauthorised access by general users?
• What logs are generated at the operating system level?
• Has access to event logs been restricted?
• What tools and services at the operating system level have been restricted for general users?
• Who is responsible for patch management of SCADA terminals?
• Has an audit feature been enabled for all SCADA terminals?
• Are default services available with the operating system restricted?
• Is virus protection implemented? Is this software manually or automatically updated?
• Are shares enabled on SCADA terminals / workstations?
• Are SCADA terminals backed up on a regular basis?
• Is registry auditing of SCADA terminals performed?
• Are user reviews and associated access rights performed on a regular basis?

SCADA Application Security

• What are the username and password requirements of SCADA application?
• Are session time out features activated?
• Are complex passwords enforced to access the SCADA application?
• Are user reviews and associated access rights performed on a regular basis?

System Penetration Testing

• Internal penetration testing
• External penetration testing
• Password strength tests

Changes to the SCADA network

• Please provide / list all potential changes being considered to the SCADA network.

Procedures

• Corporate Information Protection
• Security Management
• Information Classification
• Physical (and Environmental) Security
• Personnel Security
• Security Awareness Training
• Security Incident Response
• Security Monitoring
• Network Security
• PC/Workstation Security
• Support and Operational Security Related
• Encryption and Information Confidentiality
• Authorization Controls
• Identification and Authentication Mechanisms
• Systems Life Cycle Security
• Business Continuity Planning
• Media Security
• Third Party Services

Typical concerns and points discussion:

• Inbound and out Bound FTP
• Suggest use of DMZ
• Suggest use of Secure FTP
• Suggest use of restricted secure IP addresses / tunnelling
• Suggest use of private feeds

Modem issues used with dial in services

• No dial back
• No Authentication
• No Secure ID
• Possibly automated scripts used, so hard coded usernames and passwords used.
• Internet sharing may be turned on, allowing routing via workstations.

Increased data security and integrity considerations

• Data backups
• System redundancy
• Site and content filtering
• Virus protection
• Standard system procurement (discounts and spares)
• Network and services redundancy
• Network monitoring
• Service availability monitoring
• Internal controls
• Vendor / external service supplier
• Capacity management
• Change management system
• Asset management system
• Telecommunication and telephony bulk cost discounting
• Etc.

Use and support for corporate application considerations

• Email
• Intranet
• Internet
• Corporate virus protection
• Asset management
• Change management
• Project management
• Performance / capacity management
• Reduction of Cost
• Use of corporate applications
• Reduction of manual processes

Other things to keep in mind:

• SCADA monitoring system must be isolated from network errors and systems events. This will prevent SCADA operational systems being effected by network or corporate system issues / outages.
• Review Network topology to ensure internal and external vulnerabilities are not currently being and cannot be abused.
• Review of router configurations
• Use of change management system
• Review remote dial in systems
• Firewall SCADA systems off from corporate applications
• Uncontrolled networks and systems within the SCADA environment will compromise the corporate environments integrity and security.
• Determine if systems used within SCADA are built to a standard operating environment.

This is Great, I want one of these cards and a list of ATM’s.

http://www.sophos.com/blogs/gc/g/2009/03/18/details-diebold-atm-trojan-horse-case/

http://www.theregister.co.uk/2009/03/17/trojan_targets_diebold_atms/

From the Security Now Podcast http://www.grc.com/sn/sn-200.htm

Hi,

Recently I a questing was asked on another post relating to DUKPT. Given I have lots of material on the subject I thought I would create this thread. Link

I will come back at some stage and expand on this when I get time.

Transaction Process narrative:

The diagram describes a mobile terminal/ATM is described using the a AS2805 (‘2805′) message type and 3DES DUKPT and dual direction auth SSL from the terminal to the aquirer (transaction switch).

A good explanation of DUKPT can also be found at Wikipedia.

Diagram of the flow

DUKPT transaction flow - terminal to bank

Background notes:

• The terminal or ATM firstly encrypts the user entered pin (may be a unique DUKPT key or static, depending on the design and banks involved) prior to incorporating it into the AS 2805 transaction message.
• the message is then encrypted again using the DUKPT key which has been established through the merchant logon process within the aquirer Host Security Module (HSM) i.e. the user entered pin is encrypted separately and encapsulated within the DUKPT encrypted 2805 message to provide full message encryption.
• In the diagram a separate dual authenticating SSL session is also used between the terminal/ATM and the aquirers infrastructure. This allowing the transaction including the pin to traverse the external Wired/GPRS/LAN within 2 primary independent layers of encryption, with a 3^rd protecting the PIN.
• When the transaction enters the aquirer environment the message encapsulation layer provided by SSL is removed.  This leaving the DUKPT’ed 2805 message which also encapsulates the separately encrypted PIN.
• This encrypted message is passed to the aquirer switch engine through to the aquirer’s HSM for decryption of the 2805 message excluding the user entered pin.
• This is when transactional information necessary for aquirer’s merchant reporting (truncated card number, transaction amount, transaction type, etc.) and fraud management data is collected.
• The aquirer switch then passes the encrypted PIN to the aquirer HSM requesting that the PIN be decrypted using the aquirer’s PIN encryption and translated to the next banks (Bank 1)  PIN Encryption Key (Pin translation only occurs within the aquirer HSM) This is then sent back to the aquirer Switch engine as the Bank 1 encrypted PIN.
• The aquirer switch engine then send the decrypted 2805 message with the newly encrypted PIN back to aquirer HSM to be encrypted with the Bank 1 MAC key.
• The resultant Bank 1 key encrypted message is then sent to Bank 1 for processing and/or passing to the card issuer (using a similar process as described above).
• When the result is received back from the issuing bank it is encrypted with the Bank 1 MAC key (the pin will not be present in the result message).
• This is then decrypted by the aquirer HSM, the transaction fate result stored into the aquirer merchant reporting system and the transaction fate re-encrypted with the original aquirer DUKPT key (should be different per terminal/merchant instance) and the result sent back to the terminal through the original established SSL encrypted terminal connection.

The aquirer may terminate the the SSL connection on a hardware device such as a CISCO Content Service Switch (CSS), or equivalent instead of the design described in the diagram which terminates onto a SSL session server/gateway (Possibly including a Certificate Authority) or on the aquirer transaction switch.

When PIN blocks are received by the aquirer processing centre, the PIN encryption is translated from the terminal key to the Local Master Key (LMK) by the Host Security Modules (HSM).

When the message is sent on the upstream bank interchange link to the issuer or gateway , the aquirer HSM translates the encrypted PIN block from the LMK to the Zone Master Key (ZMK) of the aquirer interchange link. The PIN block is always encrypted using DEA3 (3DES) whenever outside of the Terminal or ATM.

HSM-8000-User Guide V2.2

From Pentestmonkey.net, this is a great list of SQL Injection cheat sheets.

• Oracle
• MSSQL
• MySQL
• PostgreSQL
• Ingres
• DB2
• Informix

Some more Links:

SQL Injection Attacks by Example

Pangolin – Automatic SQL Injection Tool

SQL Injection Attacks Exploiting Unverified User Data Input

SQL Injection Cheat Sheet

Hi,

I have been putting some secure application development documents together recently and have found some good general tutorials and guidelines which I thought I would post here.

Best Practices

• The Ten Most Critical Web Application Security Vulnerabilities, 2004 Update, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/topten
• A Guide to Building Secure Web Applications, The Open Web Application Security Project. URL: http://www.owasp.org/documentation/guide
• Improving Web Application Security: Threats and Countermeasures, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/ThreatCounter.asp
• Authentication in ASP.NET: .NET Security Guidance, Microsoft MSDN. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/authaspdotnet.asp
• Session Fixation Vulnerability in Web-Based Applications, ACROS Security. http://www.acros.si/papers/session_fixation.pdf
• Writing Secure Code, Michael Howard and David LeBlanc, Microsoft Press.
• Threat Modelling, Window Snyder, Microsoft Press.
• 10 Things You Shouldn’t Do with SQL Server (Data Access Developer “Don’ts”) http://www.dotnetjunkies.ddj.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
• Ten dos and don’ts for secure coding http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1172049,00.html
• Cross Site Scripting http://www.cert.org/archive/pdf/cross_site_scripting.pdf http://www.acunetix.com/websitesecurity/cross-site-scripting.htm
• The Cross Site Scripting (XSS) FAQ http://www.cgisecurity.com/articles/xss-faq.shtml
• XSS (Cross Site Scripting) Cheat Sheet http://ha.ckers.org/xss.html
• SQL Injection Cheat Sheet http://ha.ckers.org/blog/20070315/sql-injection-cheat-sheet/

Other Resources

• AusCERT is the national Computer Emergency Response Team for Australia http://www.auscert.org.au/
• SANS Institute http://www.sans.org/free_resources.php