Email worms propagate by extracting contact information from the address book of each infected user, and then sending out an email with the worm payload to each contact — a user needs only to open an infected email message to spread the worm.

Prior-concept email worms have been restricted to affecting only one email client; however, the Nduja Connection worm has the potential to spread faster due to its ability to infect users of four different web email clients.

The four web-mail services affected by the worm are Italian providers Libero.it, Tiscali.it, Lycos.it and Excite.com. “The choice of the providers of this [proof of concept] has been bound to the presence of an exploitable [vulnerability] (with the above features) within the web-mail domain. Also other popular providers (for example Gmail, Yahoo, Hotmail) suffer from XSS [vulnerabilities] in their web-mails, but their severity is not so high to let worms like Nduja Connection to propagate,” Valotta wrote.

Web-mail worms have existed in the wild since 2006, when the Yamanner worm targeted the Yahoo email system and spread quickly throughout users of the system. It is difficult to quickly stop or slow the spread of this kind of worm once it has begun, due to its use of JavaScript. Turning off JavaScript in the browser renders the web-mail system unusable.

“Some of the same techniques that malware authors use in order to infect victims with malware are being used to distribute links and drive traffic to all sorts of web content,” Howard said.

“The attack targets legitimate message boards with hidden links to direct users to child pornography sites, and was even found on a site designed for children.

“Web hosts must deploy web filters which filter based on website categorisation, and inspect the code of every linked website prior to granting user access,” Howard said.

“All user content must be screened prior to posting because any unprotected website can be targeted by cyber-criminals trying to spread malicious content.”

Sophos has reported the targeted sites to online content regulator the Internet Watch Foundation.

Created by Darren Pauli

This is not the first time when Gmail is affected by a security flaw that can allow an attacker to view private information about the account as well as the messages kept in the inbox. Some time ago, the search giant confirmed the existence of numerous vulnerabilities but only after it managed to fix them because it was very important to avoid successful exploitations.

Gmail was released in April 2004 and was extremely attractive for the Internet users because it was the first mail solution to offer 1GB in storage size. Obviously, the product was periodically improved and it is now described as the most efficient mail service against spam messages because its filters manage to block the majority of unsolicited emails coming into your inbox.

The XSS security flaw that was just discovered is sustaining Google’s statements concerning the security of the mail solution and proves once again that even the Mountain View company can be affected by vulnerabilities. If you didn’t know, a critical hole was also discovered in Google Desktop, the downloadable application powered by Gooogle.

-[par][ SUMMARY ][/par]———————————————————————
0×01: Hello World
0×02: Introduction
0×03: About Authentications
0×04: Difference between XSS and CSRF
0×05: Get deep in CSRF
0×06: Attack Points
0×07: Prevention
0×08: Conclusions
———————————————————————————

[par]—[ 0x01: Hello World ][/par]

Yo!
Classical title for the first paragraph indeed Don’t think there’s a better name out there! Ok, i know it’s clueless, but let me do the ritual thanks and shoutouts and then i’ll move on serious business!

Intake: Actually some coke only, it’s too hot for eating anything :Q
Music: Rage Against The Machine – Know your Enemy

Shoutouts: as it comes all my playhack.net bros (Omni, GOD, Null and all the users), str0ke (the c00lest guy out there ) and my girlfriend, who’s having a bath right now and giving me the time to write this stuff (don’t tell her, she still think i’m working ) and obviously everyone reading this paper. Thanks!

[par]—[ 0x02: Introduction ][/par]

This kind of vulnerability, which is very common and understimated, permits to make a victim user to send any kind of HTTP request to a website in which he is logged in and trusted in some way.

In this way the attacker, forging some malicious HTML or JavaScript code, uses an opened session of the victim to make HIM doing actions, which really complicates the identification of a CSRF attack.

This Session Riding could easily be taken in action with markup languages (such as Blog’s and Wiki’s syntax) and BBcode too.

