Last night, TechCrunch reported that Google will now require sites that import e-mail addresses from Gmail to also allow export of their data. The move was clearly aimed at Facebook, which has kept Google from accessing their users’ data. In response, many people have mentioned that while Facebook lets users download some data, they’re still not able to download an e-mail address book of their Facebook contacts.
However, that’s not quite the case. Back in March, I published a guide to exporting data from Facebook using various tricks and FQL queries. Facebook has since made changes and added tools which have made the post a bit outdated, but much of the information still applies. In particular, I described using Yahoo’s contact import tool to download an e-mail address book for all your Facebook friends. This technique relies on a Facebook-approved feature and should not violate the site’s terms of service. A few specific steps have changed a bit, so I’ll recap the process here.
First, you need to have a Yahoo! Mail account. If you don’t already have one, you can create one for free. In fact, I’d advise creating a new account to avoid your Facebook friends’ e-mail addresses getting mixed up with any others already in your address book.
To add your friends’ e-mail addresses to your Yahoo! Address Book, follow the steps given on this page at the Yahoo! Mail blog. Essentially, you open Contacts, click on “Tools,” then “Import,” choose “Facebook,” and follow the steps. You will have to authorize a Facebook application built by Yahoo! for this purpose.
To save a local copy of these addresses, you can use the export tools in Yahoo! Address Book. Return to your Contacts, once again click “Tools,” and this time select “Export.” You’ll be presented with a list of programs, each with an “Export Now” button.
If you’re not sure which you should choose, I would recommend clicking the button next to Microsoft Outlook. You may have to enter a code a CAPTCHA code, but you’ll then be prompted to save a file in CSV format. This is a fairly standard way of saving contact information.
Once you’ve downloaded the file, you can use it to import your contacts into other places, including Outlook. You can also open the file in Microsoft Excel to view the contact list or make changes.
Read more
Friday, November 5, 2010
Adobe Suggests Workaround for New Reader Zero-Day
Adobe is still investigating reports of a new code execution vulnerability in Adobe Reader and Acrobat, but recommends blacklisting the affected JavaScript function in the meantime.
The flaw was reported as a zero-day on Wednesday, when someone posted a proof-of-concept exploit on the Full Disclosure mailing list.
However, it appears the issue has been known as a Denial of Service (DoS) condition since almost a year ago, when it was disclosed on a Russian-language blog.
Adobe confirmed the DoS attack vector, but has not yet verified if the bug can be exploited to execute arbitrary code.
Nevertheless, French vulnerability research vendor VUPEN Security has published an advisory suggesting that it is possible.
The vulnerability is caused by a heap corruption error in the "EScript.api" plugin, triggered when a PDF document calls the "printSeps()" undocumented function.
As a temporary workaround Adobe recommends adding this function to the JavaScript API blacklist used by Adobe Reader and Acrobat.
On Windows, this can be achieved via two separate registry entries, one for enterprise policies and one used by Adobe's patching process.
"The Adobe blacklist is modified by Adobe Reader patches whenever an API is deemed vulnerable. APIs are also removed from the blacklist whenever a fix for a vulnerability is provided by the current patch," the company explains.
The blacklisting can be done by creating the key "tBlackList" under "HKLM\SOFTWARE\Adobe\\\JavaScriptPerms" with a value of "Doc.printSeps" (case sensitive).
On 64-bit flavors of Windows the location is "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\\\JavaScriptPerms".
The location of the enterprise blacklist is "HKLM\SOFTWARE\Policies\Adobe\\\FeatureLockDown\cJavaScriptPerms", however, entries added here are not automatically removed by Adobe's patches.
Therefore, when a fix is released, in order to restore the functionality provided by printSeps(), the key will have to be removed manually.
Instructions to get the same results on Mac and Linux versions of the products are provided on the Adobe Product Security Incident Response Team (PSIRT) blog.
Read More.
The flaw was reported as a zero-day on Wednesday, when someone posted a proof-of-concept exploit on the Full Disclosure mailing list.
However, it appears the issue has been known as a Denial of Service (DoS) condition since almost a year ago, when it was disclosed on a Russian-language blog.
Adobe confirmed the DoS attack vector, but has not yet verified if the bug can be exploited to execute arbitrary code.
Nevertheless, French vulnerability research vendor VUPEN Security has published an advisory suggesting that it is possible.
The vulnerability is caused by a heap corruption error in the "EScript.api" plugin, triggered when a PDF document calls the "printSeps()" undocumented function.
As a temporary workaround Adobe recommends adding this function to the JavaScript API blacklist used by Adobe Reader and Acrobat.
On Windows, this can be achieved via two separate registry entries, one for enterprise policies and one used by Adobe's patching process.
"The Adobe blacklist is modified by Adobe Reader patches whenever an API is deemed vulnerable. APIs are also removed from the blacklist whenever a fix for a vulnerability is provided by the current patch," the company explains.
The blacklisting can be done by creating the key "tBlackList" under "HKLM\SOFTWARE\Adobe\
On 64-bit flavors of Windows the location is "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\
The location of the enterprise blacklist is "HKLM\SOFTWARE\Policies\Adobe\
Therefore, when a fix is released, in order to restore the functionality provided by printSeps(), the key will have to be removed manually.
Instructions to get the same results on Mac and Linux versions of the products are provided on the Adobe Product Security Incident Response Team (PSIRT) blog.
Read More.
Thursday, November 4, 2010
Understanding Firesheep Attack
The recently released Firesheep tool caused quite a buzz. Packaged as an easy to install Firefox add-on, the tool allowed an attacker to quickly identify nearby users that were insecurely accessing popular websites. The tool's easy to use design allowed a user with basic computer skills to see pictures of the vulnerable users in a buddy list style text box and enabled the user/attacker to simply double click on the user's picture in order to completely take over their account.
Brief aside: While I do work at Mozilla, this post is primarily focused on explaining the underlying website security controls that have failed to enable such an attack. To learn more about Mozilla's view of the Firesheep plugin I encourage you to read the post at the Mozilla Security Blog.
Why Is This News?
Firesheep does not exploit a new vulnerability. The vulnerable design of sending authenticated cookies over an unencrypted channel has been known for years. The reason Firesheep is making news is because of the ease of use to execute an attack and exploit this weakness in popular websites such as Facebook and Twitter. Perhaps all of this press, and a few angry users that are victim to unwanted status updates or tweets, may result in these large social networking sites actually fixing the issue.
How Does Firesheep Work?
First, Firesheep does not steal the victim's password that they are using with a website (twitter/facebook/etc). In fact, the passwords are correctly and securely sent to those websites. Instead Firesheep steals the session identifier for the user. The session id is a long random number that is used to represent the user after the user has authenticated to the website with their username and password. Without session ids a user would need to send their username and password with every request. The session id was created to eliminate this inconvenience and allow a user to simply provide their password once and allow the browser and website to handle the rest. The browser remembers the user's session id and the web server makes a record within their databases to associate the session id and user's identity. From this point on the web site knows that each time they receive the particular session id that the request is coming from the associated user.
Examples of session ids that would be stored on the web server
Session ID - Associated User
4364256265 - Joe
1239086434 - Sue
9938381123 - Bob
Where is the Security Problem?
Many users are aware that before logging into a website they should check that they are on a page beginning with HTTPS (instead of HTTP). HTTPS uses Transport Layer Security (TLS) (sometimes referred to as SSL) to ensure that the password is sent over an encrypted connection. This means that a network administrator, the coffee shop folks running a wireless hotspot, or even the coffee drinker sitting next to you, is unable to view your password when it is sent over the network.
The problem is in the next step. As we discussed above, the username and password is only sent once. After that, the web browser sends the session id to the website in order to identify the user. Unfortunately many websites have decided not to implement TLS/SSL for the communication after the login process. This means that although your password is sent over an encrypted channel, the session id is not. Since the session id represents the user's identity with the website, anyone that obtains the session id thereby becomes the associated user.
How Does The Attacker Obtain Your Session ID?
The attacker, in this case the user running Firesheep, executes a man in the middle attack which tells your computer to send all of your traffic to the attacker's machine before it is sent out to the Internet. This allows the attacker to easily view any data that is not encrypted like the session id. Encrypted data, such as the username and password, can not be viewed by the attacker even if he is executing a man in the middle attack.
To summarize, although the attacker can't obtain your password, they can obtain your session id. And this is just as good. Because with the session id the attacker can do anything in the website as you. In Facebook they could add new friends or make status updates and on Twitter they could tweet random messages. All of this would appear to normal just as if you had made these actions yourself.
Stay tuned for post #2 in the Firesheep series : Spotting Websites Vulnerable to Firesheep
-Michael Coates
Brief aside: While I do work at Mozilla, this post is primarily focused on explaining the underlying website security controls that have failed to enable such an attack. To learn more about Mozilla's view of the Firesheep plugin I encourage you to read the post at the Mozilla Security Blog.
Why Is This News?
Firesheep does not exploit a new vulnerability. The vulnerable design of sending authenticated cookies over an unencrypted channel has been known for years. The reason Firesheep is making news is because of the ease of use to execute an attack and exploit this weakness in popular websites such as Facebook and Twitter. Perhaps all of this press, and a few angry users that are victim to unwanted status updates or tweets, may result in these large social networking sites actually fixing the issue.
How Does Firesheep Work?
First, Firesheep does not steal the victim's password that they are using with a website (twitter/facebook/etc). In fact, the passwords are correctly and securely sent to those websites. Instead Firesheep steals the session identifier for the user. The session id is a long random number that is used to represent the user after the user has authenticated to the website with their username and password. Without session ids a user would need to send their username and password with every request. The session id was created to eliminate this inconvenience and allow a user to simply provide their password once and allow the browser and website to handle the rest. The browser remembers the user's session id and the web server makes a record within their databases to associate the session id and user's identity. From this point on the web site knows that each time they receive the particular session id that the request is coming from the associated user.
Examples of session ids that would be stored on the web server
Session ID - Associated User
4364256265 - Joe
1239086434 - Sue
9938381123 - Bob
Where is the Security Problem?
Many users are aware that before logging into a website they should check that they are on a page beginning with HTTPS (instead of HTTP). HTTPS uses Transport Layer Security (TLS) (sometimes referred to as SSL) to ensure that the password is sent over an encrypted connection. This means that a network administrator, the coffee shop folks running a wireless hotspot, or even the coffee drinker sitting next to you, is unable to view your password when it is sent over the network.
The problem is in the next step. As we discussed above, the username and password is only sent once. After that, the web browser sends the session id to the website in order to identify the user. Unfortunately many websites have decided not to implement TLS/SSL for the communication after the login process. This means that although your password is sent over an encrypted channel, the session id is not. Since the session id represents the user's identity with the website, anyone that obtains the session id thereby becomes the associated user.
How Does The Attacker Obtain Your Session ID?
The attacker, in this case the user running Firesheep, executes a man in the middle attack which tells your computer to send all of your traffic to the attacker's machine before it is sent out to the Internet. This allows the attacker to easily view any data that is not encrypted like the session id. Encrypted data, such as the username and password, can not be viewed by the attacker even if he is executing a man in the middle attack.
To summarize, although the attacker can't obtain your password, they can obtain your session id. And this is just as good. Because with the session id the attacker can do anything in the website as you. In Facebook they could add new friends or make status updates and on Twitter they could tweet random messages. All of this would appear to normal just as if you had made these actions yourself.
Stay tuned for post #2 in the Firesheep series : Spotting Websites Vulnerable to Firesheep
-Michael Coates
Tuesday, November 2, 2010
ProFTPD TELNET_IAC Remote Code Execution Vulnerability
-- CVSS ----------------------------------------------------------------
10, (AV:N/AC:L/Au:N/C:C/I:C/A:C)
-- ABSTRACT ------------------------------------------------------------
TippingPoint has identified a vulnerability affecting the following
products:
ProFTPD FTP Server
-- VULNERABILITY DETAILS -----------------------------------------------
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of ProFTPD. Authentication is not required to
exploit this vulnerability.
The flaw exists within the proftpd server component which listens by
default on TCP port 21. When reading user input if a TELNET_IAC escape
sequence is encountered the process miscalculates a buffer length
counter value allowing a user controlled copy of data to a stack buffer.
A remote attacker can exploit this vulnerability to execute arbitrary
code under the context of the proftpd process.
Tested on proftpd-1.3.3a.
[Switching to process 31268]
0x0806d498 in pr_netio_telnet_gets (buf=0xbf979ffc 'A'
at netio.c:1103
1103 *bp++ = cp;
FTP commands are read by function pr_cmd_read() of file
src/main.c (line 566).
The function pr_cmd_read() uses a local buffer (line 568):
char buf[PR_DEFAULT_CMD_BUFSZ+1] = {'\0'};
At line 582, pr_cmd_read() calls pr_netio_telnet_gets():
if (pr_netio_telnet_gets(buf, sizeof(buf)-1, [...]
The second parameter of pr_netio_telnet_gets() is "sizeof(buf)-1",
so its value is :
sizeof(buf)-1 =
(PR_DEFAULT_CMD_BUFSZ+1)-1 =
PR_DEFAULT_CMD_BUFSZ = [defined in src/main.c]
PR_TUNABLE_PATH_MAX + 7 = [defined in include/options.h]
MAXPATHLEN + 7 = [on Linux, MAXPATHLEN==4096]
4096 + 7 =
4103
The function pr_netio_telnet_gets() is defined in src/netio.c
(line 991):
pr_netio_telnet_gets(char *buf, size_t buflen, [...]
We have buflen==4103. It is first decremented, and then
each read character decrements it. This is inside a loop
which stops when buflen==0, or when a '\n' character
is found (line 1039).
However, on line 1073, there is:
buflen--;
So, buflen can be decremented by TWO inside the loop. This
case occurs because the function processes TELNET_IAC
escape characters followed by a TELNET_xyz character.
So, successive buflen values can be :
4103
4102
...
3
2
1 (here we manage to decrement by TWO, by putting
a TELNET_IAC character at this location)
-1
-2
...
So, the loop never stops because buflen is never zero.
The loop will only stop when a '\n' character is found
(line 1039).
So, every character between the TELNET_IAC and the
'\n' will overflow the stack buffer. This is a classical
stack overflow.
-- CREDIT --------------------------------------------------------------
This vulnerability was discovered by:
10, (AV:N/AC:L/Au:N/C:C/I:C/A:C)
-- ABSTRACT ------------------------------------------------------------
TippingPoint has identified a vulnerability affecting the following
products:
ProFTPD FTP Server
-- VULNERABILITY DETAILS -----------------------------------------------
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of ProFTPD. Authentication is not required to
exploit this vulnerability.
The flaw exists within the proftpd server component which listens by
default on TCP port 21. When reading user input if a TELNET_IAC escape
sequence is encountered the process miscalculates a buffer length
counter value allowing a user controlled copy of data to a stack buffer.
A remote attacker can exploit this vulnerability to execute arbitrary
code under the context of the proftpd process.
Tested on proftpd-1.3.3a.
[Switching to process 31268]
0x0806d498 in pr_netio_telnet_gets (buf=0xbf979ffc 'A'
at netio.c:1103
1103 *bp++ = cp;
FTP commands are read by function pr_cmd_read() of file
src/main.c (line 566).
The function pr_cmd_read() uses a local buffer (line 568):
char buf[PR_DEFAULT_CMD_BUFSZ+1] = {'\0'};
At line 582, pr_cmd_read() calls pr_netio_telnet_gets():
if (pr_netio_telnet_gets(buf, sizeof(buf)-1, [...]
The second parameter of pr_netio_telnet_gets() is "sizeof(buf)-1",
so its value is :
sizeof(buf)-1 =
(PR_DEFAULT_CMD_BUFSZ+1)-1 =
PR_DEFAULT_CMD_BUFSZ = [defined in src/main.c]
PR_TUNABLE_PATH_MAX + 7 = [defined in include/options.h]
MAXPATHLEN + 7 = [on Linux, MAXPATHLEN==4096]
4096 + 7 =
4103
The function pr_netio_telnet_gets() is defined in src/netio.c
(line 991):
pr_netio_telnet_gets(char *buf, size_t buflen, [...]
We have buflen==4103. It is first decremented, and then
each read character decrements it. This is inside a loop
which stops when buflen==0, or when a '\n' character
is found (line 1039).
However, on line 1073, there is:
buflen--;
So, buflen can be decremented by TWO inside the loop. This
case occurs because the function processes TELNET_IAC
escape characters followed by a TELNET_xyz character.
So, successive buflen values can be :
4103
4102
...
3
2
1 (here we manage to decrement by TWO, by putting
a TELNET_IAC character at this location)
-1
-2
...
So, the loop never stops because buflen is never zero.
The loop will only stop when a '\n' character is found
(line 1039).
So, every character between the TELNET_IAC and the
'\n' will overflow the stack buffer. This is a classical
stack overflow.
-- CREDIT --------------------------------------------------------------
This vulnerability was discovered by:
* Anonymous
Playing with MS10-061
General Information
Executive Summary
This security update resolves a publicly disclosed vulnerability in the Print Spooler service. The vulnerability could allow remote code execution if an attacker sends a specially crafted print request to a vulnerable system that has a print spooler interface exposed over RPC. By default, printers are not shared on any currently supported Windows operating system.
This security update is rated Critical for all supported editions of Windows XP, and Important for all supported editions of Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. For more information, see the subsection, Affected and Non-Affected Software, in this section.
The security update addresses the vulnerability by correcting the manner in which the Printer Spooler service validates user permissions. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.
Recommendation. The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.
For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.
See also the section, Detection and Deployment Tools and Guidance, later in this bulletin.
Read More
Let's write some thing to %SystemRoot%\\system32 ;))
Download the demo video and play with me :)
Link
Executive Summary
This security update resolves a publicly disclosed vulnerability in the Print Spooler service. The vulnerability could allow remote code execution if an attacker sends a specially crafted print request to a vulnerable system that has a print spooler interface exposed over RPC. By default, printers are not shared on any currently supported Windows operating system.
This security update is rated Critical for all supported editions of Windows XP, and Important for all supported editions of Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. For more information, see the subsection, Affected and Non-Affected Software, in this section.
The security update addresses the vulnerability by correcting the manner in which the Printer Spooler service validates user permissions. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.
Recommendation. The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.
For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.
See also the section, Detection and Deployment Tools and Guidance, later in this bulletin.
Read More
Let's write some thing to %SystemRoot%\\system32 ;))
Playing with MS10-061 Vietnamese from Sangteamtham on Vimeo.
Download the demo video and play with me :)
Link
Tuesday, September 7, 2010
New Twitter XSS vulnerability
Twitter XSS vulnerability on http://dev.twitter.com/apps/
When you sign up for application, you can authorize some domains. Then, instead of adding domains, you add some malicious code into the form.
I found it today and reported it to twitter.
Subscribe to:
Posts (Atom)