lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050411004301.0CB23668@lists.grok.org.uk>
Date: Mon Apr 11 01:43:07 2005
From: randallm at fidmail.com (Randall M)
Subject: RE: [NT] Microsoft Multiple E-Mail Client Address
	Spoofing Vulnerability


As a security professional working for a Corporate Office the "Multiple
E-Mail Client Address Vulnerability" (please see original advisory attached
below) caused me no small concern. The vulnerability described was tested on
Outlook 2003 and Exchange 2003 as far as I could tell. We deploy Outlook 97,
2000, 2003 on an Exchange 2000 server. The "social engineering" possibility
concerned me therefore I attempted to produce this vulnerability using
Outlook 2003 on an outside POP3 account and on a corporate Outlook 2003
client through an Exchange 2000 server sending both from and to through
both.

Overall finding: No spoofing is of concern with POP3 account or Exchange
2000 using Outlook 2003 since "reply" or "reply to all" will only go to the
spoof address (used for social engineering) and not the default sender
address (the one attempting to use social engineering). Thus social
engineering attempts will not work.

Application: Outlook 2003 client
Account type: POP3

Sent mail to POP3 account address. 

1. On POP3 only "one" email in the "From" field is allowed. Thus only able
to put a spoof address in. Original is default.
Once arriving the view set to show headers shows only the "spoof". Once POP3
email arrives and is opened it displays original with a "on behalf of" spoof
sender in "bold". 

Sent mail to corporate address.

2. Using a POP3 account and entering a legitimate address of a corporate
management team and sending to an employee at the corporate office (social
engineering attempt) address shows the manager spoofed address in the view
but still shows it as a "on behalf of" (in bold) if mail is opened or
replied to. Same as sending to POP3 account.

Side notes:
	a. If employee has managers email go to separate folder using rules,
the spoofed email will not follow that rule.
	b. If employee has view pane open the "From" address appears with
original and the "on behalf of" which would be suspicious.

Application: Exchange 2000 OWA
1. Could not manipulate the "From" field.

Application: Outlook 2003 client
Account type: Corporate Exchange 2000 server
Tested sending spoofed manager in the "From" field to another corporate
account.

Sent mail to another corporate employee:

1. Using spoofed manager address in "From" field. Mail arrived showing only
the spoofed manager address (no default address) with header view. If mail
is opened the "From" field still showed only the manager address. A "reply"
or "reply to all" would only reply to spoof address of manager which is
legit and thus he alone would receive.
2. I could not send email with more then one address in the "from" field no
mater what combination of commas.

Sent mail to outside POP3 account:

1. Mail arrives showing only the spoofed manager address (used for social
engineering attempts). A reply though would only go to spoofed manager
address which is legit.


Summary:


I was only concerned with Exchange 2000 and Outlook 97, 2000, 2003 since
this is what our company uses. I could not test on Exchange 2003. Though I
found that "spoofing" was available and that it showed in the header view,
the concern of the author of the below advisory...
____________
 "Consider the following example: A corporate SMTP server is configured to
drop all mail received from the external network claiming to be from an
internal address. By exploiting this issue, an attacker can bypass the
imposed restrictions and transmit a message that appears to come from an
internal user. This attack, combined with social engineering, could
potentially lead to further compromise."
__________

...is no concern with Exchange 2000 using corporate and POP3 2000, 2003
clients. The default sender and only one spoofing address could be used and
that using reply or reply to all would only go to the "spoofed" address
which would pose no threat since this is used for the social engineering
attempt and that a reply would then go to that address only and not the
default sender. 

I attempted to use comma-separated variables on both the POP3 and corporate
clients(Outlook 2003) but could not duplicate what the advisory stated. My
clients would only allow one address to show in the "From" field.

If you can find fault with my findings I would be most grateful. If my
explanations above are confusing feel free to ask 
me to clarify since my mind often runs faster then my fingers. Flaming is
helpful since my concern is to prevent this.


thank you
Randall M

"If we ever forget that we're one nation under God, then we will be a nation
gone under." 
- Ronald Reagan

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::
_________________________________

 
 

