Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

See my follow up email first.

Are you asserting that your entire basis for what "risk" is comprised of is the 
number of new vulnerabilities found in code?   Risk=code vulnerabilities?  
Please tell me you know more about this industry than that.   Actually, DON'T 
tell me that.  I don't want to start to feel more sorry for you than I already 
do.

We don't need six months.  Pick whatever 100 you want.  Come up with your risk 
factor.  I'll deploy them, and they will be 100% vulnerable to immediate 
"exploitation" and I'll laugh at your "risk figures" all the way to the bank.   
 This is getting better by the minute.

Care to up your bet?  I'll wager 4:1 for you.  Let's make it my $100k to your 
$25k, even though you've already set the terms and the amount in writing 
previously.  I'm happy to amend this.

t

From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
Sent: Tuesday, February 09, 2010 10:28 PM
To: Thor (Hammer of God); valdis.kletni...@vt.edu
Cc: pen-t...@securityfocus.com; 'full-disclosure'; 
security-bas...@securityfocus.com
Subject: RE: [Full-disclosure] SMS Banking

I will happily do this.

"That it can be hacked, or will be hacked"
Anything CAN be hacked.

Software first. Choose 100 common software products. I will define scale here 
first. This will be number of vulnerabilities (new) that are found in each 
piece of software each month. This will also be related to the common metrics 
for the level of the vulnerability. This will be for 6 months. Choose the 
number of vulnerabilities and the impact of each of these for 6 months. It has 
to be commonly run software with a user base that I cannot count on one hand.

My predictions will be for these products and will have a confidence bound set 
at 95% (or alpha=5%).

"I further assume that the "loser" will be financially responsible for the 
"audits" done my way."
Are you saying that you will pay MY fees when you lose?

"won't look at the software code"
When you can get MS to give me their code this may be an issue, but it is not 
as yet.

Regards,
...
Dr. Craig S Wright GSE-Malware, 
GSE-Compliance, LLM, & ...
Information Defense Pty Ltd


From: Thor (Hammer of God) [mailto:t...@hammerofgod.com]
Sent: Wednesday, 10 February 2010 3:59 PM
To: craig.wri...@information-defense.com; valdis.kletni...@vt.edu
Cc: pen-t...@securityfocus.com; 'full-disclosure'; 
security-bas...@securityfocus.com
Subject: RE: [Full-disclosure] SMS Banking

Now you're talking.  But first let's work up an actual contract.  Neither of 
your components define anything.  When you say that you are going to predict 
"risk" with your  magic formula, do you mean if the software has 
vulnerabilities?   That it can be hacked, or will be hacked?

Be sure to define this properly and definitively - if you end up saying that a 
system has a 1% change of being hacked, and I (or my auditors) hack it, would 
you claim you were "right"?  I question if you can even define the parameters 
of this bet, much less apply your formulas, but we'll see.

I also want to know what "scale" you plan to use.  So far, even though I've 
asked, you've not provided what the "answer" to your formula is, or how it will 
be applied.   I'm assuming, unless you are going to change your tune which I 
wouldn't doubt, that you won't look at the software code or threat models, but 
rather apply your formulas.  I further assume that the "loser" will be 
financially responsible for the "audits" done my way.

I'm more than happy to take your money, and I look forward to doing so.
Since one of your masters degrees is in law, I'm assuming you can clearly 
define the terms of the contract.I will, of course, insist upon a contract, 
and I hope you won't mind that I have my own attorney look it over.I'm not 
immediately trusting of the competence of one with a doctorate degree and 
multiple masters degrees who can't spell "technology" or "experience" correctly 
on his on-line CV.

You are officially "on."  And I'm looking forward to it.

t



From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
Sent: Tuesday, February 09, 2010 7:41 PM
To: valdis.kletni...@vt.edu; Thor (Hammer of God)
Cc: pen-t...@securityfocus.com; 'full-disclosure'; 
security-bas...@securityfocus.com
Subject: RE: [Full-disclosure] SMS Banking


I have a simple answer to this. Forget the debate, rhetoric is not a scientific 
method of determining truth.

"Thor" wants a challenge, let's have one - a real one and not one based on 
verbalisations, abuse and unfounded assertions.

I suggest two components;

1   A selection of software products are tested using both processes, that 
is I use a model for the risk of these products, and "Thor" can make up 
whatever guesses he wishes. We model (or "Thor" guesses, pulls from a hat...) 
the vulnerabilities over a time period. The number of bugs in software as well 
as the risk are to be presented 

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

Actually, I'll make it even easier for you...

You pick the 50 software packages- I don't care which.  You use your formulas 
to calculate the "risk" of deploying them on the internet.

As per your instructions, which were in writing when you put up your $10,000, 
"Thor does whatever he wants."  I will illustrate "real world" deployment 
issues that will lead to full compromise of all 50, count them, 50 (That's 100% 
- thought I would save you the trouble of getting out your calculator) software 
packages.

Your formulas cannot, and will not, be able to factor in the human element, 
particularly when I get to do "whatever I want."

And please don't try to change the terms, Craig.   I have to say that because 
the last time I bothered with you, (when you tried to tell me IPSec was an 
authentication protocol like NTLM or that Rainbow Tables worked on NTLMv2) you 
wiggled about a bit.

Can we do this live?  If I lose, I'll pay for your plane ticket to Vegas.

t



From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of 
God)
Sent: Tuesday, February 09, 2010 8:59 PM
To: craig.wri...@information-defense.com; valdis.kletni...@vt.edu
Cc: 'full-disclosure'; pen-t...@securityfocus.com; 
security-bas...@securityfocus.com
Subject: Re: [Full-disclosure] SMS Banking

Now you're talking.  But first let's work up an actual contract.  Neither of 
your components define anything.  When you say that you are going to predict 
"risk" with your  magic formula, do you mean if the software has 
vulnerabilities?   That it can be hacked, or will be hacked?

Be sure to define this properly and definitively - if you end up saying that a 
system has a 1% change of being hacked, and I (or my auditors) hack it, would 
you claim you were "right"?  I question if you can even define the parameters 
of this bet, much less apply your formulas, but we'll see.

I also want to know what "scale" you plan to use.  So far, even though I've 
asked, you've not provided what the "answer" to your formula is, or how it will 
be applied.   I'm assuming, unless you are going to change your tune which I 
wouldn't doubt, that you won't look at the software code or threat models, but 
rather apply your formulas.  I further assume that the "loser" will be 
financially responsible for the "audits" done my way.

I'm more than happy to take your money, and I look forward to doing so.
Since one of your masters degrees is in law, I'm assuming you can clearly 
define the terms of the contract.I will, of course, insist upon a contract, 
and I hope you won't mind that I have my own attorney look it over.I'm not 
immediately trusting of the competence of one with a doctorate degree and 
multiple masters degrees who can't spell "technology" or "experience" correctly 
on his on-line CV.

You are officially "on."  And I'm looking forward to it.

t



From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
Sent: Tuesday, February 09, 2010 7:41 PM
To: valdis.kletni...@vt.edu; Thor (Hammer of God)
Cc: pen-t...@securityfocus.com; 'full-disclosure'; 
security-bas...@securityfocus.com
Subject: RE: [Full-disclosure] SMS Banking


I have a simple answer to this. Forget the debate, rhetoric is not a scientific 
method of determining truth.

"Thor" wants a challenge, let's have one - a real one and not one based on 
verbalisations, abuse and unfounded assertions.

I suggest two components;

1   A selection of software products are tested using both processes, that 
is I use a model for the risk of these products, and "Thor" can make up 
whatever guesses he wishes. We model (or "Thor" guesses, pulls from a hat...) 
the vulnerabilities over a time period. The number of bugs in software as well 
as the risk are to be presented as a monthly estimate.

2   We model a few systems (say 50). We can use Honeypots (real systems set 
to log all activity without interference) run by an independent party to each 
of us. I use probabilistic models to calculate the risk. "Thor" does whatever 
he wants.

Each of the predictions is published by all parties. The one who is most 
accurate wins. Fairly simple?

I will even give a handicap to "Thor", I will offer to predict within a 95% 
confidence interval and that for me to win, at least 90 of the 100 software 
products and 45 of the 50 systems have to lie within my predicted range that I 
calculate and release. "Thor" has to simply guess better than I do no matter 
how far out he is.

I will put up $10,000 Au for my side. Let's see if "Thor" has something real to 
offer.

Regards,

...

Dr. Craig S Wright GSE-Malware, 
GSE-Compliance, LLM, & ...

Information Defense Pty Ltd

_
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
Sent: Wednesday, 10 February 2010 7:03 AM
To: Thor (Hammer of God)
Cc: pen-t...@securityf

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

Now you're talking.  But first let's work up an actual contract.  Neither of 
your components define anything.  When you say that you are going to predict 
"risk" with your  magic formula, do you mean if the software has 
vulnerabilities?   That it can be hacked, or will be hacked?

Be sure to define this properly and definitively - if you end up saying that a 
system has a 1% change of being hacked, and I (or my auditors) hack it, would 
you claim you were "right"?  I question if you can even define the parameters 
of this bet, much less apply your formulas, but we'll see.

I also want to know what "scale" you plan to use.  So far, even though I've 
asked, you've not provided what the "answer" to your formula is, or how it will 
be applied.   I'm assuming, unless you are going to change your tune which I 
wouldn't doubt, that you won't look at the software code or threat models, but 
rather apply your formulas.  I further assume that the "loser" will be 
financially responsible for the "audits" done my way.

