Creative Commons BY-SA might be more appropriate than the GPL.
On Dec 2, 2011 10:41 AM, Travis Biehn tbi...@gmail.com wrote:
My password leaks will all be released under the GPL.
-Travis
On Fri, Dec 2, 2011 at 7:28 AM, Mario Vilas mvi...@gmail.com wrote:
On Fri, Dec 2, 2011 at 3:05 AM,
On Wed, Nov 30, 2011 at 1:30 PM, Adam Behnke adam () infosecinstitute
com 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.
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 cmor...@cs.odu.edu
Of course, you are quite right, it follows,
and it's been many years since
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
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
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 lu...@sulweb.org wrote:
Hello *,
I'm not new here, but
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 keep
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
On Mon, Dec 5, 2011 at 11:44 AM, Lucio Crusca lu...@sulweb.org 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
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 and
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
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
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
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 the
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
Awesome tips guys...
On Dec 5, 2011 11:01 AM, John Jacobs flamdu...@hotmail.com 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
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
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
-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.04
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,
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 to
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
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:
--On December 5, 2011 1:48:24 PM +0100 Christophe Garault
let...@gmail.com 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
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
--On December 5, 2011 11:44:04 AM +0100 Lucio Crusca lu...@sulweb.org
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -
Debian Security Advisory DSA-2358-1 secur...@debian.org
http://www.debian.org/security/
December 05, 2011
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
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
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/
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
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 it
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
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. --
--
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
I'd check these too:http://virtuemart.net/security-bulletinsOn Dec 05, 2011, at 05:35 AM, mitchell mitch...@csc.bg 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.
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 itnet...@gmail.com wrote:
Awesome tips guys...
On Dec 5, 2011 11:01 AM, John Jacobs flamdu...@hotmail.com wrote:
2. Do you
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 itnet...@gmail.com wrote:
Awesome tips guys...
On Dec 5, 2011 11:01 AM, John Jacobs flamdu...@hotmail.com wrote:
Thanks for that. I've learnt a lot from this thread. Peace to you all.
On 5 December 2011 20:11, Gage Bystrom themadichi...@gmail.com 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,
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
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,
43 matches
Mail list logo