:-----Original Message-----
:From: SecuriTeam [mailto:support@...uriteam.com] 
:Sent: Sunday, April 10, 2005 10:50 AM
:To: list@...uriteam.com
:Subject: [NT] Microsoft Multiple E-Mail Client Address 
:Spoofing Vulnerability
:
:The following security advisory is sent to the securiteam 
:mailing list, and can be found at the SecuriTeam web site: 
:http://www.securiteam.com
:- - promotion
:
:The SecuriTeam alerts list - Free, Accurate, Independent.
:
:Get your security news from a reliable source.
:http://www.securiteam.com/mailinglist.html 
:
:- - - - - - - - -
:
:
:
:  Microsoft Multiple E-Mail Client Address Spoofing Vulnerability
:---------------------------------------------------------------
:---------
:
:
:SUMMARY
:
: <http://www.microsoft.com/outlook/> Microsoft Outlook 
:provides an integrated solution for managing and organizing 
:e-mail messages, schedules, tasks, notes, contacts, and other 
:information. Remote exploitation of an address spoofing 
:vulnerability in various Microsoft Corp. e-mail clients could 
:allow attackers to social engineer sensitive information from 
:end users.
:
:DETAILS
:
:Vulnerable Systems:
: * Microsoft Outlook as distributed with Office XP and 2003 as 
:well as Outlook Web Access as distributed with Exchange 2003 
:have been confirmed as vulnerable. Prior versions are 
:suspected to be affected as well
:
:Immune Systems:
: * Microsoft Outlook Express is not affected by this issue
:
:Microsoft Outlook and Microsoft Outlook Web Access (OWA) are 
:widely deployed collaboration clients in corporate networks. 
:The vulnerability specifically exists in message header 
:parsing and allows an attacker to spoof the "From" field that 
:is displayed on the user's screen. Within the SMTP header, 
:when the From field contains multiple comma-separated 
:addresses, Outlook and OWA will only display the first 
:address. Consider the following example header:
:
:From: support@...r.company, Phisher <phisher@...ackers.domain>
:
:Outlook and OWA will only display the address 
:"support@...r.company" as the sender address. While 
:server-side e-mail spoofing is a known matter, this issue is 
:relevant as it exists within the client. Consider the 
:following example: A corporate SMTP server is configured to 
:drop all mail received from the external network claiming to 
:be from an internal address. By exploiting this issue, an 
:attacker can bypass the imposed restrictions and transmit a 
:message that appears to come from an internal user. This 
:attack, combined with social engineering, could potentially 
:lead to further compromise.
:
:Workaround:
:Examine the full mail headers of any suspicious e-mail 
:messages prior to taking described actions or following live links.
:
:Vendor Status:
:Microsoft has reviewed the issue and has made the 
:determination that while a bug fix may be implemented in a 
:future service pack, a security advisory/patch will not be 
:released for this issue.
:
:Disclosure Timeline:
:01/21/2005 - Initial vendor notification
:01/24/2005 - Initial vendor response
:04/08/2005 - Public disclosure
:
:
:ADDITIONAL INFORMATION
:
:The information has been provided by
:<mailto:idlabs-advisories@...fense.com> iDEFENSE.
:The original article can be found at:  
:<http://www.idefense.com/application/poi/display?type=vulnerabilities>
:http://www.idefense.com/application/poi/display?type=vulnerabilities
:
:
:
:======================================== 
:
:
:This bulletin is sent to members of the SecuriTeam mailing list. 
:To unsubscribe from the list, send mail with an empty subject 
:line and body to: list-unsubscribe@...uriteam.com In order to 
:subscribe to the mailing list, simply forward this email to: 
:list-subscribe@...uriteam.com 
:
:
:==================== 
:==================== 
:
:DISCLAIMER: 
:The information in this bulletin is provided "AS IS" without 
:warranty of any kind. 
:In no event shall we be liable for any damages whatsoever 
:including direct, indirect, incidental, consequential, loss of 
:business profits or special damages. 
:
:
:
:
:

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