I'm more than happy to take your money, and I look forward to doing so.
Since one of your masters degrees is in law, I'm assuming you can clearly 
define the terms of the contract.I will, of course, insist upon a contract, 
and I hope you won't mind that I have my own attorney look it over.I'm not 
immediately trusting of the competence of one with a doctorate degree and 
multiple masters degrees who can't spell "technology" or "experience" correctly 
on his on-line CV.

You are officially "on."  And I'm looking forward to it.

t



From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
Sent: Tuesday, February 09, 2010 7:41 PM
To: valdis.kletni...@vt.edu; Thor (Hammer of God)
Cc: pen-t...@securityfocus.com; 'full-disclosure'; 
security-bas...@securityfocus.com
Subject: RE: [Full-disclosure] SMS Banking


I have a simple answer to this. Forget the debate, rhetoric is not a scientific 
method of determining truth.

"Thor" wants a challenge, let's have one - a real one and not one based on 
verbalisations, abuse and unfounded assertions.

I suggest two components;

1   A selection of software products are tested using both processes, that 
is I use a model for the risk of these products, and "Thor" can make up 
whatever guesses he wishes. We model (or "Thor" guesses, pulls from a hat...) 
the vulnerabilities over a time period. The number of bugs in software as well 
as the risk are to be presented as a monthly estimate.

2   We model a few systems (say 50). We can use Honeypots (real systems set 
to log all activity without interference) run by an independent party to each 
of us. I use probabilistic models to calculate the risk. "Thor" does whatever 
he wants.

Each of the predictions is published by all parties. The one who is most 
accurate wins. Fairly simple?

I will even give a handicap to "Thor", I will offer to predict within a 95% 
confidence interval and that for me to win, at least 90 of the 100 software 
products and 45 of the 50 systems have to lie within my predicted range that I 
calculate and release. "Thor" has to simply guess better than I do no matter 
how far out he is.

I will put up $10,000 Au for my side. Let's see if "Thor" has something real to 
offer.

Regards,

...

Dr. Craig S Wright GSE-Malware, 
GSE-Compliance, LLM, & ...

Information Defense Pty Ltd

_
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
Sent: Wednesday, 10 February 2010 7:03 AM
To: Thor (Hammer of God)
Cc: pen-t...@securityfocus.com; full-disclosure; 
craig.wri...@information-defense.com
Subject: Re: [Full-disclosure] SMS Banking

* PGP Signed by an unknown key

On Tue, 09 Feb 2010 17:39:39 GMT, "Thor (Hammer of God)" said:

> how about accepting a challenge to an open debate on the subject at Defcon?

"Alright folks just make yourself at home, Have a snow cone and enjoy the show"

-- Webb Wilder


* Unknown Key

* 0xB4D3D7B0
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Finding Domain Controllers for use with WinScanX using DCLookup.exe (source included)

[Bugtrace]

nltest.exe(Windows NT Resource Kit)

2010/2/10 Reed Arvin :
> WinScanX Pro is only $10.00 for the month of February (normally $250.00)
>
> WinScanX Basic (always free - only scans one host per run)
> http://www.windowsaudit.com/
>
> Article tool: DCLookup.exe (source included)
> http://windowsaudit.com/downloads/DCLookup.zip
>
> Original article link:
> http://windowsaudit.com/winscanx/finding-domain-controllers-for-use-with-winscanx/
>
> ==
>
> When performing a security assessment it’s important to have a plan of
> attack. All machines do not have the same level of criticality. For
> example, a missing patch on a Windows workstation will not be
> perceived as being as serious a flaw as a missing patch on a Windows
> domain controller. For a Windows assessment, one routine that I found
> useful was to target the following hosts in the following order:
>
> - Windows domain controllers
> - Windows servers
> - Windows workstations
>
> Locating Windows domain controllers can be a bit of a hassle
> sometimes, especially if you have no knowledge of the network you are
> assessing. If that is the case for you, the following may provide some
> help.
>
> DCLookup – Provides a list of domain controllers that are available to
> authenticate the current host
>
> Download at: http://windowsaudit.com/downloads/DCLookup.zip (source included)
>
> Usage:
>
> DCLookup.exe 
>
> DCLookup.exe 127.0.0.1
> DCLookup.exe MyMachine
>
> Example output:
>
> C:\>DCLookup.exe 127.0.0.1
>
> +++
> +         DC INFO VIA DsGetDcName         +
> +++
>
> Domain Controller Name:    \\site1dc06.company.corp
> Domain Controller Address: \\192.168.11.65
> Domain Name:               company.corp
> DNS Forest Name:           company.corp
>
> +++
> +  DC INFO VIA DsGetDomainControllerInfo  +
> +++
>
> NetBios Name:  site1DC01
> DNS Host Name: site1dc01.company.corp
>
> NetBios Name:  site1DC02
> DNS Host Name: site1dc02.company.corp
>
> NetBios Name:  site2DC01
> DNS Host Name: site2dc01.company.corp
>
> NetBios Name:  site3DC01
> DNS Host Name: site3dc01.company.corp
>
> NetBios Name:  site4DC01
> DNS Host Name: site4DC01.company.corp
>
> NetBios Name:  site5DC01
> DNS Host Name: site5DC01.company.corp
>
> NetBios Name:  site6DC04
> DNS Host Name: site6DC04.company.corp
>
> NetBios Name:  site1DC05
> DNS Host Name: site1dc05.company.corp
>
> NetBios Name:  site1DC06
> DNS Host Name: site1dc06.company.corp
>
> NetBios Name:  site1DC04
> DNS Host Name: site1dc04.company.corp
>
> +++
> +   DC INFO VIA DsEnumerateDomainTrusts   +
> +++
>
> NetBios Domain Name: TRUSTEDDOM
> DNS Domain Name:     trusteddom.corp
>
> What to do next:
>
> Once you have a list of domain controllers, the next step would be to
> start running various checks against them to assess their security
> stature. The following is a short assessment flow for a domain
> controller using WinScanX:
>
> 1. Using WinScanX, attempt to retrieve the account lockout threshold
> using the Get Account Policy Information feature against a domain
> controller.
>
> 2. If the account lockout threshold is not set or if it is 5 attempts
> or higher, attempt to retrieve the user information using the Get User
> Information or Get User Information via RA Bypass feature of WinScanX
> and run a quick password check using the Guess Windows Passwords
> feature.
>
> ***NOTE***
> Make sure to only use the Guess Windows Passwords feature on one
> domain controller ONLY. Using this feature on multiple domain
> controllers in the same domain may cause accounts to lock out.
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
Best Regards,
Trace

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Windows SMB NTLM Authentication Weak Nonce Vulnerability

[Hernan Ochoa]

(to get the scripts mentioned by this advisory please get the full
version at http://www.hexale.org/advisories/OCHOA-2010-0209.txt; I did
not include them here to reduce the size of this email)


Windows SMB NTLM Authentication Weak Nonce Vulnerability
Security Advisory
Hernan Ochoa (her...@gmail.com) - Agustin Azubel 
(agustin.azu...@gmail.com)


Title: Windows SMB NTLM Authentication Weak Nonce Vulnerablity
Advisory ID: OCHOA-2010-0209
Advisory URL: http://www.hexale.org/advisories/OCHOA-2010-0209.txt
Date published: 2010-02-09
Vendors contacted: Microsoft
Release mode: Coordinated release
Last Updated: 2010-02-09


Index
-

1.Vulnerablity information
2.Vulnerablity description
3.Vulnerable systems
4.Vendor Information, solutions and workarounds
5.Credits
6.Technical description
6.1.NTLMv1 authentication protocol
6.2.The Flaws
6.3.Detecting if the SMB service generates duplicate 8-byte challenges
6.4.Exploiting duplicate challenges
6.4.1.Proof-of-Concept Exploit
6.5.Predicting challenges
6.5.1.SMB service: challenge generation process
6.5.2.Proof-of-Concept Exploit
7.References
8.Disclaimer


1.Vulnerability information
---

Impact: An unauthenticated remote attacker without any kind of
credentials can access the SMB service under the credentials of an
authorized user. Depending on the privileges of the authorized user, and
the configuration of the remote system, an attacker can gain read/write
access to the remote file system and execute arbitrary code by using
DCE/RPC over SMB.
Remotely Exploitable: Yes
Bugtraq Id: 
CVE: CVE-2010-0231


2.Vulnerability description
---

Microsoft Server Message Block (SMB) Protocol is a Microsoft network
file sharing protocol also used for sharing printers, communications
abstractions such as named pipes and mailslots, and performing Remote
Procedure Calls (DCE/RPC over SMB) [1].

NTLM (NT Lan Manager) is a challenge-response authentication protocol
used by the SMB protocol [2].

Windows systems commonly use the SMB protocol with NTLM authentication
for network file/printer sharing and remote administration via DCE/RPC.

Flaws in Microsoft's implementation of the NTLM challenge-response
authentication protocol causing the server to generate duplicate
challenges/nonces and an information leak allow an unauthenticated
remote attacker without any kind of credentials to access the SMB
service of the target system under the credentials of an authorized
user. Depending on the privileges of the user, the attacker will be able
to obtain and modify files on the target system and execute arbitrary code.

3.Vulnerable Systems


This vulnerability was verified by the authors on the following platforms:

Windows NT4 SP1
Windows Server 2003 SP2
Windows XP SP3
Windows Vista x32
Windows 7 x32 RC

However, all versions of Windows implementing NTLMv1 are suspected to be
affected.

