Fwd: PR06-08: BEA Plumtree portal internal hostname disclosure vulnerability
On Dec 3, 2007 4:26 PM, guiness.stout <[EMAIL PROTECTED]> wrote: > > On 1 Dec 2007 21:04:34 -, <[EMAIL PROTECTED]> wrote: > > PR06-08: BEA Plumtree portal internal hostname disclosure vulnerability > > > I have verified this as well as PR06-09 and PR06-11 in version 6.1.0.240495. > Version 5.x is also vulnerable to all three issues. =i -- And what exactly is a dream? And what exactly is a joke? - Syd Barrett
Re: Standing Up Against German Laws - Project HayNeedle
Hi Raju, On Nov 14, 2007 3:20 AM, Raj Mathur <[EMAIL PROTECTED]> wrote: > The mail addresses can only be stored if the server through which the > mail is relayed (or on which it originates) falls under the law. I'd > presume that's not a significant percentage of all mails sent out from > any country. > (a) (as you say) they can of course be trivially extracted from the traffic flow at the provider level. cf the current EFF / NSA / San Francisco case - that (as I understand it) is probably in breach of the US Constitution, yet it happened/is happening. The German law, and similar laws in the UK and other countries, implicitly (at least) enables such tactics; (b) most mail users use mail servers at their employers or their local ISP (ISPs with retail presence in multiple territories will of course have mail servers in situated locally); (c) the balance, excluding those weirdos running their own personal MTA / MSAs, will be using webmail services like Hotmail and Gmail. Tracerouting from the machine I'm typing this on (in the UK) shows a route through my ISP, to LINX (the London IX), and then straight into Google space. The RTT all the way to the final hop is in the 30ms range: [...] 8 209.85.248.80 (209.85.248.80) 25.302 ms 24.348 ms 25.605 ms MPLS Label 548800 TTL=1 9 209.85.248.79 (209.85.248.79) 27.972 ms 36.281 ms 26.562 ms 10 72.14.233.77 (72.14.233.77) 28.266 ms 29.057 ms 27.273 ms 11 66.249.94.146 (66.249.94.146) 29.517 ms 30.668 ms 30.179 ms 12 ik-in-f19.google.com (66.249.91.19) 28.092 ms 27.926 ms 28.564 ms ...which strongly suggests to me that the front-end Gmail webserver my "mail" hits is probably pretty close to me. It's certainly not on the other side of the Atlantic. There's quite a lot of cooperation between EU member states, would a "UKUSA"-type arrangement in the EU be very surprising? =i On Nov 14, 2007 3:20 AM, Raj Mathur <[EMAIL PROTECTED]> wrote: > On Tuesday 13 November 2007 15:29, Florian Echtler wrote: > > [snip] > > As a native German speaker, allow me to clarify: with respect to IP > > communication, the law mandates saving the following information for > > 6 months: > > > > - which customer was assigned which IP for what timespan > > - sender mail address, receiver mail address and sender IP for each > > mail - in case of VOIP: caller and callee phone number and IP address > > The mail addresses can only be stored if the server through which the > mail is relayed (or on which it originates) falls under the law. I'd > presume that's not a significant percentage of all mails sent out from > any country. > > Of course, it's also possible to track (snoop) all SMTP traffic on the > network, but that's totally different from just keeping mail and AAA > server logs and from my understanding that's not what this law > mandates. > > Regards, > > -- Raju > -- > Raj Mathur[EMAIL PROTECTED] http://kandalaya.org/ > Freedom in Technology & Software || February 2008 || http://freed.in/ >GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F > PsyTrance & Chill: http://schizoid.in/ || It is the mind that moves > -- And what exactly is a dream? And what exactly is a joke? - Syd Barrett
Re: Defeating Citibank Virtual Keyboard protection using screenshot method
Omar A. Herrera wrote: Rogier Mulhuijzen wrote: I'm surprised that banks use such simple things as passwords. Banks here in the Netherlands use things like one-time PINs, and challenge/response stuff that uses your chipped bank card. Seems a little safer to me. [...] Nick Fitgerald wrote: Sure, they're a lot more expensive and a lot more "high-tech" but unless they are doing end-to-end client and server authentication and strong crypto _AND_ have their own input and output devices that cannot be interfaced from the host OS _AND_ are required for verifying (virtually) every step of every transaction (in other words -- if you have any of the real-world implementations of banking OTP cards used anywhere in the world, the answer is "no"), they are effectively no better than the Citi OSK's as they are trivially MiTM'ed via on-client malware. This is true, and doing it right is even harder than what it seems. Providing an independent hardware security module (i.e. with its own input/output) for the client would be probably the easier part if we forget about the cost. Something like this? http://business.guardian.co.uk/story/0,,2077984,00.html "All the big [UK] banks [...] are to demand that online customers use "chip and pin at home" devices to identify themselves before moving money out of their accounts, in the biggest change to personal banking since chip and pin replaced signatures at the checkout. "Millions of hand-held card reading devices will be sent, free of charge, to bank customers over the next six months in the latest attempt to fight online fraud. Regular internet users will be the first to receive the devices, in which they will have to place their debit card before making any online banking transactions." I haven't looked at these in any detail but superficially they seem to meet your criteria - end-to-end crypto, bidirectional auth, etc. I'd be surprised if there were any obvious & trivial attacks against these devices such as malware MitM. Finally, systems that are only vulnerable to concurrent MitM attacks (where Dr Evil is replays the client's auth to the bank and vice versa) presumably restrict the attacker to defrauding one victim at a time, drastically reducing their takings and thus incentive, as well as the damage to bank and customer. But at the other end, within the bank, there are usually hundreds of applications that have different kinds of interfaces through which transactions flow. The risk of insider fraud within the bank's own back-office systems is much better understood, better controlled, and the threat level has presumably been fairly constant for the last 20-30 years. (The banks have had some close calls over the years eg: http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/ but that's out of scope.) OSKs, CPE chip-and-PIN readers, one-time passwords and smart tokens are all trying to mitigate the client-side risk. cheers /i -- "I guess we'll have to test what's darker than ourselves We said the truth was fixed, it's lost without a trace" - MSP
