Community Discussions and Support
Critical security patches for Mercury/32 and Mercury/NLM

Here one can find a real exploit code (not just crashing the server!). As far as I can tell, it executes shell code, but to the real malware exploitation, it's "a small step in programming, but a giant leap to hijacking the machine...".

 

http://securityreason.com/exploitalert/2657

 

 

<p>Here one can find a real exploit code (not just crashing the server!). As far as I can tell, it executes shell code, but to the real malware exploitation, it's "a small step in programming, but a giant leap to hijacking the machine...".</p><p> </p><p>http://securityreason.com/exploitalert/2657</p><p> </p><p> </p>

Patches are now available to correct a potentially severe security weakness in the MercuryS SMTP server. This vulnerability affects the SMTP AUTH command and can result in crashes or, in the worst case, remote execution exploits. In essence, all current versions of Mercury are potentially affected to some extent by this problem.

Given the potential seriousness of this problem, we have produced three different patches:

  • For users of Mercury/32, a new release, v4.52 is available.

  • For users of Mercury/32 v4.01b who do not wish to upgrade to Mercury/32 v4.52 at this time, a v4.01c patch is available, which can be retrofitted into Mercury/32 v4.01b systems.

  • For users of the NLM version of Mercury, a patch is provided for both the Bindery and NDS mode versions of MercuryS.

All sites should regard this upgrade as critical.

For more information on these patches, please visit our official web site, http://www.pmail.com, and follow the "Newsflash" links on the front page.

Cheers!

-- David --
Patches are now available to correct a potentially severe security weakness in the MercuryS SMTP server. This vulnerability affects the SMTP AUTH command and can result in crashes or, in the worst case, remote execution exploits. In essence, all current versions of Mercury are potentially affected to some extent by this problem. Given the potential seriousness of this problem, we have produced three different patches: <UL> <LI>For users of Mercury/32, a new release, v4.52 is available.</LI></UL> <UL> <LI>For users of Mercury/32 v4.01b who do not wish to upgrade to Mercury/32 v4.52 at this time, a v4.01c patch is available, which can be retrofitted into Mercury/32 v4.01b systems.</LI></UL> <UL> <LI>For users of the NLM version of Mercury, a patch is provided for both the Bindery and NDS mode versions of MercuryS.</LI></UL> All sites should regard this upgrade as critical. For more information on these patches, please visit our official web site, <A class="" title=http://www.pmail.com href="http://www.pmail.com/" target=_blank mce_href="http://www.pmail.com">http://www.pmail.com</A>, and follow the "Newsflash" links on the front page. Cheers! -- David --

All v4.x versions of Mercury earlier

than v4.51 are vulnerable to this exploit, and users should

regard the upgrade to v4.52 as mandatory.

David, 4.51 is also vulnerable. So this should read: "...v4.51 and earlier... " !!

You should amend the announcement on http://www.pmail.com/

 

<p>[i]All v4.x versions of Mercury [b]earlier than v4.51 are vulnerable to this exploit[/b], and users should regard the upgrade to v4.52 as mandatory.[/i]</p><p>David, 4.51 is also vulnerable. So this should read: "...v4.51 and earlier... " !!</p><p>You should amend the announcement on http://www.pmail.com/</p><p> </p>

Corrected now. It was meant to say "all versions earlier than v4.51 are ALSO vulnerable".

