Vulnerability: back door in stupid spamming software
About EPractize Labs:
EPractize Labs is fully Customer Focused, Innovative and Global
service provider for Skill Development and Skill Evaluation products
suitable for pre employment assessment testing, employee evaluation
for appraisal, employ
> Very useful john jacob ... really helpful.
> do you maintaine your blog or any other resource you want to share with us.
> thanx a ton .
Thank you for the kind words and I consider it an honor to have been helpful.
I do not have a blog. I have enjoyed this thread, sharing what I know, and
l
Thanks for that. I've learnt a lot from this thread. Peace to you all.
On 5 December 2011 20:11, Gage Bystrom wrote:
> Tripwire is awesome for many reasons. The original use of rootkit
> detection is no longer one of them. It was used back when userland rootkits
> were big, it has zero effect on
Very useful john jacob ... really helpful.
do you maintaine your blog or any other resource you want to share with us.
thanx a ton .
On Mon, Dec 5, 2011 at 8:18 AM, Michael Wood wrote:
> Awesome tips guys...
>
> On Dec 5, 2011 11:01 AM, "John Jacobs" wrote:
>>
>>
>> > 2. Do you think said phpmya
Really enjoying following this thread. Any one have thoughts/opinions
on APF as an option to prevent this in the future?
On Mon, Dec 5, 2011 at 11:18 AM, Michael Wood wrote:
> Awesome tips guys...
>
> On Dec 5, 2011 11:01 AM, "John Jacobs" wrote:
>>
>>
>> > 2. Do you think said phpmyadmin vulns
I'd check these too:http://virtuemart.net/security-bulletinsOn Dec 05, 2011, at 05:35 AM, mitchell wrote:Hi,Here is what you generally need to do in such cases.1. Suspend the webapp until you investigate.2. Check the web server logs for unusual entries and identify the entry point. You should have
--
CVE-2011-4343: Apache MyFaces information disclosure vulnerability
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
MyFaces Core 2.0.1 to 2.0.10
Hi,I'd say tell your boss your application has been compromised right away. Tell them you'll need to rebuild the entire system from scratch and they'll need to either devise an upgrade path for virtuemart or find a new ecommerce solution.You can't trust a system once it has been compromised. --
Thanks for the heads-up on rkhunter Gage.
Is there anything else out there atm that works as a reasonable root kit
detector or is such a thing considered impossible now? I realise a skilled
attack will be able to bury itself without a trace, but I'm thinking of
something that can be used in less s
A good start would have been to take a snapshot of your compromized
system and not to delete any file.
Now, good luck to understand what happened.
Aris
Le 5/12/11 11:44, Lucio Crusca a écrit :
> Hello *,
>
> I'm not new here, but I've mostly lurked all the time through gmane. I never
> believed
> http://seclists.org/nmap-hackers/2011/5
>
That's pathetic. Anonymous is usually being called on situations like this
...
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Sec
http://seclists.org/nmap-hackers/2011/5
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
In addition to the tips given (chroot, disable shell_exec,etc), you
should also use open_basedir with DocumentRoot as path on each
VirtualHost. In case of a compromise via webapp, this will reduce the
compromised zone in the filesystem to the DocumentRoot of one
VirtualHost instead of the whole chr
Tripwire is awesome for many reasons. The original use of rootkit detection
is no longer one of them. It was used back when userland rootkits were big,
it has zero effect on kernel rootkits. That being said you can use it to
watch other critical files for improper access. Keep tabs on your cron
fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -
Debian Security Advisory DSA-2358-1 secur...@debian.org
http://www.debian.org/security/
December 05, 2011
> Why take the risk? You don't know what the attacker actually did
> until you do some analysis. If you do analysis before capturing a
> disk image, you're destroying evidence.
>
> Rebuilding a server is not hard. It has a known quantity of effort
> involved and reliably prevents further intrusion
John Jacobs wrote:
> In my previous experience, including a few vulnerabilities in Roundcube,
> I've seen a programmatic scan, exploitation, and then wget/dropping of a
> Perl IRC bot. Of course this is all speculation based on previous
> experience, I am not looking at lucio's box. The Apache a
--On December 5, 2011 11:44:04 AM +0100 Lucio Crusca
wrote:
>
> Now the problem is: how do I pervent further abuse? What should I search
> in the logs (if anything) to spot the security hole?
>
Install mod-security and write custom rules to prevent the hack. Look in
your webserver logs to se
> Well, I actually made 2 mistakes and the second compensated the harm the
> first did...
>
> My second mistake I did not mention before was to overlook various other
> folders in /tmp that were older than /tmp/.m and contained lots of other
> crap (so they are even more useful in finding the o
--On December 5, 2011 1:48:24 PM +0100 Christophe Garault
wrote:
>>
> Having your /tmp partition with noexec,nosuid is also considered a good
> practice.
That's not a bad generic suggestion, but it won't do a thing for this hack.
They deposit perl scripts in /tmp/.m and then run them by callin
> Subject: Re: [Full-disclosure] one of my servers has been compromized
> From: ja...@zero-internet.org.uk
> Date: Mon, 5 Dec 2011 17:36:53 +
> CC: tim-secur...@sentinelchicken.org; lu...@sulweb.org;
> full-disclosure@lists.grok.org.uk
> To: flamdu...@
> > For future reference, and for the benefit of people searching for
> > solutions to similar problems: You've made the most common rookie
> > mistake. You have already trashed potentially critical information
> > about the attack by trying to clean up the server first. Don't do
> > that.
>
> Tim
Tim wrote:
>
> For future reference, and for the benefit of people searching for
> solutions to similar problems: You've made the most common rookie
> mistake.
Well, I actually made 2 mistakes and the second compensated the harm the
first did...
My second mistake I did not mention before was t
John,
All good thoughts but can we show the server was rooted?
In otherwords; instead of an attacker getting root and then adding this to a
botnet this way is it not more likely that the original attack added the server
in one step to avoid the need to do this?
Attackers, from my experience, d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/2011 10:44, Lucio Crusca wrote:
> Hello *,
>
> I'm not new here, but I've mostly lurked all the time through gmane. I never
> believed it could happen to me until it actually happened: they compromized
> one of my servers. It's a Ubuntu 10.
> For future reference, and for the benefit of people searching for
> solutions to similar problems: You've made the most common rookie
> mistake. You have already trashed potentially critical information
> about the attack by trying to clean up the server first. Don't do
> that.
Tim, while I do
For future reference, and for the benefit of people searching for
solutions to similar problems: You've made the most common rookie
mistake. You have already trashed potentially critical information
about the attack by trying to clean up the server first. Don't do
that.
> I've run the "find" c
Awesome tips guys...
On Dec 5, 2011 11:01 AM, "John Jacobs" wrote:
>
> > 2. Do you think said phpmyadmin vulns are reasonable attack vectors in my
> > case?
>
> I do, I believe this is to be the initial infection vector. Scanning for
> PHPMyAdmin is often and frequent and since it's likely that
> 2. Do you think said phpmyadmin vulns are reasonable attack vectors in my
> case?
I do, I believe this is to be the initial infection vector. Scanning for
PHPMyAdmin is often and frequent and since it's likely that it was present in
it's default (or one of the default) URIs discovery is like
Gage Bystrom wrote:
> Fortunately for him, since the bot was so easy to find in the first place
> and such a simple way of maintaining it, the box was clearly seized by
> someone who didn't give a rats ass about it. Probably a skiddie or an
> automated attack to begin with.
That makes me think th
Hi,
Here is what you generally need to do in such cases.
1. Suspend the webapp until you investigate.
2. Check the web server logs for unusual entries and identify the entry
point. You should have noticed the timestamp of the Perl script in the /tmp
directory. Try looking for entries around this t
On 12/O5/2011 13:07, Lucio Crusca wrote :
> Ferenc Kovacs wrote:
>
> No, it's just common saying. I apply patches, change password regularly,
> move ssh to nonstandard ports, disable remote root access and do all the
> rest I've learnt about security in years of running linux servers, also if I
You could ch-root your apache process/webserver going forward. This would
effectively stop the malicious process when/if your machine is compromised
via web based vulnerabilities to spread to entire machine.. meaning your
area of investigation is more isolated.
I'd expect if its automatically spre
Ferenc Kovacs wrote:
> ps: "I neverbelieved it could happen to me until it actually happened:
> they compromizedone of my servers." this is a really bad attitude.
No, it's just common saying. I apply patches, change password regularly,
move ssh to nonstandard ports, disable remote root access an
On Mon, Dec 5, 2011 at 11:44 AM, Lucio Crusca wrote:
> Hello *,
>
> I'm not new here, but I've mostly lurked all the time through gmane. I
> never
> believed it could happen to me until it actually happened: they compromized
> one of my servers. It's a Ubuntu 10.04 server with all security patche
If it was a rootkit then trying to run the outdated rkhunter would be a
moot point. Whatever seizes the kernel first wins, hands down.
Fortunately for him, since the bot was so easy to find in the first place
and such a simple way of maintaining it, the box was clearly seized by
someone who didn't
Dan Ballance wrote:
> I'm no expert, but here's something to get you started while you wait for
> more experienced replies. Check for root kits:
>
> sudo apt-get install rkhunter
> sudo rkhunter --update
> sudo rkhunter --check
Thanks for the tip, I've ran those but the check found nothing. I ke
I'm no expert, but here's something to get you started while you wait for
more experienced replies. Check for root kits:
sudo apt-get install rkhunter
sudo rkhunter --update
sudo rkhunter --check
On 5 December 2011 10:44, Lucio Crusca wrote:
> Hello *,
>
> I'm not new here, but I've mostly lurk
Hello *,
I'm not new here, but I've mostly lurked all the time through gmane. I never
believed it could happen to me until it actually happened: they compromized
one of my servers. It's a Ubuntu 10.04 server with all security patches
regularly applied. I'm inclined to believe they used some hol
Any specific dictionary file/collection work best for you,and was wpa
involved, ifso, wich list was best there.. just, somuch to download
there..like 15gig :s i would rather hone in on the effective one :)
thanks mate!
drew
On 5 December 2011 19:28, Alessandro Tagliapietra
wrote:
> Get g0tmi1k's
Get g0tmi1k's password list, for me there is lot of work behind and i've
found that working fine ;)
http://g0tmi1k.blogspot.com/2011/06/dictionaries-wordlists.html
Regards
2011/12/2 Charles Morris
> Of course, you are quite right, it follows,
> and it's been many years since I've used anything
On Wed, Nov 30, 2011 at 1:30 PM, Adam Behnke wrote:
Hello full disclosureites, a new tutorial is available at InfoSec Institute
...
Your thoughts?
>>who was this content plagiarized from?
I wrote it. It wasn't plagarized from anywhere.
___
Full-Discl
Creative Commons BY-SA might be more appropriate than the GPL.
On Dec 2, 2011 10:41 AM, "Travis Biehn" wrote:
> My password leaks will all be released under the GPL.
>
> -Travis
>
> On Fri, Dec 2, 2011 at 7:28 AM, Mario Vilas wrote:
>
>> On Fri, Dec 2, 2011 at 3:05 AM, adam wrote:
>>
>>> C:\Use
43 matches
Mail list logo