Microsoft, in their "Microsoft Security Bulletin Advance Notification
for February 2010" [3], list the following platforms as affected:

Windows 2000 SP4
Windows XP SP2 and SP3
Windows XP Professional x64 Edition SP2
Windows Server 2003 SP2
Windows Server 2003 x64 Edition SP2
Windows Server 2003 SP2 for Itanium-based systems
Windows Vista
Windows Vista SP1
Windows Vista SP2
Windows Vista x64 Edition
Windows Vista x64 Edition SP1
Windows Vista x64 Edition SP2
Windows Server 2008 x32
Windows Server 2008 x32 SP2
Windows Server 2008 x64 SP2
Windows Server 2008 x64 SP2
Windows Server 2008 for Itanium-based systems
Windows Server 2008 for Itanium-based systems SP2
Windows 7 x32

See [3] for more details.

Given that Windows NT 4 was relased in ~1996 this vulnerability has been
present for ~14 years. If it is confirmed this vulnerablity is also
present in older systems such as Windows NT 3.1, released in ~1993,
Windows NTLMv1 authentication mechanism could have been vulnerable for
~17+ years.


4.Vendor Information, Solutions and Workarounds
---

SMB NTLM Authentication Lack of Entropy Vulnerability - CVE-2010-0231
http://www.microsoft.com/technet/security/bulletin/ms10-012.mspx

5.Credits
-

This vulnerability was discovered by Hernan Ochoa (Independent
Information Security Consultant and Researcher) and it was researched by
Hernan Ochoa and Agustin Azubel (Independent Information Security
Consultant and Researcher).

6.Technical description


Microsoft Server Message Block (SMB) Protocol is a Microsoft network
file sharing protocol also used for sharing printers, communications
abstractions such as named pipes and mailslots, and performing Remote
Procedure Calls (DCE/RPC over SMB) [1].

NTLM (NT Lan Manager) is a challenge-response authentication protocol
used by the SMB protocol [2].

Windows systems commonly use the SMB protocol with NTLM authentication
for network file/printer sharing and remote administration vi

Re: [Full-disclosure] SMS Banking

[Valdis . Kletnieks]

On Tue, 09 Feb 2010 17:39:39 GMT, "Thor (Hammer of God)" said:
> how about accepting a challenge to an open debate on the subject at Defcon?

"Alright folks just make yourself at home, Have a snow cone and enjoy the show"
-- Webb Wilder



pgpUepClxHHDb.pgp
Description: PGP signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Trustwave's SpiderLabs Security Advisory TWSL2010-001

[Trustwave Advisories]

Trustwave's SpiderLabs Security Advisory TWSL2010-001:
Multiplatform View State Tampering Vulnerabilities

Published: 2010-02-08 Version: 1.1

SpiderLabs has documented view state tampering
vulnerabilities in three products from separate vendors.
View states are used by some web application frameworks to
store the state of HTML GUI controls. View states are
typically stored in hidden client-side input fields,
although server-side storage is widely supported.

The affected vendors generally recommend that client-side
view states are cryptographically signed and/or encrypted,
but specific exploits have not been previously documented.
These vulnerabilities show that unsigned client-side view
states will ALWAYS result in a vulnerability in the affected
products.

Credit: David Byrne of Trustwave's SpiderLabs


===
Vendor: Microsoft (http://www.microsoft.com)
Product: ASP.Net (http://www.asp.net)
Versions affected: .Net 3.5 is confirmed vulnerable;
previous versions are likely to be vulnerable as well.

Description:
ASP.Net is a web-application development framework that
provides for both user interfaces, and back-end
functionality.

The ASP.Net view state is typically stored in a hidden field
named "__VIEWSTATE". When a page's view state is not
cryptographically signed, many standard .Net controls are
vulnerable to Cross-Site Scripting (XSS) through the view
state.

It is well documented that using an unsigned view state is
"bad", but most previous advisories focus on vaguely
described threats or vulnerabilities introduced by custom
use of the view state. To the best of Trustwave's knowledge,
this is the first time a proof of concept attack of this
nature has been demonstrated against the view state. A
vulnerability was alluded to in a 2004 Microsoft article on
troubleshooting view state problems [1]. However, other
Microsoft documents recommend disabling view state signing
"if performance is a key consideration," [2, 3, 4] or for
various other reasons [5, 6]. Realistically, unsigned view
states should never be used in a production environment.

The following code is vulnerable to a XSS attack against the
form control. Note that the "ValidateRequest" setting does
not prevent the attack.

   <%@ Page EnableViewStateMac="False" 
   ValidateRequest="True" %>
   
  
   



If the following request is sent to the server, the response
will contain JavaScript that calls an alert box.

xss.aspx?__VIEWSTATE=/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxY
CHglpbm5lcmh0bWwFHTxzY3JpcHQ%2BYWxlcnQoJ3hzcycpPC9zY3JpcHQ%2
BZGQ=

The view state's XML equivalent is below:

   
   
 
   
 -834067820
 
   
 0
 
   
 1
 
   
innerhtml

   
 
   
 
   
 
   
 
   

The HTML response is below:
   
 
   
   
   
   alert('xss')
   

This example uses the "innerhtml" attribute of the form
control, although other attributes in other controls are
also vulnerable to similar attacks.


Remediation Steps:
The ASP.Net view state should always be cryptographically
signed with a "Message Authentication Code" (MAC). This has
been enabled by default since .Net 1.1, but can be disabled
using the "EnableViewStateMac" setting. Using the
"ViewStateUserKey" setting can also help to mitigate the
scope of this vulnerability. [7]




===
Vendor: Apache Software Foundation (http://www.apache.org)
Product: Apache MyFaces (http://myfaces.apache.org/)
Versions affected: 1.2.8 and 1.1.7 are confirmed as
   vulnerable. All previous versions are likely vulnerable.
Related products: Some versions of IBM WebSphere Application
   Server (at least 6.x and 7.x) ship with Apache MyFaces 
   [8,9]

Description:
MyFaces is an open source implementation of the JavaServer
Faces standard. JavaServer Faces [10] is a framework that
aids in developing user interfaces for web-based
applications.

When the application's view state is not encrypted, it is
possible for an attacker to supply a new or modified view
object as part of a request. The malicious view can contain
arbitrary HTML code (allowing Cross-Site Scripting), and
arbitrary Expression Language (EL) [11] statements that will
be executed on the server. The EL statements can be used to
read data stored in user-scoped session variables, and
application or server-scoped variables. Since these
variables should be inaccessible by the user, it is not
uncommon to store sensitive data in them.

Exploiting this vulnerability requires modification of the
serialized view object, which is not stored in a plaintext
format. The Deface tool[12] can be used to provide
proof-of-concept attacks.


Remediation Steps:
This vulnerability can be completely prevented by encrypting
the application's view state.[13] This should a

[Full-disclosure] Trustwave's SpiderLabs Security Advisory TWSL2010-001

[Trustwave Advisories]

Trustwave's SpiderLabs Security Advisory TWSL2010-001:
Multiplatform View State Tampering Vulnerabilities

Published: 2010-02-08 Version: 1.1

SpiderLabs has documented view state tampering
vulnerabilities in three products from separate vendors.
View states are used by some web application frameworks to
store the state of HTML GUI controls. View states are
typically stored in hidden client-side input fields,
although server-side storage is widely supported.

The affected vendors generally recommend that client-side
view states are cryptographically signed and/or encrypted,
but specific exploits have not been previously documented.
These vulnerabilities show that unsigned client-side view
states will ALWAYS result in a vulnerability in the affected
products.

Credit: David Byrne of Trustwave's SpiderLabs


===
Vendor: Microsoft (http://www.microsoft.com)
Product: ASP.Net (http://www.asp.net)
Versions affected: .Net 3.5 is confirmed vulnerable;
previous versions are likely to be vulnerable as well.

Description:
ASP.Net is a web-application development framework that
provides for both user interfaces, and back-end
functionality.

The ASP.Net view state is typically stored in a hidden field
named "__VIEWSTATE". When a page's view state is not
cryptographically signed, many standard .Net controls are
vulnerable to Cross-Site Scripting (XSS) through the view
state.

It is well documented that using an unsigned view state is
"bad", but most previous advisories focus on vaguely
described threats or vulnerabilities introduced by custom
use of the view state. To the best of Trustwave's knowledge,
this is the first time a proof of concept attack of this
nature has been demonstrated against the view state. A
vulnerability was alluded to in a 2004 Microsoft article on
troubleshooting view state problems [1]. However, other
Microsoft documents recommend disabling view state signing
"if performance is a key consideration," [2, 3, 4] or for
various other reasons [5, 6]. Realistically, unsigned view
states should never be used in a production environment.

The following code is vulnerable to a XSS attack against the
form control. Note that the "ValidateRequest" setting does
not prevent the attack.

   <%@ Page EnableViewStateMac="False" 
   ValidateRequest="True" %>
   
  
   



If the following request is sent to the server, the response
will contain JavaScript that calls an alert box.

xss.aspx?__VIEWSTATE=/wEPDwUKLTgzNDA2NzgyMA9kFgJmD2QWAgIBDxY
CHglpbm5lcmh0bWwFHTxzY3JpcHQ%2BYWxlcnQoJ3hzcycpPC9zY3JpcHQ%2
BZGQ=

The view state's XML equivalent is below:

   
   
 
   
 -834067820
 
   
 0
 
   
 1
 
   
innerhtml

   
 
   
 
   
 
   
 
   

The HTML response is below:
   
 
   
   
   
   alert('xss')
   

This example uses the "innerhtml" attribute of the form
control, although other attributes in other controls are
also vulnerable to similar attacks.


Remediation Steps:
The ASP.Net view state should always be cryptographically
signed with a "Message Authentication Code" (MAC). This has
been enabled by default since .Net 1.1, but can be disabled
using the "EnableViewStateMac" setting. Using the
"ViewStateUserKey" setting can also help to mitigate the
scope of this vulnerability. [7]




===
Vendor: Apache Software Foundation (http://www.apache.org)
Product: Apache MyFaces (http://myfaces.apache.org/)
Versions affected: 1.2.8 and 1.1.7 are confirmed as
   vulnerable. All previous versions are likely vulnerable.
Related products: Some versions of IBM WebSphere Application
   Server (at least 6.x and 7.x) ship with Apache MyFaces 
   [8,9]

Description:
MyFaces is an open source implementation of the JavaServer
Faces standard. JavaServer Faces [10] is a framework that
aids in developing user interfaces for web-based
applications.

When the application's view state is not encrypted, it is
possible for an attacker to supply a new or modified view
object as part of a request. The malicious view can contain
arbitrary HTML code (allowing Cross-Site Scripting), and
arbitrary Expression Language (EL) [11] statements that will
be executed on the server. The EL statements can be used to
read data stored in user-scoped session variables, and
application or server-scoped variables. Since these
variables should be inaccessible by the user, it is not
uncommon to store sensitive data in them.

Exploiting this vulnerability requires modification of the
serialized view object, which is not stored in a plaintext
format. The Deface tool[12] can be used to provide
proof-of-concept attacks.


Remediation Steps:
This vulnerability can be completely prevented by encrypting
the application's view state.[13] This should a

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

"I won't bow, I won't bend, I won't break.  I'll tough it out."  :)

t

> -Original Message-
> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> Sent: Tuesday, February 09, 2010 12:03 PM
> To: Thor (Hammer of God)
> Cc: pen-t...@securityfocus.com; full-disclosure;
> craig.wri...@information-defense.com
> Subject: Re: [Full-disclosure] SMS Banking
> 
> On Tue, 09 Feb 2010 17:39:39 GMT, "Thor (Hammer of God)" said:
> > how about accepting a challenge to an open debate on the subject at
> Defcon?
> 
> "Alright folks just make yourself at home, Have a snow cone and enjoy
> the show"
>   -- Webb Wilder

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

In line.

> "Exactly.  So, before the incident, you would have come up with Some
> Number
> and said, "this is your risk."  After the incident your number would
> (hopefully) change to Some Number + Some Other Number, and you could
> say
> "Oops.  Didn't think of that.  Sorry."
>
> Are you trying to be clueless? [R(t)-> 0] means that the system was
> inherently unreliable. That is no change before or after. I recommended
> a
> probability distribution that links to a financial model.

Well, if I arrive at clueless, it will definitely be because I tried.  Maybe 
you can teach me how to attain that disposition naturally.

So, ANY deployment of SQL server is inherently unreliable?  And the SMS model 
is also inherently unreliable. What system then is NOT inherently unreliable?  
Might we assume that your own formula falls into this category?


> " Fine.  Let's do it this way then.  We'll have someone implement an
> SMS
> solution for banking that we don't have anything to do with.  I'll
> assess
> risk my way, you assess risk with your calculator.  Since *someone* has
> to
> pay, are you saying that you are willing to assume responsibility for
> financial losses when your numbers come out wrong?"
>
> Yes simply I will. In case you have not as yet had a clue, I stated
> reliability limits towards 0. That means the SMS solution is inherently
> insecure.
>
> "So which is it?  Is quantifying the probability of compromise "fairly
> simple using a formula" or is it "not an economic function pure and
> simple?""
> Both.

Typical.

> " Since *someone* has to pay, are you saying that you are willing to
> assume
> responsibility for financial losses when your numbers come out wrong?"
> I am working on a hedging instrument at present, and yes, where I am
> paid to
> model systems I will negotiate for losses.

Excellent.  Bring your checkbook along with your math.

> So where are all the lives being lost through a banking app?

They are not.  They will be when you start consulting to CIP.  Do us a favor 
though, test it out on your own country first.  But let me know before you do, 
my friends David and Greg are in AU.


>
> "Surely as the most highly certified security professional in the world
> you
> don't need me, a mere working stiff, to find you a sponsor."
> If you want me there, yes. I work by the hour, I am not going to waste
> time
> paying for this "opportunity". How about you come to an IEEE
> conference?

So, the most highly certified security professional in the world, and the 
greatest global mind in computer security refers to an open debate where you 
could defend formulas that have been publically ridiculed and openly called 
ignorant as a "waste of time"?  I don't need to pay you to substantiate my 
claims, sir.  You just did it for free.

t


>
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
>
> -Original Message-
> From: Thor (Hammer of God) [mailto:t...@hammerofgod.com]
> Sent: Wednesday, 10 February 2010 7:05 AM
> To: craig.wri...@information-defense.com; pen-t...@securityfocus.com;
> 'full-disclosure'
> Subject: RE: SMS Banking
>
> > -Original Message-
> > From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
> > Sent: Tuesday, February 09, 2010 10:54 AM
> > To: Thor (Hammer of God); pen-t...@securityfocus.com; 'full-
> disclosure'
> > Subject: RE: SMS Banking
> >
> > First,
> > 'Thor', get me sponsored and I will be more than happy to debate you
> at
> > Defcon. Being in Au, it costs a little more for me to get there than
> a
> > simple interstate flight.
>
> Surely as the most highly certified security professional in the world
> you
> don't need me, a mere working stiff, to find you a sponsor.  As the
> greatest
> mind on the face of the globe, I'll leave that one for you to figure
> out.
>
> > I am happy to be an egoist. I am not an altruist, I invest, I do not
> > sacrifice. So no insult.
>
> No, we sacrifice for you.  Or will, that is, if you or your formulas
> have
> anything to do with real human safety.
>
> >
> > "Your "risk formula" is ridiculous." Why? How is IT different to all
> > other
> > aspects of life and the world. Why is it sacrosanct and unable to be
> > modelled? As for real experience, I have been doing this over several
> > decades. I may be teaching at CSU (csu.edu.au - gratuitous plug), but
> > that
> > is a side line, not what I do.
>
> Because it fails to take into account simple reality.  Risk is assessed
> as
> the result of human interaction, not calculated by some formula.
> Information security is about people as much as it is about technology.
> Your math fails here, and it fails grievously.  Have you ever been in
> love
> and acted out of that?  If so, then prove it mathematically.  Show me
> the
> variables that take into account human actions and reactions.
>
> > " What number would your formula have yielded 2 weeks before SQL
> > Slammer was
> > released?"
> > The sam

[Full-disclosure] TPTI-10-02: Microsoft Office PowerPoint Viewer TextCharsAtom Record Code Execution Vulnerability

[ZDI Disclosures]

TPTI-10-02: Microsoft Office PowerPoint Viewer TextCharsAtom Record Code 
Execution Vulnerability
http://dvlabs.tippingpoint.com/advisory/TPTI-10-02
February 9, 2010

-- CVE ID:
CVE-2010-0034

-- Affected Vendors:
Microsoft

-- Affected Products:
Microsoft Office PowerPoint Viewer

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 9439. 
For further product information on the TippingPoint IPS, visit:

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of Microsoft Office PowerPoint Viewer. User
interaction is required to exploit this vulnerability in that the target
must open a malicious PowerPoint PPT file.

The specific flaw exists in the handling of TextCharsAtom (0x0fa0)
records contained in a PPT file. Due to the lack of bounds checking on
the size argument an unchecked memcpy copies user-supplied data from the
file to the stack, overflowing key exception structures. Exploitation of
this vulnerability can lead to remote compromise of the affected system
under the credentials of the currently logged in user.

-- Vendor Response:
Microsoft has issued an update to correct this vulnerability. More
details can be found at:

http://www.microsoft.com/technet/security/Bulletin/MS10-004.mspx

-- Disclosure Timeline:
2009-10-29 - Vulnerability reported to vendor
2010-02-09 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Cody Pierce, TippingPoint DVLabs
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

> -Original Message-
> From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
> Sent: Tuesday, February 09, 2010 10:54 AM
> To: Thor (Hammer of God); pen-t...@securityfocus.com; 'full-disclosure'
> Subject: RE: SMS Banking
>
> First,
> 'Thor', get me sponsored and I will be more than happy to debate you at
> Defcon. Being in Au, it costs a little more for me to get there than a
> simple interstate flight.

Surely as the most highly certified security professional in the world you 
don't need me, a mere working stiff, to find you a sponsor.  As the greatest 
mind on the face of the globe, I'll leave that one for you to figure out.

> I am happy to be an egoist. I am not an altruist, I invest, I do not
> sacrifice. So no insult.

No, we sacrifice for you.  Or will, that is, if you or your formulas have 
anything to do with real human safety.

>
> "Your "risk formula" is ridiculous." Why? How is IT different to all
> other
> aspects of life and the world. Why is it sacrosanct and unable to be
> modelled? As for real experience, I have been doing this over several
> decades. I may be teaching at CSU (csu.edu.au - gratuitous plug), but
> that
> is a side line, not what I do.

Because it fails to take into account simple reality.  Risk is assessed as the 
result of human interaction, not calculated by some formula.  Information 
security is about people as much as it is about technology.  Your math fails 
here, and it fails grievously.  Have you ever been in love and acted out of 
that?  If so, then prove it mathematically.  Show me the variables that take 
into account human actions and reactions.

> " What number would your formula have yielded 2 weeks before SQL
> Slammer was
> released?"
> The same as at any time before the incident. SQL was a time degrading
> function similar to the SMS example. The end result is a reliability
> value
> [R(t)-> 0] that approaches 0 and is prone to catastrophic failure. The
> rate
> of failure being related to the no. of access paths, no. of systems and
> the
> number of users.

Exactly.  So, before the incident, you would have come up with Some Number and 
said, "this is your risk."  After the incident your number would (hopefully) 
change to Some Number + Some Other Number, and you could say "Oops.  Didn't 
think of that.  Sorry."

>
> "Where is the variable for unpatched systems?"
> This is a function of both local and remotely accessible services. Some
> of
> these are dependant. This calculation has to account for each of these
> services on the host as well as a vulnerability model for each service.
> I am
> publishing a paper on this later in the year.
>
> "What number do we plug in for malicious employee factorization?"
> A prior data from similar industries, areas etc.

So you just take historical data that may or may not have anything to do with 
anything, and apply it to your formula just because it is what has happened 
before?  Your source is from only reported incidents or discovered incidents?  
Does it take into account anything of value?  Are you saying that with all of 
your education, and your globally superior intellect, the only value-add you 
bring is to tell us what has already happened in the past?  Seems a bit obvious 
if you asked me irrespective of the fact that it's basically worthless in the 
absence of an assessment.


> Now, the real issue is that you (thor) seem to have this idea that
> multiplying risk is a function of multiplying one made up number by
> another
> made up number. The 'expert' who cannot be wrong.

Sure I can be wrong.  I'm wrong all the time - it gives me an opportunity to 
learn.  And I'm not the one who claims to be an "expert" Craig.  Let the 
readers of this thread look at my site and then yours to make that comparison.  
The actual proof in one's capacity to learn is simple.  No one who has actually 
done this in a meaningful way would ever think that they can quantify risk with 
a formula when they haven't even bothered to qualify it.  A child can read 
volumes of books on how to ride a bicycle and immerse themselves in the physics 
behind balance and force, and the way the cilia of the inner ear works to 
communicate movement to the brain.  But they will NEVER learn how to ride until 
they get on and start pedaling.   Let me know when you stop peddling and start 
to pedal.

>
> The example spanning this is simple, a single SMS based function with
> open
> access. This example was a trivial example in modelling. Firewalls and
> other
> choke points make calculations simpler, multiple paths offer
> complexity.
> What I see from this is that a lack of understanding = a dangerous
> level of
> ignorance.

I could not agree with you more, sir.  A lack of understanding does indeed 
equal a dangerous level of ignorance.  Which is why I so look forward to an 
open debate on this subject where I can hopefully intervene on the adoption of 
your formulas when human life is at stake.  Your formulas can't even b

[Full-disclosure] ZDI-10-017: Microsoft Office PowerPoint Viewer TextBytesAtom Record Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-017: Microsoft Office PowerPoint Viewer TextBytesAtom Record Remote Code 
Execution Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-10-017
February 9, 2010

-- CVE ID:
CVE-2010-0033

-- Affected Vendors:
Microsoft

-- Affected Products:
Microsoft Office PowerPoint Viewer

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 9438. 
For further product information on the TippingPoint IPS, visit:

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of Microsoft Office PowerPoint Viewer. User
interaction is required to exploit this vulnerability in that the target
must open a malicious presentation.

The specific flaw exists in the handling of TextBytesAtom records
contained in a PPT file. Due to the lack of bounds checking on the size
argument an unchecked memcpy() copies user data from the file to the
stack, overflowing key exception structures. Exploitation of this
vulnerability can lead to remote compromise of the affected system under
the context of the currently logged in user.

-- Vendor Response:
Microsoft has issued an update to correct this vulnerability. More
details can be found at:

http://www.microsoft.com/technet/security/Bulletin/MS10-004.mspx

-- Disclosure Timeline:
2009-10-21 - Vulnerability reported to vendor
2010-02-09 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* SkD

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, The Zero Day Initiative (ZDI) represents 
a best-of-breed model for rewarding security researchers for responsibly
disclosing discovered vulnerabilities.

Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:

http://www.zerodayinitiative.com

The ZDI is unique in how the acquired vulnerability information is
used. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint provides its customers with zero day protection through
its intrusion prevention technology. Explicit details regarding the
specifics of the vulnerability are not exposed to any parties until
an official vendor patch is publicly available. Furthermore, with the
altruistic aim of helping to secure a broader user base, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] ZDI-10-016: Microsoft Windows ShellExecute Improper Sanitization Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-016: Microsoft Windows ShellExecute Improper Sanitization Code Execution 
Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-10-016
February 9, 2010

-- CVE ID:
CVE-2010-0027

-- Affected Vendors:
Microsoft

-- Affected Products:
Microsoft Windows XP

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 9436. 
For further product information on the TippingPoint IPS, visit:

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows remote attackers to force a Microsoft Windows
system to execute a given local executable. User interaction is required
in that the target must access a malicious URL.

The specific flaw exists within the ShellExecute API. Using a specially
formatted URL an attacker can bypass sanitization checks within this
function and force the calling application into running an executable of
their choice. Successful exploitation requires a useful binary to exist
in a predictable location on the remote system.

-- Vendor Response:
Microsoft has issued an update to correct this vulnerability. More
details can be found at:

http://www.microsoft.com/technet/security/bulletin/MS10-007.mspx

-- Disclosure Timeline:
2009-07-20 - Vulnerability reported to vendor
2010-02-09 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Brett Moore, Insomnia Security

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, The Zero Day Initiative (ZDI) represents 
a best-of-breed model for rewarding security researchers for responsibly
disclosing discovered vulnerabilities.

Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:

http://www.zerodayinitiative.com

The ZDI is unique in how the acquired vulnerability information is
used. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint provides its customers with zero day protection through
its intrusion prevention technology. Explicit details regarding the
specifics of the vulnerability are not exposed to any parties until
an official vendor patch is publicly available. Furthermore, with the
altruistic aim of helping to secure a broader user base, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] ZDI-10-015: Microsoft Windows RLE Video Decompressor Remote Code Execution Vulnerability

[ZDI Disclosures]

ZDI-10-015: Microsoft Windows RLE Video Decompressor Remote Code Execution 
Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-10-015
February 9, 2010

-- CVE ID:
CVE-2010-0250

-- Affected Vendors:
Microsoft

-- Affected Products:
Microsoft Windows XP
Microsoft Windows Vista

-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 9453. 
For further product information on the TippingPoint IPS, visit:

http://www.tippingpoint.com

-- Vulnerability Details:
This vulnerability allows attackers to execute arbitrary code on
applications that utilize DirectShow for rendering video on Microsoft
Windows. User interaction is required to exploit this vulnerability in
that the target must be coerced into decompressing a malicious video.

The specific flaw exists within the decompression of a specific type of
video stream contained in an .AVI file. The application misuses a length
field for an allocation causing the memory allocation to be too small to
contain the subsequent data. During population of this buffer, the
application will copy more data than allocated for leading to memory
corruption with the potential for code execution.

-- Vendor Response:
Microsoft has issued an update to correct this vulnerability. More
details can be found at:

http://www.microsoft.com/technet/security/bulletin/MS10-013.mspx

-- Disclosure Timeline:
2009-01-15 - Vulnerability reported to vendor
2010-02-09 - Coordinated public release of advisory

-- Credit:
This vulnerability was discovered by:
* Anonymous

-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, The Zero Day Initiative (ZDI) represents 
a best-of-breed model for rewarding security researchers for responsibly
disclosing discovered vulnerabilities.

Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:

http://www.zerodayinitiative.com

The ZDI is unique in how the acquired vulnerability information is
used. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint provides its customers with zero day protection through
its intrusion prevention technology. Explicit details regarding the
specifics of the vulnerability are not exposed to any parties until
an official vendor patch is publicly available. Furthermore, with the
altruistic aim of helping to secure a broader user base, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.

Our vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] CORE-2009-0827: Microsoft Office Excel / Word OfficeArtSpgr Container Pointer Overwrite Vulnerability

[CORE Security Technologies Advisories]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Core Security Technologies - CoreLabs Advisory
   http://www.coresecurity.com/corelabs/

Microsoft Office Excel / Word OfficeArtSpgr Container Pointer Overwrite
Vulnerability



1. *Advisory Information*

Title: Microsoft Office Excel / Word OfficeArtSpgr Container Pointer
Overwrite Vulnerability
Advisory Id: CORE-2009-0827
Advisory URL: http://www.coresecurity.com/content/excel-buffer-overflow
Date published: 2010-02-09
Date of last update: 2010-02-08
Vendors contacted: Microsoft
Release mode: Coordinated release



2. *Vulnerability Information*

Class: Buffer overflow [CWE-119]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 38073
CVE Name: CVE-2010-0243



3. *Vulnerability Description*

A vulnerability exists in MSO.DLL affecting Excel 9 (Office 2000) and
Excel 10 (Office XP) in the code responsible for parsing OfficeArtSpgr
(recType 0xF003) containers that allows an attacker to cause a class
pointer to be interpreted incorrectly, leading to code execution in the
context of the currently logged on user.


4. *Vulnerable packages*

   . Microsoft Office XP Service Pack 3
   . Microsoft Office 2004 for Mac


5. *Non-vulnerable packages*

   . Microsoft Office 2003 Service Pack 3
   . 2007 Microsoft Office System Service Pack 1
   . 2007 Microsoft Office System Service Pack 2
   . Microsoft Office 2008 for Mac
   . Open XML File Format Converter for Mac
   . Microsoft Office Excel Viewer Service Pack 1 and Microsoft Office
Excel Viewer Service Pack 2
   . Microsoft Office Word Viewer
   . PowerPoint Viewer 2007 Service Pack 1 and PowerPoint Viewer 2007
Service Pack 2
   . Visio Viewer 2007 Service Pack 1 and Visio Viewer 2007 Service Pack 2
   . Microsoft Works 8.5
   . Microsoft Works 9


6. *Vendor Information, Solutions and Workarounds*

Microsoft has addressed this vulnerability by issuing an update located
at http://www.microsoft.com/technet/security/bulletin/MS10-003.msp


7. *Credits*

This vulnerability was discovered and researched by Damian Frizza from
Core Security Technologies during Bugweek 2009 [1].


8. *Technical Description / Proof of Concept Code*


8.1. *Excel / Word - OfficeArtSpgr container - invalid recType value
leads to attacker controlled pointer usage [MSRC 9368]*

A vulnerability exists in MSO.DLL affecting Excel 9 (Office 2000) and
Excel 10 (Office XP) in the code responsible for parsing OfficeArtSpgr
(recType 0xF003) containers that allows an attacker to cause a class
pointer to be interpreted incorrectly, leading to code execution in the
context of the currently logged on user.

The precise affected executable version we tested is 'Excel.exe
v10.0.6854' and the DLL is 'mso.dll v10.0.6845'

Likely attack vectors include:

   . Targeted attacks involving e-mailed malicious files combined with
social engineering to entice the user to open the malicious attachment.
   . Targeted attacks involving malicious files hosted on a remote web
site combined with social engineering to entice the user to open the
malicious attachment.

The root cause description of the vulnerability is that there is no
check to make sure that there is a valid group before loading the SPGR
from the file.

A disassembly of the vulnerable code follows:

/-
30BDE405   CMP ECX,0F003
30BDE40B   JB mso.30EFD183
30BDE411   CMP ECX,0F004
30BDE417   JA mso.30BDE4C8
30BDE41D   XOR ESI,ESI
30BDE41F   LEA EAX,DWORD PTR SS:[EBP-8]
30BDE422   PUSH ESI
30BDE423   PUSH EAX
30BDE424   PUSH EDI
30BDE425   MOV ECX,EBX
30BDE427   CALL mso.30BDEC18
30BDE42C   TEST EAX,EAX
30BDE42E   JE mso.30EFD21A
30BDE434   MOV EDX,DWORD PTR SS:[EBP-8]
30BDE437   MOV EAX,DWORD PTR DS:[EDX+50]
30BDE43A   TEST AL,10
30BDE43C   JE mso.30BDE356
30BDE442   TEST AL,4
30BDE444   JE mso.30EFD21A
30BDE44A   CMP WORD PTR DS:[EDX+24],SI
30BDE44E   JNZ mso.30EFD21A
30BDE454   PUSH 23
30BDE456   LEA EDI,DWORD PTR DS:[EBX+90]
30BDE45C   POP ECX
30BDE45D   MOV ESI,EDX
30BDE45F   LEA EAX,DWORD PTR DS:[EBX+F0]
30BDE465   ADD EDX,58
30BDE468   REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
30BDE46A   CMP DWORD PTR DS:[EAX],EDX
30BDE46C   MOV DWORD PTR DS:[EBX+CC],EBX
30BDE472   JE mso.30EFD12E
30BDE478   MOV ECX,DWORD PTR DS:[EAX]
30BDE47A   MOV DWORD PTR DS:[ECX],EAX  ;*Access Violation On Write*

registers
eax=017f068c ebx=017f059c ecx=0e000e00 edx=017f0870 esi=017f08a4
edi=017f06b8
eip=30dd70cc esp=00137674 ebp=00137714 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0206

- -/



8.2. *Memory Corruption related to Graphic Description [MSRC case 9562]*

Core Security Technologies reported a second bug in Excel which resulted
non exploitable. In its investigation, MSRC has analyzed BIFF5++, BIFF4,
and BIFF2 file formats for exploitability of this vulnerability. MSRC
has been unable to reproduce it in such a way that an exploitable
condition occurs.


9. *Report Timeline*

. 2009-09-04:
Core Security Technologies not

[Full-disclosure] #HITB - Special Report: HITB2009 CTF Weapons of Mass Destruction

[Hafez Kamal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A true 'hacker's conference' wouldn't be fun without a competition
where hackers go head to head, tears are shed, and blood is spilled,
and when we say blood we mean points. CTFs have always been about how
good and fast you are at reversing and exploiting daemons and
binaries. Sure it's fun and all but after a few years of the same
thing, it's starts to get boring. Hence we decided to come up with CTF
- - Weapons of Mass Destruction (say it with me, destruktion!!!).

Let's face it, acquiring allies and launching nukes at rival teams is
much more fun than just reversing binaries and stealing flags.
Strategy is everything! The crew worked hard through out the year,
planning the game mechanics, designing the world map, and coming up
with complex challenges for the game. Though there were some quirks
here and there on game day, miraculously we pulled it off. The nukes
weren't the only thing that was different. We also had no prize money
for this year's CTF but teams still signed up anyway purely for the
bragging rights. You guys are f...@#&king awesome!

So without further ado, the CTF crew brings you the writeup for
Weapons of Mass Destruction 2009. Enjoy!

https://www.hackinthebox.org/misc/HITB-CTF2009-Special-Report.pdf
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktxlUQACgkQbMY1K865PtGXeACfdD2kYtSaPi8xjC4v8a4mLp/S
jYIAoLbNRbXUQpBBZhobgPO6QoF8CkWn
=yeuM
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Finding Domain Controllers for use with WinScanX using DCLookup.exe (source included)

[Thor (Hammer of God)]

FYI, TSEnum is free and always has been on the HoG site.  I wrote it 
specifically to enumerate the roles of all servers in the domain, including 
things like SQL server, Terminal services, etc.  it also works over a null 
session.

Well, it did back in the day, I've not looked at how it holds up against 2008.

t

> -Original Message-
> From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-
> disclosure-boun...@lists.grok.org.uk] On Behalf Of Reed Arvin
> Sent: Tuesday, February 09, 2010 10:08 AM
> To: full-disclosure@lists.grok.org.uk
> Subject: [Full-disclosure] Finding Domain Controllers for use with
> WinScanX using DCLookup.exe (source included)
> 
> WinScanX Pro is only $10.00 for the month of February (normally
> $250.00)
> 
> WinScanX Basic (always free - only scans one host per run)
> http://www.windowsaudit.com/
> 
> Article tool: DCLookup.exe (source included)
> http://windowsaudit.com/downloads/DCLookup.zip
> 
> Original article link:
> http://windowsaudit.com/winscanx/finding-domain-controllers-for-use-
> with-winscanx/
> 
> ==
> 
> When performing a security assessment it's important to have a plan of
> attack. All machines do not have the same level of criticality. For
> example, a missing patch on a Windows workstation will not be
> perceived as being as serious a flaw as a missing patch on a Windows
> domain controller. For a Windows assessment, one routine that I found
> useful was to target the following hosts in the following order:
> 
> - Windows domain controllers
> - Windows servers
> - Windows workstations
> 
> Locating Windows domain controllers can be a bit of a hassle
> sometimes, especially if you have no knowledge of the network you are
> assessing. If that is the case for you, the following may provide some
> help.
> 
> DCLookup - Provides a list of domain controllers that are available to
> authenticate the current host
> 
> Download at: http://windowsaudit.com/downloads/DCLookup.zip (source
> included)
> 
> Usage:
> 
> DCLookup.exe 
> 
> DCLookup.exe 127.0.0.1
> DCLookup.exe MyMachine
> 
> Example output:
> 
> C:\>DCLookup.exe 127.0.0.1
> 
> +++
> + DC INFO VIA DsGetDcName +
> +++
> 
> Domain Controller Name:\\site1dc06.company.corp
> Domain Controller Address: \\192.168.11.65
> Domain Name:   company.corp
> DNS Forest Name:   company.corp
> 
> +++
> +  DC INFO VIA DsGetDomainControllerInfo  +
> +++
> 
> NetBios Name:  site1DC01
> DNS Host Name: site1dc01.company.corp
> 
> NetBios Name:  site1DC02
> DNS Host Name: site1dc02.company.corp
> 
> NetBios Name:  site2DC01
> DNS Host Name: site2dc01.company.corp
> 
> NetBios Name:  site3DC01
> DNS Host Name: site3dc01.company.corp
> 
> NetBios Name:  site4DC01
> DNS Host Name: site4DC01.company.corp
> 
> NetBios Name:  site5DC01
> DNS Host Name: site5DC01.company.corp
> 
> NetBios Name:  site6DC04
> DNS Host Name: site6DC04.company.corp
> 
> NetBios Name:  site1DC05
> DNS Host Name: site1dc05.company.corp
> 
> NetBios Name:  site1DC06
> DNS Host Name: site1dc06.company.corp
> 
> NetBios Name:  site1DC04
> DNS Host Name: site1dc04.company.corp
> 
> +++
> +   DC INFO VIA DsEnumerateDomainTrusts   +
> +++
> 
> NetBios Domain Name: TRUSTEDDOM
> DNS Domain Name: trusteddom.corp
> 
> What to do next:
> 
> Once you have a list of domain controllers, the next step would be to
> start running various checks against them to assess their security
> stature. The following is a short assessment flow for a domain
> controller using WinScanX:
> 
> 1. Using WinScanX, attempt to retrieve the account lockout threshold
> using the Get Account Policy Information feature against a domain
> controller.
> 
> 2. If the account lockout threshold is not set or if it is 5 attempts
> or higher, attempt to retrieve the user information using the Get User
> Information or Get User Information via RA Bypass feature of WinScanX
> and run a quick password check using the Guess Windows Passwords
> feature.
> 
> ***NOTE***
> Make sure to only use the Guess Windows Passwords feature on one
> domain controller ONLY. Using this feature on multiple domain
> controllers in the same domain may cause accounts to lock out.
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Finding Domain Controllers for use with WinScanX using DCLookup.exe (source included)

[Reed Arvin]

WinScanX Pro is only $10.00 for the month of February (normally $250.00)

WinScanX Basic (always free - only scans one host per run)
http://www.windowsaudit.com/

Article tool: DCLookup.exe (source included)
http://windowsaudit.com/downloads/DCLookup.zip

Original article link:
http://windowsaudit.com/winscanx/finding-domain-controllers-for-use-with-winscanx/

==

When performing a security assessment it’s important to have a plan of
attack. All machines do not have the same level of criticality. For
example, a missing patch on a Windows workstation will not be
perceived as being as serious a flaw as a missing patch on a Windows
domain controller. For a Windows assessment, one routine that I found
useful was to target the following hosts in the following order:

- Windows domain controllers
- Windows servers
- Windows workstations

Locating Windows domain controllers can be a bit of a hassle
sometimes, especially if you have no knowledge of the network you are
assessing. If that is the case for you, the following may provide some
help.

DCLookup – Provides a list of domain controllers that are available to
authenticate the current host

Download at: http://windowsaudit.com/downloads/DCLookup.zip (source included)

Usage:

DCLookup.exe 

DCLookup.exe 127.0.0.1
DCLookup.exe MyMachine

Example output:

C:\>DCLookup.exe 127.0.0.1

+++
+ DC INFO VIA DsGetDcName +
+++

Domain Controller Name:\\site1dc06.company.corp
Domain Controller Address: \\192.168.11.65
Domain Name:   company.corp
DNS Forest Name:   company.corp

+++
+  DC INFO VIA DsGetDomainControllerInfo  +
+++

NetBios Name:  site1DC01
DNS Host Name: site1dc01.company.corp

NetBios Name:  site1DC02
DNS Host Name: site1dc02.company.corp

NetBios Name:  site2DC01
DNS Host Name: site2dc01.company.corp

NetBios Name:  site3DC01
DNS Host Name: site3dc01.company.corp

NetBios Name:  site4DC01
DNS Host Name: site4DC01.company.corp

NetBios Name:  site5DC01
DNS Host Name: site5DC01.company.corp

NetBios Name:  site6DC04
DNS Host Name: site6DC04.company.corp

NetBios Name:  site1DC05
DNS Host Name: site1dc05.company.corp

NetBios Name:  site1DC06
DNS Host Name: site1dc06.company.corp

NetBios Name:  site1DC04
DNS Host Name: site1dc04.company.corp

+++
+   DC INFO VIA DsEnumerateDomainTrusts   +
+++

NetBios Domain Name: TRUSTEDDOM
DNS Domain Name: trusteddom.corp

What to do next:

Once you have a list of domain controllers, the next step would be to
start running various checks against them to assess their security
stature. The following is a short assessment flow for a domain
controller using WinScanX:

1. Using WinScanX, attempt to retrieve the account lockout threshold
using the Get Account Policy Information feature against a domain
controller.

2. If the account lockout threshold is not set or if it is 5 attempts
or higher, attempt to retrieve the user information using the Get User
Information or Get User Information via RA Bypass feature of WinScanX
and run a quick password check using the Guess Windows Passwords
feature.

***NOTE***
Make sure to only use the Guess Windows Passwords feature on one
domain controller ONLY. Using this feature on multiple domain
controllers in the same domain may cause accounts to lock out.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] SMS Banking

[Thor (Hammer of God)]

I'm looping in the FD list because often my replies don't make it to Pen-Test, 
and this has hit a nerve with me.

I've looked over your post at:

http://gse-compliance.blogspot.com/2010/02/modelling-risk.html .

Once I was able to get past the overwhelming egoism and self-substantiating 
claims of your contributions to the industry, I arrived at the conclusion that 
the only portion of the aforementioned page that is not complete drivel and 
even laughable to anyone who has actually worked towards ascertaining actual 
risk in production environments, is where you describe your own words as 
"ravings."  Ravings, of course, means "delirious, irrational speech."  

I'm fine with you sitting back and gloating about the Security Hero award you 
got from Northcutt, but when I see that you are actually contributing to ANY 
level of Critical Infrastructure Protection, it makes me fear for anyone who 
might be counting on your presumed skillset to actually make intelligent 
decisions about risk where human safety is at stake.  Your "risk formula" is 
ridiculous.  What number would your formula have yielded 2 weeks before SQL 
Slammer was released?  Where is the variable for unpatched systems?  What 
number do we plug in for malicious employee factorization?   More importantly, 
where is the calculation for self absorbed snake-oil selling academics with no 
real experience using their calculator to come up with magic numbers that 
represent the risk of a nuclear power plant being hacked?

Since you are (self-described) as "currently the only GIAC GSE (Compliance) 
holder globally and the most highly accredited Global Information Security 
Professional" and thus (presumably, if only in your mind) the greatest security 
mind in the world, how about accepting a challenge to an open debate on the 
subject at Defcon?  People like you are dangerous and need to be exposed before 
someone in a position of power actually believes that you know what you are 
talking about.  Bring your abacus.  

t




> -Original Message-
> From: Craig S. Wright [mailto:craig.wri...@information-defense.com]
> Sent: Monday, February 08, 2010 3:40 PM
> To: Thor (Hammer of God); pen-t...@securityfocus.com; security-
> bas...@securityfocus.com
> Subject: RE: SMS Banking
> 
> " And just how do you come up with the probability of compromising the
> SMS
> function and the user authentication method?"
> 
> Actually, fairly simply using Bayes' formula.
> 
> I have posted on this at:
> http://gse-compliance.blogspot.com/2010/02/modelling-risk.html
> 
> The comment was that GSM itself can be made more secure if it is
> coupled
> with another means of securing the transmission.
> 
> "if one can position one's self anywhere in the transmission chain."
> This is a select number of locations. It is not everywhere. Though the
> number of locations may be large - it is not infinite. It is also not
> all
> points on the globe.
> 
> As can be seen in the post, what the effect of an SMS only based
> solution is
> a time degrading function. This is, the longer that the SMS application
> runs
> (alone), the greater the risk until eventually, the risk is maximised
> at
> certain failure.
> 
> Adding a second function, such as a non-SMS based sub-function can help
> to
> mitigate this, but a well chosen sub-function is more effective alone
> without the addition of the SMS measure and hence a better option.
> 
> The SMS function alone can befit from a second function, but this is
> only
> warranted if the SMS function is an essential process for some reason.
> 
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
> 
> 
> -Original Message-
> From: listbou...@securityfocus.com
> [mailto:listbou...@securityfocus.com] On
> Behalf Of Thor (Hammer of God)
> Sent: Tuesday, 9 February 2010 3:15 AM
> To: pen-t...@securityfocus.com; security-bas...@securityfocus.com
> Subject: RE: SMS Banking
> 
> And just how do you come up with the probability of compromising the
> SMS
> function and the user authentication method?
> 
> While little formulas may go well in meetings, this hardly helps the OP
> with
> his question.  You also failed to note that the overall risk figure you
> calculate has to be compared to something - what are you comparing it
> to?
> If P(Compromise) turns out to be 42, what does he do with that
> information?
> 
> Regarding GSM, what "far more" information are you talking about?  The
> account number and PIN is all that is needed in the example given by
> the OP,
> and that is exactly what one would get from a GSM attack.
> 
> You should also note that "compromising GSM" is completely unnecessary
> if
> one does in fact have a select number of locations where the actual GSM
> signal is redirected.  Cracking GSM itself does NOT require being at a
> "select number of locations" if one can position one's self anywhere in
> the
> transmission chain.
> 
> t
> 
> > -Original Message-

[Full-disclosure] List Charter

[John Cartwright]

[Full-Disclosure] Mailing List Charter
John Cartwright 
 

- Introduction & Purpose -

This document serves as a charter for the [Full-Disclosure] mailing 
list hosted at lists.grok.org.uk.

The list was created on 9th July 2002 by Len Rose, and is primarily 
concerned with security issues and their discussion.  The list is 
administered by John Cartwright.

The Full-Disclosure list is hosted and sponsored by Secunia.


- Subscription Information -

Subscription/unsubscription may be performed via the HTTP interface 
located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure.

Alternatively, commands may be emailed to 
full-disclosure-requ...@lists.grok.org.uk, send the word 'help' in 
either the message subject or body for details.

 
- Moderation & Management -

The [Full-Disclosure] list is unmoderated. Typically posting will be
restricted to members only, however the administrators may choose to 
accept submissions from non-members based on individual merit and 
relevance.

It is expected that the list will be largely self-policing, however in
special circumstances (eg spamming, misappropriation) then offending 
members may be removed from the list by the management.

An archive of postings is available at 
http://lists.grok.org.uk/pipermail/full-disclosure/.
 

- Acceptable Content -

Any information pertaining to vulnerabilities is acceptable, for 
instance announcement and discussion thereof, exploit techniques and 
code, related tools and papers, and other useful information.

Gratuitous advertisement, product placement, or self-promotion is 
forbidden.  Disagreements, flames, arguments, and off-topic discussion 
should be taken off-list wherever possible.

Humour is acceptable in moderation, providing it is inoffensive. 
Politics should be avoided at all costs.

Members are reminded that due to the open nature of the list, they 
should use discretion in executing any tools or code distributed via
this list.
 

- Posting Guidelines -

The primary language of this list is English. Members are expected to 
maintain a reasonable standard of netiquette when posting to the list. 

Quoting should not exceed that which is necessary to convey context, 
this is especially relevant to members subscribed to the digested 
version of the list.

The use of HTML is discouraged, but not forbidden. Signatures will 
preferably be short and to the point, and those containing 
'disclaimers' should be avoided where possible.

Attachments may be included if relevant or necessary (e.g. PGP or 
S/MIME signatures, proof-of-concept code, etc) but must not be active 
(in the case of a worm, for example) or malicious to the recipient.

Vacation messages should be carefully configured to avoid replying to 
list postings. Offenders will be excluded from the mailing list until 
the problem is corrected.

Members may post to the list by emailing 
full-disclos...@lists.grok.org.uk. Do not send subscription/
unsubscription mails to this address, use the -request address 
mentioned above.


- Charter Additions/Changes -

The list charter will be published at 
http://lists.grok.org.uk/full-disclosure-charter.html.

In addition, the charter will be posted monthly to the list by the 
management.

Alterations will be made after consultation with list members and a 
concensus has been reached.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Samba Remote Zero-Day Exploit

[Michael Wojcik]

> From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
> Sent: Monday, 08 February, 2010 16:33
> 
> Michael Wojcik wrote:
> 
> >> From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
> >> Sent: Saturday, 06 February, 2010 08:21
> >>
> >> Since Windows 2000 NTFS supports "junctions", which pretty much
> >> resemble Unix symlinks, but only for directories.
> >> See 
> >
> > And at least since Vista, it also supports symlinks, which are
> > designed
> 
> s/at least//
> [ well-known facts snipped ]

So ... your original note about junctions did not cover "well-known
facts", but my note about other reparse point types did?

> > The Windows SMB server apparently won't cross reparse points,
though,
> > so there's no equivalent vulnerability.
> 
> NO, Windows SMB server crosses reparse points!

Not in my testing, at least not for junctions and symlinks. User with
requisite authority could traverse the junctions and symlinks locally,
but not remotely via a share.

> But as Dan Kaminsky pointed out, you need to have administrative
rights
> to remotely create a junction on an SMB share, so the non-admin user
> cant get himself access to files outside a share he's allowed to
> access.

Unless the reparse point already exists.

This particular exploit happened to involve a remote user creating a
symlink. That doesn't mean there are no other imaginable vulnerabilities
stemming from filesystem objects that violate the notional tree
structure of the directory hierarchy.

The obvious one: someone shares a branch of the directory tree in the
belief that clients only have access to that part of the tree, but the
tree already contains a convenience symlink (Unix) or reparse point
(Windows) that points elsewhere in the hierarchy. That's one reason why
Samba has had the "wide links=no" option since, what, the mid-1990s.


-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Samba Remote Zero-Day Exploit

[Stefan Kanthak]

Michael Wojcik wrote:

>> From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
>> Sent: Saturday, 06 February, 2010 08:21
>> 
>> Dan Kaminsky wrote:
>> 
>> [...]
>> 
>> > (On a side note, you're not going to see this sort of symlink stuff
>> > on Windows,
>> 
>> What exactly do you mean?
>> Traversing symlinks on the server/share, or creation of "wide"
>symlinks
>> by the client on the server/share?
>> 
>> Since Windows 2000 NTFS supports "junctions", which pretty much
>> resemble Unix symlinks, but only for directories.
>> See 
>
> And at least since Vista, it also supports symlinks, which are designed

s/at least//

[ well-known facts snipped ]

> The Windows SMB server apparently won't cross reparse points, though, so
> there's no equivalent vulnerability.

NO, Windows SMB server crosses reparse points!

But as Dan Kaminsky pointed out, you need to have administrative rights
to remotely create a junction on an SMB share, so the non-admin user
cant get himself access to files outside a share he's allowed to access.

Stefan

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Samba Remote Zero-Day Exploit

[Krzysztof Halasa]

Thierry Zoller  writes:

> Facts :
> - Several distributions run with vulnerable settings per default
>   if there is a "misconfiguration" it is part of the vendor.
> - Your not supposed to be able to traverse dirs.

What's wrong with creating $HOME/tmp -> /tmp/$USER (not necessarily
with Samba, maybe with xterm or ssh) and then accessing /tmp/$USER via
/host/HOME/tmp? Why is it a problem while "ssh host cat /etc/passwd" is
not?

Can you traverse a directory for which you have no +x right?
Can you, for example, write to a file for which you have no +w right?
Read without +r?

If you can't, maybe it's a (local config?) issue with guest accounts, or
maybe Windows-only (and similar, non-guest) accounts, instead of
permissions and symlinks?

Disabling or limiting symlink creation will not really close the "hole",
the problem is not the symlink but that the user has fs access which he
(or she) should never have.

... unless (obviously) answer to any of the 3 questions is positive
(I haven't checked, to be honest) - is it?
-- 
Chris

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Samba Remote Zero-Day Exploit

[Michael Wojcik]

> From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
> Sent: Saturday, 06 February, 2010 08:21
> 
> Dan Kaminsky wrote:
> 
> [...]
> 
> > (On a side note, you're not going to see this sort of symlink stuff
> > on Windows,
> 
> What exactly do you mean?
> Traversing symlinks on the server/share, or creation of "wide"
symlinks
> by the client on the server/share?
> 
> Since Windows 2000 NTFS supports "junctions", which pretty much
> resemble Unix symlinks, but only for directories.
> See 

And at least since Vista, it also supports symlinks, which are designed
to mimic Unix symlinks, and can point to files or directories. Junctions
and symlinks can cross volumes; symlinks can also refer to files or
directories on network filesystems.

Junctions (which Microsoft also sometimes refers to as "soft links") and
symlinks are implemented with NTFS reparse points, just like mounts. You
can see some of the differences between them using "fsutil reparsepoint
query ", where "" is a junction or symlink.

In Vista and later, symlinks and junctions can be created with the
mklink command. (I've seen some comments about symlinks being available
in earlier versions of NTFS, via Services for Unix; but at least in SFU
2.0, symlinks were just files with a special format, not reparse
points.)

The Windows SMB server apparently won't cross reparse points, though, so
there's no equivalent vulnerability.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Hacktics Advisory Feb09: XSS in Oracle E-Business Suite

[Ofer Maor]

Hacktics Research Group Security Advisory
http://www.hacktics.com/#view=Resources%7CAdvisory

By Gil Cohen, Hacktics.
9-Feb-2010

===
I. Overview
===
During a penetration test performed by Hacktics' experts, certain
vulnerabilities were identified in an Oracle E-Business Suite deployment.
Further research has identified that a web interface showing user errors are
vulnerable to reflected cross site scripting attacks. 

A friendly formatted version of this advisory is available in:
   http://www.hacktics.com/content/advisories/AdvORA20100209.html

===
II. The Finding
===
The XSS vulnerability appears in the error details page,
OAErrorDetailPage.jsp when the server is in diagnostics mode, and requires
an additional preliminary step to invoke. When an application error occurs,
the application presents a general error message with a link to the detailed
error page. The detailed error page is vulnerable to scripting attacks
embedded in input sent to the page that caused the error. An attacker can
exploit this by sending users or administrators a malicious link that causes
an error and contains a malicious script, and urges them to navigate to the
details page causing the malicious script to be executed. 

Hacktics' research classifies the risk of the vulnerability as Low, due to
the combination of the non default diagnostic mode, and the complex
invocation scenario, which reduce the probability of successfully exploiting
this vulnerability.


III. Details

The XSS vulnerability requires that an error is raised first, through
OA.jsp. The page that receives the malicious script and raises the error
resides at the following address:

http://foo.bar:fooport/OA_HTML/OA.jsp?page=/oracle/apps/fnd/framework/naviga
te/webui/HomePG&homePage='a&OAPB='b&transactionid=malicious_script

The application then displays a general error message with a link to a more
detailed error page (OAErrorDetailPage.jsp). When the user navigates to the
vulnerable error details page, the script executes:

http://foo.bar:fooport/OA_HTML/OAErrorDetailPage.jsp

===
IV. Exploit
===
The exploit is performed by replacing malicious_script with the relevant
Javascript payload. 

===
V. Affected Systems
===
The vulnerability was identified in version 12.1.1.

==
VI. Vendor's Response/Solution
==
Oracle's security alerts group has been notified of this vulnerability in
early November 2009. 
The vulnerability has been acknowledged by Oracle, and has already been
fixed in the Jul-2009 CPU:
 
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuj
ul2009.html

Oracle has also pointed out that this vulnerability is only applicable when
the system is in diagnostics mode. Customers are recommended to avoid
running their systems in diagnostics mode while in production.

===
VII. Credit
===
The vulnerability was discovered by Gil Cohen from Hacktics Ltd.


---
Ofer Maor
CTO, Hacktics
Chairman, OWASP Israel

Web: www.hacktics.com




___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/