[par]—[ 0x03: About Authentications ][/par]

Commonly when a user logs into a trusted website, the authentication system will flag this person with a “token” that tells to the website that the current user is authed and authorized to visit some reserved pages and services.

These “tokens” are realized with the creations of Cookies and Sessions, commonly generated with some hashed or encoded number , which strictly identify a single user.

Anytime this user logs into the website with his own credentials he will be flagged and a new session will be generated, and meanwhile an attacker could easily makes some unauthorized actions in the “ward” of that website

It could looks like something quite un-dangerous, because only an idiot user will accept any kind of request that will disfrut his own authentication: great mistake! Don’t ever understimate the power of a sweet Cookie!

Cookies are the aim of the most XSS attacks because permits an instant access to any kind of confidential and private service an user has privileges on: the CSRF is even more powerful, because disfruts the current session and cannot be avoided easily if the website doesn’t provide very short temporary cookies.

[par]—[ 0x04: Difference between XSS and CSRF ][/par]

Actually, what’s the real difference between XSS and CSRF? They look very similars!

As a matter of fact they’re quite similars, but there’s a core difference that makes the two vulnerabilities strictly opposed eachothers.

In the XSS vulnerabilities the USER trusts the WEBSITE’s integrity, and gets tricked to give direct informations to the ATTACKER (with cookie grabbing of fake logins for example).

In the CSRF vulnerabilities is the WEBSITE that trusts in the USER’s requests and accomplish any kind of action that comes from his flagged authentication in order to get some advantages to the ATTACKER.

The Cross Site Request Forgery situation can be resumed with this graph:

.			      trusted <-----flag-----.
.	.----------.          .------.           .---|-----.
.	| ATTACKER |__________| USER |___________| WEBSITE |
.	`----------`  tricks  `------` (request) `---------`
.	      |           \_ _ _ _ _ _ _ _/          |
.	      |					     |
.	      `--------------------------------------`
.		the website accomplishes the request

As we can see the situation is opposed to the XSS' one, the website (trusting the authentication and the authorizations of the user) just accomplishes the request that are sent to him, which are obscured to the USER's awareness.

The important point of this attack is that the request to the website is sent by the USER, not the ATTACKER: this makes the vulnerability more dangerous.

[par]---[ 0x05: Get deep in CSRF ][/par]

Okay, now that we got a general idea of what CSRF is, let's try to get into some simple examples.

Assure that for example a user is subscribed into a website that provide some particular services, maybe which even schedule some money transactions: when the user logs in, the server will create a cookie or a session that flags the user as authed and authorized to access to his own private pages.

Assure also that the website is maybe a e-banking service and it provides an HTML form which perform money transactions, and the code will look like:

How much:

To:

ABI:

CAB:

CIN:





	

Through this form the user could transfer some money to the target bank account. Ok, it's really a stupid thing and quite impossible to be found right that, but it's only to make you understand the thing more clearly don't complain for that please!

Ok, when the user will submit the values of the form the script sendmoney.php will execute the query and make the e-banking system accomplish his request of transfer. Maybe the script will look like:

	/* sendmoney.php */
	
	/* EOF */

Consider that this script is well written and the send_money() sanitizes all the variables that are submitted to him, the transfer will be finally accomplished.

In this particular case the use of REQUEST global variable allows to an attacker to disfrut the GET method in order to trick the user and steal his money

If the user is authed in, as we previously said, an attacker could provide to the user a webpage or an image which will look like something like this:

Actually, if the user invited to visit this page is contemporary logged into the "bankhost.com" website, the image loaded will send an HTTP request to that website asking him to accomplish that transaction: the fact is that the transfer will be formerly commanded from the user himself.

Ok.. this is not really a good way for managing the transaction: the REQUEST global is not that safe, most probably the script sendmoney will use the POST variables instead, because they may think that it would be more secure. Obviously it is not.

Consider that the coolthing.html file will look instead like: