Re: [Full-disclosure] PenTest Market is for FREE Now
{SNIP} If you wonder: What emplyers expect
from pentesters/ IT security specialists?
Would it be premature of me to think one of the things emplyers [sic] would
expect would be proper spelling and proofreading, especially when making a
product announcement peddling my wares?
Cheers,
John Jacobs
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
Those considering Tripwire I would ask they take a look at OSSEC-HIDS; the filesystem change notification is outstanding and with inotify() support you get immediate notification of changes. The monitoring and alerting of log files is also exceptional. I am not affiliated with OSSEC in any way. http://www.ossec.net/main/about I would recommend from a rooting aspect that kernel module loading be disabled after boot. This is accomplished by removing the CAP_SYS_MODULE permission using something like lcap on older systems or by using the sysctl value of 'kernel.modules_disabled = 1'. This can save a box by preventing automatic or intentional loading of a vulnerable modules or a module-based rootkit. The sysctl value of 'kernel.panic_on_oops = 1' also is a good idea. Thanks, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
Sounds pretty neat to be honest. But one thing I'm wondering is that if they have root, what's stopping them from turning that off? After all they need root to load the modules in the first place, so if they are in a position to want to do that, then they are in a position to turn that off. Granted they probably wouldn't be able to load modules till next boot(at least Id probably cry if that wasn't the case) but even that can be a win scenario depending on how they want to execute the Hi Gage, thank you for your reply. What you are missing is that by disabling kernel module loading you are applying a defense-in-depth strategy to prevent a *vulnerable* module from automatically loading in the first place resulting in root compromise. I believe you may not be aware that some modules are loaded automatically if a corresponding special device is accessed. Usually the userspace modprobe utility is executed though this can be controlled by the value of /proc/sys/kernel/modprobe Preventing module loading has historically be a valuable way to prevent privilege escalation or further root compromise. Such an example would be the 'ptrace' exploit, see http://www.sans.org/security-resources/malwarefaq/Ptrace.php Historically there have been various kernel modules that are vulnerable that could be loaded by userland non-root programs or access. Ubuntu likes to automatically load modules. Removing CAP_SYS_MODULE or kernel.modules_disabled=1 make good security sense. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3d43321b7015387cfebbe26436d0e9d299162ea1 and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=25354c4fee169710fd9da15f3bb2abaa24dcf933 and https://wiki.ubuntu.com/Security/Features#block-modules The goal here is defense in depth. Revocation of loading the kernel modules cannot be undone unless a system reboot is effected which should be highly suspicious. The goal isn't about protecting ones boxens from a theoretical boogie-man it is to leverage all available and sane methods for properly securing ones box. I see no point to to use these options. Thanks, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
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 likely. There are a plethora of scanners out there which look for PHPMyAdmin specifically and add to the Internet noise-floor. You are taking the correct steps with the egress firewall policy. Forward-going, I think it may be valuable to consider: 1) Leveraging AppArmor and creating an enforcing profile for Apache; one that controls by extension or path, what the HTTPd can write to or access. Be strict but sane. 2) Consider chrooting Apache via the 'chroot' directive for Apache (no more mod_chroot required). 3) Consider a strict ingress and egress firewall which would have prevent the egress connection to the IRCd. 4) Remain up to date; perhaps cron 'apt-get clean all; apt-get update; apt-get -t lucid-security -y dist-upgrade' (I believe the security channel is correct) 5) Consider sane php.ini values and leverage Suhosin (plugin) as well (http://www.hardened-php.net/suhosin/index.html); disallow url_fopen and url_include. Disallow the exec(), system(), passthru(), etc commands if possible. url_fopen() will thwart RFI. LFI should be thwarted by a sane AppArmor profile. 6) Restrict access to PHPMyAdmin based on authentication or remove it's access entirely. 7) Consider leveraging something like Fail2ban against Apache's error and access logs looking for excessive high-frequency HTTP 404, 403, or 500 errors as these are indicative of scanning. This is a great tool to stop Web-app scanning. 8) As you've already done with SSH, move it from TCP 22, PermitRootLogin no, and disable password authentication using key-based authentication. 9) Using OSSEC-HIDS (http://www.ossec.net/) with inotify() to watch changes to your system and Apache directories including those that are HTTP writable. 10) Mount /tmp noexec,nosuid,nodev as others have recommended. 11) Optionally use mod_security with a tuned ruleset or another WAF. I find #7 to be extremely helpful. Feel free to hit me up for additional clarification if needed. I wish you the best, remember that defense-in-depth is the best approach here. This is a good list-discussion as it is likely to yield many valuable ways to correctly secure web applications. Potentially any one of the suggestiosn in #1, #2, #3, #4, #5, #6, #7, and #10 would have saved your box. I hope this helped, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
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 believe there is some truth in what you are saying here, I
respectfully disagree in that this tends to be a run-of-the-mill IRC bot as
evidenced by the Undernet advisory. This looks like a skiddie-de-jour attack
against PHPMyAdmin and nothing to be concerned with regarding cloning disk
images and full forensics. I do respect your input and thoughts though for a
more targeted attack; not an IRC bot in /tmp.
That being said, I strongly believe in preserving bash_history as well as vital
log data. It's best/wise to ship this off to a separate Syslog server. If
you're paranoid turn up stunnel between the devices. For example and as
evidenced by many of the documented attacks here purging of bash_history is
common ala 'history -c' after fun. To thwart this I like the idea of logging
to syslog often, ensure permissions are strict for the syslog messages, and
shipping the syslog data off to a separate box. I like to:
1) Generate an E-Mail alert when someone logs in, by adjusting /etc/bash.bashrc
(or similar based on distribution) to:
#Email alert for login
echo -e Subject: Login from $(/usr/bin/whoami) on $(/bin/hostname) at
$(/bin/date)\n\n$(/usr/bin/last -ian 10)\n|/usr/sbin/sendmail
recipi...@example.com
2) Preserve, via Syslog, commands executed at the prompt, by adjusting
/etc/profile. Adjust /etc/syslog.conf or /etc/rsyslog.conf to forward these
syslog messages off-box to another asset. If you're paranoid use stunnel.
export PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND ; }'echo $$ $USER
$(history 1)|/usr/bin/logger -p user.alert -t bash_history'
readonly PROMPT_COMMAND
3) Preserve bash_history by adjusting /etc/profile:
#Secure the Bash History
export HISTSIZE=1500
export HISTCONTROL=''
export HISTIGNORE=''
export HISTTIMEFORMAT='%F %T '
readonly HISTFILE
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCONTROL
readonly HISTIGNORE
readonly HISTTIMEFORMAT
4) Optionally use chattr to set ~/.bash_history to append-only:
#Secure .bash_history (poke fun of the while subshell if you wish)
/usr/bin/find / -maxdepth 3|/bin/grep -i bash_history|while read line; do
/usr/bin/chattr +a $line; done
5) Use of an IP Recorder, something like daemonlogger, in ring-buffer mode, as
a way to record all ingress/egress traffic using a percentage of the disk. See
http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html
I am eager to hear any additional thoughts or methods for security information
such as this.
Thanks,
John
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
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...@hotmail.com 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? James, thank you for your response. I agree with you here, I was speaking more along the lines of defense-in-depth and security generalities. In this case I believe a vulnerability in an unpatched/unprotected version of PHPMyAdmin permitted the Apache process to write to /tmp and spawn a process. 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 access/error logs should have the offending log entries and/or any output from the system()/exec() etc PHP functions. Lucio -- what user was the IRC bot running under? It's evident that 10.04.1 LTS is certainly out of date and there are a multitude of vulnerabilities that could be leverage for privilege escalation. Lucio, I would also recommend subscribing to the Ubuntu Security-Announce mailing lists which issue the USNs so you are aware of which packages have been patched and those which require a reboot to effect the changes, such as Kernel update. Thanks again for the dialog Tim and James, this exchange is very beneficial and appreciated. James you are correct regarding the shell; I would assume /bin/sh would be pointed to /bin/dash or /bin/bash on a Ubuntu system. I would assume the user's login shell would be /bin/bash. Again, these are all assumptions made on my part and can certainly be incorrect, however, I would hope if someone is using KSH that they would see past the BASHisms of the previous message. Thanks, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
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 which leverages the access previously gained. On the other hand, conducting an investigation to the point where you are reasonably sure an attacker can't continue to leverage that access costs a lot of time and money. I'm conflicted here, though I do agree with what you say. A simple attack lacking any sophistication whose goal is simply to drop an IRC bot and nothing more may result in undue expense through effort and analysis. Conversely, assuming that former does not confirm the scope of attack or impact... I'm conflicted but I agree with your assessment. Perhaps in this situation one would be more likely to fall back on the output of the defense in depth tools previously recommended. In this case they are not available so perhaps caution is wise as you have suggested. I think it reasonable to assume a documented and vulnerable out of date world-accessible version of PHPMyAdmin is likely the initial attack vector. The Apache/PHP logs should prove this to be the case, so rebuilding a box and disabling PHPMyAdmin may be a reasonable response to this incident without the need for forensic analysis... depending on the organization. If this box is a singular VPS I think it reasonable, if it's a part of a larger system which could be leveraged as a launching platform to attack other LAN or organizational-owned boxes then by all means a comprehensive analysis should be undertaken. Tim thanks for your thoughts and reply. Thanks, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] one of my servers has been compromized
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 learning from it. Perhaps one day I will start a blog and it may be a house along the road where I can share what I have learned. Thanks, John ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache 2.2.17 exploit?
http://packetstormsecurity.org/files/25728/w000t-shell.c.html It's a trojan, based on the w00t-shell.c code; the shell code adds a passwordless root account under the name w000t. Date: Mon, 3 Oct 2011 15:31:29 +0100 From: d.martyn.fulldisclos...@gmail.com To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Apache 2.2.17 exploit? I regularly trawl Pastebin.com to find code - often idiots leave some 0day and similar there and it is nice to find. Well, seeing as I have no test boxes at the moment, can someone check this code in a VM? I am not sure if it is legit or not. http://pastebin.com/ygByEV2e Thanks :) ~Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux kernel 2011 local root does it exist
Apologies in advance for thread-jacking but does someone happen to have a spare GNU/Linux CD-Key for sale? I'm having some issues with Linux Genuine Advantage for Linux Kernel 2011 Home Edition. I did recently change my motherboard and evidently it was an OEM license and LGA went crazy. Please do not recommend a Linux key-gen, I do not pirate GNU/Linux! I've seen many of these Linux torrents floating around and the last thing I want is to be sued over downloading Linux! Amazingly many of them are right out there in the open too! Kind Regards, John Jacobs ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Insect Pro - Looking for partners
Insect Pro is actively looking for partners to expand the frontiers of Insect Pro and grow our penetration testing tool at a competitive level worldwide. Dear Sir, I would very much like to be a partner and I think this is an exceptional product that not only offers more than what is already available in the open source community but it is also very well marketed. Would you be willing to wave the initial Donations Appreciated hurdle to becoming a partner? Also, some time ago I ordered your product (I think back when it was free but it wasn't, or something, yawn) and I never did get a nifty box like the one depicted in your image. Kind Regards, John I see what you did there Jacobs ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux kernel exploit
I've included here a proof-of-concept local privilege escalation exploit for Linux. Please read the header for an explanation of what's going on. Without further ado, I present full-nelson.c: Hello Dan, is this exploitation not mitigated by best practice defense-in-depth strategies such as preventing the CAP_SYS_MODULE capability or '/sbin/sysctl -w kernel.modules_disabled=1' respectively? It seems it'd certainly stop the Econet/Acorn issue. Curious to hear your input as I fear too many rely solely on errata updates and not a good defense-in-depth approach. Happy hacking, Dan Cheers, John Jacobs ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] NIPS/NIDS prodcuts: HTML evasions
Hi Mahesh, I generally try to find the one which offers the most HTML-evasions. There's a few people who require say, 10 evasions, but those are often individuals who settle for less in life. When speaking with our vendors we always require, at a minimum, at least 11 evasions to be available. If a vendor were to offer, say 20 evasions, well they would most certainly have our business because 20 is clearly more than 11 or 10 respectively. John Jacobs Patel Sr. Security Engineer Evasion Specialist Date: Fri, 19 Nov 2010 23:20:29 +0530 From: umamahesh.venk...@gmail.com To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] NIPS/NIDS prodcuts: HTML evasions Hi, I have a query regarding HTML evasions. While buying any NIPS/NIDS product, what kind of HTML-evasions we should look from product? Mahesh. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] targetted SSH bruteforce attacks
Of course it's wise to disable password authentication and just use public key authentication. Why? Ssh is encrypted, so you're not exposing a password when you login. How does public key authentication make you more secure (in a practical sense)? Paul, it's more secure in that brute force attacks are mitigated because the private key is required by the client and the public key must appear in ~/.ssh/authorized_keys. Disabling password authentication means a weak password on an account cannot be compromised by brute force or other discovery efforts. A password on the private key provides even greater defense-in-depth security. Disable password authentication and enforce key-pair authentication and targeted brute-force attacking becomes moot very quickly. Moving SSHd from TCP 22 also keeps the script-kiddies and automated scanners away. After doing these two basic things then it's time to focus on fail2ban, denyhosts, and the other firewall integrating solutions. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Windows Help Centre Handles Malformed Escape Sequences Incorrectly
Consequently, in my humble opinion I think there should be less focus on the emotional interaction between Microsoft and Travis' findings. Of course it's easy for me to assert this; when I wake up in the morning I don't have the same challenges of wading through a soup of emotional fog and displacing the priority of actual vulnerabilities in favor of emotional interaction with Microsoft. While it's fun to be a Microsoft apologist, and even more fun to be ruled by emotion, I would be ashamed to have published what Susan did. Even more shaming is the call to arms which you so eagerly answered only to appear as foolish as Susan herself. It's hard to tell who the trolls are, perhaps Susan is indeed a troll, and decided to fork the conversation about actual vulnerabilities and security events and derail them by introducing drivel about interacting with Microsoft. I believe this may be one of the disadvantages of an unmoderated list, perhaps it encourages or enables others to treat it like a social networking site. Date: Fri, 11 Jun 2010 11:40:55 +0200 From: uuf6...@gmail.com To: jfr...@freerun.com CC: full-disclosure@lists.grok.org.uk; bugt...@securityfocus.com Subject: Re: [Full-disclosure] Microsoft Windows Help Centre Handles Malformed Escape Sequences Incorrectly In my humble opinion, he could have waited a couple more days just in case Microsoft decided to do the unprecedented. In which case, I progressive change of policies at Microsoft are better than a couple of users getting hacked from pron sites... Cheers. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Off Topic: Information Security research paper help
I'm not the original author of this message, saw it pop-up on Snort-Sigs and as a graduate student myself I figured I'd give this guy a hand to get more visibility. I'm not so sure it's a troll. YMMV. -John Message below, unaltered: Hello Snort and Emerging Threats communities, this is off-topic so I apologize in advance. I am in the midst of a graduate thesis paper hinged around the Information Security environment and the use of Apple products. My undergraduate degree was in Computer Science where I minored in Information Security (I am one of you, at least to a small degree). My graduate degree is in Psychology with a focus on how technology, particularly the security aspect of technology, affects what we do, say, and think. As such, I'm reaching out to the Information Security community for some help in this paper. Simply put I am trying to gather evidence to support two observations as well as a behavioral idiosyncrasy between a niche facet of the Information Technology field and subsequent behavioral attributes. If you would, please take the time to respond to these two questions which are not mutually dependent on each-other. 1) Do you use Apple products for your Information Security duties, either exclusively, or occasionally? 2) Have you, at any point in your professional career (professional, being the key word, please do not respond with the context being prior to obtaining an Information Security job) entertained thoughts of homosexual behavior? Feel free to respond to the list or to me directly. Thanks very much in advance to all who respond and again, I'm sorry for this off topic post but a good sampling from the Information Security industry is necessary for my results to be valid. Sincerely, Mike Ferguson ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Snort Sigs for ISC Twitter/Google Diary Annoucements
___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] ISC Twitter/Google Snort Signatures
Hello FD, first and foremost thank you for the strong effort and excellent signatures. As such, in an attempt to give back to a wonderful community, I humbly submitted the following Snort rules for inclusion into the ET signatures. A brief explanation is provided below: The first signature is designed to detect Google non-security related announcement articles on the ISC Diary; this seems to be a topic of extreme interest for some ISC Handlers despite having little to no security value. I am unsure if this is a result of Slow News Day syndrome or another behavorial oddity which manifests at ISC. This will detect on Google is slow style articles as well, however, I am sure this signature will require more tweaking as ISC encourages handing over more personal data to a 3rd party under the guise of functionality. The second signature is designed to detect Joel peddling Twitter on the isc.sans.org Diary, as again, this isn't security related. I suspect the Twitter signature may tend to fire more than the Google as Joel tends to get excited about Tweeting and Twittering and this spills over into the ISC Diary anytime he's the Handler on Duty. As always, please feel free to make changes to this signatures, especially regarding performance. I've placed these into ET POLICY but they may be more applicable in another classes, perhaps a blocking class. I thank you in advance, feel free to modify for PCRE as well. alert tcp $HOME_NET any - $EXTERNAL_NET $HTTP_PORTS (msg:ET POLICY isc.sans.org Access; flowbits:set,isc_sans; flowbits:noalert; flow:established,to_server; content:|0D 0A|Host|3A 20|isc|2E|sans|2E|org|0D 0A|; reference:url,isc.sans.org/; classtype:policy-violation; sid:2009; rev:1;) alert tcp $EXTERNAL_NET $HTTP_PORTS - $HOME_NET any (msg:ET POLICY isc.sans.org SANdlers say Google is slow; flowbits:isset,isc_sans; flow:established,from_server; content:google; nocase; content:slow; nocase; reference:url,isc.sans.org/diary.html?storyid=6388; reference:url,isc.sans.org/diary.html?storyid=5443; classtype:policy-annoyance; sid:2009; rev:1;) alert tcp $EXTERNAL_NET $HTTP_PORTS - $HOME_NET any (msg:ET POLICY isc.sans.org Joel Esler Peddling Twitter; flowbits:isset,isc_sans; flow:established,from_server; content:Joel|20|Esler; nocase; content:Twitter; nocase; reference:url,isc.sans.org/diary.html?storyid=6391; reference:url,isc.sans.org/diary.html?storyid=6388; classtype:policy-annoyance; sid:2009; rev:1;) - John Jacobs___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