That's the problem with having to do a release like this in such a hurry. If "eliteb0y" had had the common decency to give me even day's notice about this I could have approached the fix in a more measured way, but he made no effort to contact me at all, so it was "panic stations, drop everything or die"... [:(]

It's not easy for me to describe how stressful this kind of thing is... I'm feeling utterly drained and low at the moment; I've been pulling 18 hour days since the damned exploit came out and it's going to take me a while to recover. Don't get me wrong here - I have no problem with bug disclosure, but the fact that NOBODY involved in the disclosure made even the smallest attempt to get in touch with me before or after it was made public is galling and wrong. I shouldn't have to hear about this thing from my users.

-- David --

<p>Corrected now. It was meant to say "all versions earlier than v4.51 are ALSO vulnerable". That's the problem with having to do a release like this in such a hurry. If "eliteb0y" had had the common decency to give me even day's notice about this I could have approached the fix in a more measured way, but he made no effort to contact me at all, so it was "panic stations, drop everything or die"... [:(] It's not easy for me to describe how stressful this kind of thing is... I'm feeling utterly drained and low at the moment; I've been pulling 18 hour days since the damned exploit came out and it's going to take me a while to recover. Don't get me wrong here - I have no problem with bug disclosure, but the fact that NOBODY involved in the disclosure made even the smallest attempt to get in touch with me before or after it was made public is galling and wrong. I shouldn't have to hear about this thing from my users. -- David -- </p>

[quote user="David Harris"]

Corrected now. It was meant to say "all versions earlier than v4.51 are ALSO vulnerable".

That's the problem with having to do a release like this in such a hurry. If "eliteb0y" had had the common decency to give me even day's notice about this I could have approached the fix in a more measured way, but he made no effort to contact me at all, so it was "panic stations, drop everything or die"... [:(]

It's not easy for me to describe how stressful this kind of thing is... I'm feeling utterly drained and low at the moment; I've been pulling 18 hour days since the damned exploit came out and it's going to take me a while to recover. Don't get me wrong here - I have no problem with bug disclosure, but the fact that NOBODY involved in the disclosure made even the smallest attempt to get in touch with me before or after it was made public is galling and wrong. I shouldn't have to hear about this thing from my users.

-- David --

[/quote]

 

Wholeheartedly agree with you!!

 

 

[quote user="David Harris"]<p>Corrected now. It was meant to say "all versions earlier than v4.51 are ALSO vulnerable". That's the problem with having to do a release like this in such a hurry. If "eliteb0y" had had the common decency to give me even day's notice about this I could have approached the fix in a more measured way, but he made no effort to contact me at all, so it was "panic stations, drop everything or die"... [:(] It's not easy for me to describe how stressful this kind of thing is... I'm feeling utterly drained and low at the moment; I've been pulling 18 hour days since the damned exploit came out and it's going to take me a while to recover. Don't get me wrong here - I have no problem with bug disclosure, but the fact that NOBODY involved in the disclosure made even the smallest attempt to get in touch with me before or after it was made public is galling and wrong. I shouldn't have to hear about this thing from my users. -- David -- </p><p>[/quote]</p><p> </p><p>Wholeheartedly agree with you!!</p><p> </p><p> </p>

Something is very weird here,

I was using v4.01b, all of a sudden, mail stops working, I log in and see that mercury is now v4.52 (Without me installing it and I dont quite remember an auto-update option) and mail no longer works.

I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.

I wasn't aware of any automatic update option, not to mention that if there was such a procedure in place, I guess there is a problem in its implementation.

<P>Something is very weird here,</P> <P>I was using v4.01b, all of a sudden, mail stops working, I log in and see that mercury is now v4.52 (Without me installing it and I dont quite remember an auto-update option) and mail no longer works.</P> <P>I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.</P> <P>I wasn't aware of any automatic update option, not to mention that if there was such a procedure in place, I guess there is a problem in its implementation.</P>

[quote user="Moshe"]

Something is very weird here,

I was using v4.01b, all of a sudden, mail stops working, I log in and see that mercury is now v4.52 (Without me installing it and I dont quite remember an auto-update option) and mail no longer works.

I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.

I wasn't aware of any automatic update option, not to mention that if there was such a procedure in place, I guess there is a problem in its implementation.

[/quote]

 

There is no automatic update option, someone ran m32-452.exe over the v4.01b as an update.  

 

[quote user="Moshe"]<p>Something is very weird here,</p> <p>I was using v4.01b, all of a sudden, mail stops working, I log in and see that mercury is now v4.52 (Without me installing it and I dont quite remember an auto-update option) and mail no longer works.</p> <p>I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.</p> <p>I wasn't aware of any automatic update option, not to mention that if there was such a procedure in place, I guess there is a problem in its implementation.</p><p>[/quote]</p><p> </p><p>There is no automatic update option, someone ran m32-452.exe over the v4.01b as an update.  </p><p> </p>

[quote user="Moshe"] I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.[/quote]

You must have managed to do a clean install beside the 4.01b setup, without stopping the running mercury at hand. Best practice is always to stop a server software, back it up, then do the upgrades or patching process.

Also - since you were running 4.01b you failed to download the actual patches for this version, taking it to 4.01c (with the imap patch) and then the MercuryS patch.

It is however recommended to upgrade previous versions to 4.52 at the earliest convenience.

<P>[quote user="Moshe"] I check the running processes and see there are two instances of "mercury.exe". Closing mercury and killing the other process and mail starts working again.[/quote]</P> <P>You must have managed to do a clean install beside the 4.01b setup, without stopping the running mercury at hand. Best practice is always to stop a server software, back it up, then do the upgrades or patching process. </P> <P>Also - since you were running 4.01b you failed to download the actual patches for this version, taking it to 4.01c (with the imap patch) and then the MercuryS patch.</P> <P>It is however recommended to upgrade previous versions to 4.52 at the earliest convenience.</P>

Crosspost from the Pmail/Mercury Mailing list: 
 
Thomas R. Stephenson wrote:



They have a robot checking all IP addresses for an active port 25 and then the robot tries the

exploit.  They really do not care how many times it fails, they simply want to find the servers

where it does not fail.  The actual exploit as provided was not all that big a deal, it only

crashed the program.  The ones you worry about are the ones that use the vulnerability to

actually access and run code on the host. 


These hackers really like these vulnerability reporting forums that do not pass the exploit on to

the developer when reporting it to the subscribers of it's reports (actually the developer should

get this before it's reported to the entire world).  It's just like getting a zero day virus since the

guy that can fix it has never been notified by anyone until the users happen to notice this and

report it. 



Meanwhile I've got a third attempt. From the logs I must assume that

they are acting in a surprisingly clever way:


They first verify the server's reaction by attempting a plain vanilla


AUTH CRAM-MD5


aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.....



with ~1k of these "aaaaaa"



As SBK alraedy filters that out, I can't tell what would coming next.

But there's to expect they either record the result with the IP of the

vulnerable system and would attack at a later time, or they will make

immediately follow a subsequent attack with the real payload to be put

on the stack. For the latter I've no time/eagerness as to know how they

actually would infect/takeover the system.



But it's most evident that we have to expect a huge number of Mercury

systems being transformed into zombies over the next days and weeks, as

this vulnerability is definitely actively exploited RIGHT NOW!





-- 


Developer of SpamBunker


http://www.spambunker-dev.ch/


<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 13px;" lang="x-unicode">Crosspost from the Pmail/Mercury Mailing list: </div><div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 13px;" lang="x-unicode"> </div><div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 13px;" lang="x-unicode">Thomas R. Stephenson wrote: </div><div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 13px;" lang="x-unicode"><blockquote type="cite"> They have a robot checking all IP addresses for an active port 25 and then the robot tries the exploit.  They really do not care how many times it fails, they simply want to find the servers where it does not fail.  The actual exploit as provided was not all that big a deal, it only crashed the program.  The ones you worry about are the ones that use the vulnerability to actually access and run code on the host.  These hackers really like these vulnerability reporting forums that do not pass the exploit on to the developer when reporting it to the subscribers of it's reports (actually the developer should get this before it's reported to the entire world).  It's just like getting a zero day virus since the guy that can fix it has never been notified by anyone until the users happen to notice this and report it.  </blockquote> Meanwhile I've got a third attempt. From the logs I must assume that they are acting in a surprisingly clever way: They first verify the server's reaction by attempting a plain vanilla AUTH CRAM-MD5 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa..... with ~1k of these "aaaaaa" As SBK alraedy filters that out, I can't tell what would coming next. But there's to expect they either record the result with the IP of the vulnerable system and would attack at a later time, or they will make immediately follow a subsequent attack with the real payload to be put on the stack. For the latter I've no time/eagerness as to know how they actually would infect/takeover the system. But it's most evident that we have to expect a huge number of Mercury systems being transformed into zombies over the next days and weeks, as this vulnerability is definitely actively exploited RIGHT NOW! <div class="moz-txt-sig"><span class="moz-txt-tag">--  </span> Developer of SpamBunker <a href="http://www.spambunker-dev.ch/" class="moz-txt-link-freetext">http://www.spambunker-dev.ch/</a> </div></div>

It looks as if my server got compromised.

check for files here:
c:\windows\java\classes\java.dll
c:\windows\java\classes\javavm.exe

I tried scanning with multiple anti-virus software.  The free ClamWin anti-virus only reported a virus on "java.dll".  I then ran the kaspersky anti-virus which detected both files.  The trojan opened a port (2004) through the windows firewall, it looks as if it's a modified ServU ftp server.  The entry for this port in the firewall setup was even named Mercury, so unless Mercury adds its own windows firewall entry, this has a good chance of being connected.

I strongly suspect that the hackers have a script that compromises systems and then installs v4.52 automatically for you so that whomever did it wont have to compete with others compromising the same system (which I suspect caused the issue with multiple instances of mercury.exe running).

I actually had 4.01c installed (I wrote "b" earlier by mistake) and then it magically turned into v4.52 without me (or anyone else) doing anything.

<P>It looks as if my server got compromised.</P> <P>check for files here: c:\windows\java\classes\java.dll c:\windows\java\classes\javavm.exe I tried scanning with multiple anti-virus software.  The free ClamWin anti-virus only reported a virus on "java.dll".  I then ran the kaspersky anti-virus which detected both files.  The trojan opened a port (2004) through the windows firewall, it looks as if it's a modified ServU ftp server.  The entry for this port in the firewall setup was even named Mercury, so unless Mercury adds its own windows firewall entry, this has a good chance of being connected.</P> <P>I <U>strongly</U> suspect that the hackers have a script that compromises systems and then installs v4.52 automatically for you so that whomever did it wont have to compete with others compromising the same system (which I suspect caused the issue with multiple instances of mercury.exe running).</P> <P>I actually had 4.01c installed (I wrote "b" earlier by mistake) and then it magically turned into v4.52 without me (or anyone else) doing anything.</P>

Nonono, no way they install 4.52 via script since it removes the vulnerability.

However, assuming they managed to run a script, they most likely used TFTP to download arbitrary code. Assuming you only have windows fw against the outside world, and you run an ftp server I'd say you've been lucky so far, and I strongly believe that you got hit earlier than the exploit was out - unless you can trace back the change of java.dll to pinpoint with the auth logs that MercuryS produces.

<P>Nonono, no way they install 4.52 via script since it removes the vulnerability.</P> <P>However, assuming they managed to run a script, they most likely used TFTP to download arbitrary code. Assuming you only have windows fw against the outside world, and you run an ftp server I'd say you've been lucky so far, and I strongly believe that you got hit earlier than the exploit was out - unless you can trace back the change of java.dll to pinpoint with the auth logs that MercuryS produces.</P>

I've just updated the Mercury/NLM to version 1.49, but it still reports as version 1.48 so now I am in doubt that I have done it correctly.  Is it correct that version 1.49 reports as version 1.48, copyright (c) 1993-2000  ?

 

<p>I've just updated the Mercury/NLM to version 1.49, but it still reports as version 1.48 so now I am in doubt that I have done it correctly.  Is it correct that version 1.49 reports as version 1.48, copyright (c) 1993-2000  ?</p><p> </p>

[quote user="Peter Strömblad"]

Nonono, no way they install 4.52 via script since it removes the vulnerability.

[/quote]

If they can download additional code and execute it in first place, why should they not be able to transfer and execute a 4.52 installer (original or "customised")?

And what Moshe pointed out, that patching to 4.52 *AFTER* compromising the system, makes perfect sense. That would prevent "competitors" from taking advantage of the same hole and replacing the installed malware with their own.

So writing about "Nonono, no way..." is pretty much wrong.


[quote user="Peter Strömblad"]<p>Nonono, no way they install 4.52 via script since it removes the vulnerability.</p><p> [/quote]</p><p>If they can download additional code and execute it in first place, why should they not be able to transfer and execute a 4.52 installer (original or "customised")?</p><p>And what Moshe pointed out, that patching to 4.52 *AFTER* compromising the system, makes perfect sense. That would prevent "competitors" from taking advantage of the same hole and replacing the installed malware with their own.</p><p>So writing about "Nonono, no way..." is pretty much wrong.</p><p> </p>

Peter:
I'm not sure you understood me.
What I said is that they:

1. They inserted their trojans using the exploit.
2. Once the exploit was in place and gave them backdoor+ftp access (they had two trojans in place, one a remote desktop and the other an FTP server) they installed Mercury 4.52 in order to prevent others from using the same exploit.  They didn't care if it fixed the exploit as they already had their backdoor established.

I can lock down the time of the exploit to Aug 26-27th.  And the fact that I didn't install mercury v4.52 myself should give you a hugh clue that it was part of the exploit (no one else has access to the computer).

<P>Peter: I'm not sure you understood me. What I said is that they:</P> <P>1. They inserted their trojans using the exploit. 2. Once the exploit was in place and gave them backdoor+ftp access (they had two trojans in place, one a remote desktop and the other an FTP server) they installed Mercury 4.52 in order to prevent others from using the same exploit.  They didn't care if it fixed the exploit as they already had their backdoor established.</P> <P>I can lock down the time of the exploit to Aug 26-27th.  And the fact that I didn't install mercury v4.52 myself should give you a hugh clue that it was part of the exploit (no one else has access to the computer).</P>

[quote user="Beggi"]

I've just updated the Mercury/NLM to version 1.49, but it still reports as version 1.48 so now I am in doubt that I have done it correctly.  Is it correct that version 1.49 reports as version 1.48, copyright (c) 1993-2000  ?

[/quote]

 

Still reports as v1.48 when connecting to port 25.  You can test this to ensure you have the right one by telnet into port 25 and issuing an auth command and then responding with a really long string.   

[quote user="Beggi"]<p>I've just updated the Mercury/NLM to version 1.49, but it still reports as version 1.48 so now I am in doubt that I have done it correctly.  Is it correct that version 1.49 reports as version 1.48, copyright (c) 1993-2000  ?</p><p>[/quote]</p><p> </p><p>Still reports as v1.48 when connecting to port 25.  You can test this to ensure you have the right one by telnet into port 25 and issuing an auth command and then responding with a really long string.   </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft