Re: [Full-disclosure] [DCC SPAM] 0trace - traceroute on established connections
Michal Zalewski wrote:
> I'd like to announce the availability of a free security reconnaissance /
> firewall bypassing tool called 0trace. This tool enables the user to
> perform hop enumeration ("traceroute") within an established TCP
> connection, such as a HTTP or SMTP session. This is opposed to sending
> stray packets, as traceroute-type tools usually do.
>
> The important benefit of using an established connection and matching TCP
> packets to send a TTL-based probe is that such traffic is happily allowed
> through by many stateful firewalls and other defenses without further
> inspection (since it is related to an entry in the connection table).
>
> I'm not aware of any public implementations of this technique, even though
> the concept itself is making rounds since 2000 or so; because of this, I
> thought it might be a good idea to give it a try.
>
I believe that paketto keiretsu package (Dan Kaminsky) performs this
technique - but we could use more tools and more improvements on the matter!
> [ Of course, I might be wrong, but Google seems to agree with my
> assessment. A related use of this idea is 'firewalk' by Schiffman and
> Goldsmith, a tool to probe firewall ACLs; another utility called
> 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since
> the tool does not ride an existing connection, it is less likely to
> succeed (sometimes a handshake must be completed with the NAT device
> before any traffic is forwarded). ]
>
> A good example of the difference is www.ebay.com (66.135.192.124) - a
> regular UDP/ICMP traceroute and tcptraceroute both end like this:
>
> 14 as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) ...
> 15 ae-12-53.car2.SanJose1.Level3.net (4.68.123.80) ...
> 16 * * *
> 17 * * *
> 18 * * *
>
> Let's do the same using 0trace: we first manually telnet to 66.135.192.124
> to port 80, then execute: './0trace.sh eth0 66.135.192.124', and finally
> enter 'GET / HTTP/1.0' (followed by a single, not two newlines) to solicit
> some client-server traffic but keep the session alive for the couple of
> seconds 0trace needs to complete the probe.
>
> The output is as follows:
>
> 10 80.91.249.14
> 11 213.248.65.210
> 12 213.248.83.66
> 13 4.68.110.81
> 14 4.68.97.33
> 15 64.159.1.130
> 16 4.68.123.48
> 17 166.90.140.134 <---
> 18 10.6.1.166 <--- new data
> 19 10.6.1.70 <---
> Target reached.
>
> The last three lines reveal firewalled infrastructure, including private
> addresses used on the inside of the company. This is obviously an
> important piece of information as far as penetration testing is concerned.
>
> Of course, 0trace won't work everywhere and all the time. The tool will
> not produce interesting results in the following situations:
>
> - Target's firewall drops all outgoing ICMP messages,
>
> - Target's firewall does TTL or full-packet rewriting,
>
> - There's an application layer proxy / load balancer in the way
> (Akamai, in-house LBs, etc),
>
> - There's no notable layer 3 infrastructure behind the firewall.
>
> The tool also has a fairly distinctive TCP signature, and as such, it can
> be detected by IDS/IPS systems.
>
> Enough chatter - the tool is available here (Linux version):
>
> http://lcamtuf.coredump.cx/soft/0trace.tgz
>
> Note: this is a 30-minute hack that involves C code coupled with a cheesy
> shellscript. It may not work on non-Linux systems, and may fail on some
> Linuxes, too. It could be improved in a number of ways - so if you like
> it, rewrite it.
>
> Many thanks for Robert Swiecki (www.swiecki.net) for forcing me to
> finally give this idea some thought and develop this piece.
>
> Cheers,
> /mz
>
>
___
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] Re: [General-discussion] Graph analysis of stolen credit cards
James Eaton-Lee wrote: > On Fri, 2006-05-26 at 12:49 +0100, James Eaton-Lee wrote: > >> On Fri, 2006-05-26 at 10:22 +0100, Justin Mason wrote: >> >>> (volume of accounts in thousands). However that's from 7 years >>> ago :( >>> >>> There may be more recent figures but a quick google can't find 'em. >>> >> Wikipedia has some good ones on the 'Bank' page: >> > > And the link, since I'm evidently twitchy about hitting 'send' today.. > > http://en.wikipedia.org/wiki/Bank#Bank_Size_Information > > I'm actually interested as to the source of the original data - since > these are cards stolen "by one carding forum", how representative are > they of card theft globally.. > > What we're seeing in malware is scary for sure, we've uncovered over 2 million cards with the trojan data we monitor in the last 6 months. I would say that 21,000 is a conservative and not fully discovered number by one group, but what it does tell you is the minimum amount a group may be uncovering. > - James. > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * https://slam.securescience.com/signup.cgi * ** ___ 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] Re: [apwg] Graph analysis of stolen credit cards
[EMAIL PROTECTED] wrote: > It makes me feel both happy and very uneasy when Discover Card is not on > the list. Just to clarify, when you say stolen cards, you really mean > stolen card data, correct? In addition, in your analysis of the carder > forums, can you tell if the majority of the card data is obtained by the > carders via phishing and pharming, hackings, or both? > We are getting a more determination through thorough analysis of this group, but the majority obtained is through phishing and botnets. > Thanks. > (Embedded image moved to file: pic29711.jpg) > > > > Lance James > <[EMAIL PROTECTED] > cience.net>To >"Malicious Activity Awareness & > 05/26/2006 12:56 Response Discussions" > AM<[EMAIL PROTECTED]>, >Phish-Net <[EMAIL PROTECTED]>, >Apwg <[EMAIL PROTECTED]>, >[EMAIL PROTECTED], >bugtraq@securityfocus.com, >"full-disclosure@lists.grok.org.uk" > > cc > >Subject >[apwg] Graph analysis of stolen >credit cards > > > > > > > > > > > Hi all, > > We took one sample of one carding/phishing forum that our Global > Surveillance Center was monitoring and sampled the set into a graph that > lists the top 10 banks and the losses over the last month. As you can > see, it's obvious who the top credit card companies are out there, but > at the same time, we can see an ever increasing on the top targets but > not necessarily an increase on the lower tiers over the entire three > months, but in the first two we see a significant increase in success > with stolen credit cards in general. In this case, the loss that we > captured (which probably isn't nearly the number captured by this forum) > was a little over 21,000 credit cards. > > Thought this might interest some, and if this is interesting, we are > going to be providing a graph of the losses of top targets with malware > in the upcoming weeks. > > Attached is the chart. > > -- > Best Regards, > Lance James > Secure Science Corporation > www.securescience.net > Author of 'Phishing Exposed' > http://securescience.net/home/news/phishingexposed.html > ** > * New IntelliFound Service 2 weeks free * > * Real-Time Identity Surveillance Service* > * https://slam.securescience.com/signup.cgi * > ** > > (Embedded image moved to file: pic09317.gif) > > > > > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * https://slam.securescience.com/signup.cgi * ** ___ 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] Re: [General-discussion] Graph analysis of stolen credit cards
Lance James wrote: > One thing to add: > correction 21,000 cards per 3 months. > This is one group, with 21,000 cards per month (that we know about) and > law enforcement estimates about $500.00 per card in average loss. At > that rate, in 3 months, one carding group causes $10,500,000.00 in loss. > And this carding group is at the low end of the totem poll. > > > Lance James wrote: > >> Hi all, >> >> We took one sample of one carding/phishing forum that our Global >> Surveillance Center was monitoring and sampled the set into a graph that >> lists the top 10 banks and the losses over the last month. As you can >> see, it's obvious who the top credit card companies are out there, but >> at the same time, we can see an ever increasing on the top targets but >> not necessarily an increase on the lower tiers over the entire three >> months, but in the first two we see a significant increase in success >> with stolen credit cards in general. In this case, the loss that we >> captured (which probably isn't nearly the number captured by this forum) >> was a little over 21,000 credit cards. >> >> Thought this might interest some, and if this is interesting, we are >> going to be providing a graph of the losses of top targets with malware >> in the upcoming weeks. >> >> Attached is the chart. >> >> >> >> >> >> >> >> _______ >> General-discussion mailing list >> [EMAIL PROTECTED] >> http://mal-aware.org/mailman/listinfo/general-discussion >> >> > > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * https://slam.securescience.com/signup.cgi * ** ___ 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] Re: [General-discussion] Graph analysis of stolen credit cards
One thing to add: This is one group, with 21,000 cards per month (that we know about) and law enforcement estimates about $500.00 per card in average loss. At that rate, in 3 months, one carding group causes $10,500,000.00 in loss. And this carding group is at the low end of the totem poll. Lance James wrote: > Hi all, > > We took one sample of one carding/phishing forum that our Global > Surveillance Center was monitoring and sampled the set into a graph that > lists the top 10 banks and the losses over the last month. As you can > see, it's obvious who the top credit card companies are out there, but > at the same time, we can see an ever increasing on the top targets but > not necessarily an increase on the lower tiers over the entire three > months, but in the first two we see a significant increase in success > with stolen credit cards in general. In this case, the loss that we > captured (which probably isn't nearly the number captured by this forum) > was a little over 21,000 credit cards. > > Thought this might interest some, and if this is interesting, we are > going to be providing a graph of the losses of top targets with malware > in the upcoming weeks. > > Attached is the chart. > > > > > > > > ___ > General-discussion mailing list > [EMAIL PROTECTED] > http://mal-aware.org/mailman/listinfo/general-discussion > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * https://slam.securescience.com/signup.cgi * ** ___ 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] Graph analysis of stolen credit cards
Hi all, We took one sample of one carding/phishing forum that our Global Surveillance Center was monitoring and sampled the set into a graph that lists the top 10 banks and the losses over the last month. As you can see, it's obvious who the top credit card companies are out there, but at the same time, we can see an ever increasing on the top targets but not necessarily an increase on the lower tiers over the entire three months, but in the first two we see a significant increase in success with stolen credit cards in general. In this case, the loss that we captured (which probably isn't nearly the number captured by this forum) was a little over 21,000 credit cards. Thought this might interest some, and if this is interesting, we are going to be providing a graph of the losses of top targets with malware in the upcoming weeks. Attached is the chart. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * https://slam.securescience.com/signup.cgi * ** ___ 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] Re: Fedex Kinkos Smart Card Authentication Bypass
Lance James wrote: > Eric B wrote: > >> Wait, so if I read this right, consumers with existing cards could >> dupe their legit cards for fake ones and cash in the fake ones yet >> still have credit on the legit card? >> >> So I'm assuming Fedex has no database/authentication system storing >> these serials...brilliant. >> >> > > Yup. > > According to Fedex Kinko's: > "Our analysis shows that the information in the article is inaccurate > and not based on the way the actual technology and security function. > Security is a priority to FedEx Kinko's, and we are confident in the > security of our network in preventing such illegal activity." > > Our response: > > http://ip.securescience.net/exploits/P1010029.JPG > Following up with a video for skeptics http://www.securescience.net/exploits/ssc_expresspay_vuln.wmv Thanks. > > >> Good write-up, thanks! >> >> On 2/28/06, *Lance James* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Abstract: >> - >> The ExpressPay stored-value card system used by FedEx Kinko's is >> vulnerable to attack. An attacker who gains the ability to alter the >> data stored on the card can use FedEx Kinko's services fraudulently >> and anonymously, and can even obtain cash from the store. >> >> >> Description: >> >> The FedEx Kinko's ExpressPay system, developed by enTrac Technologies >> of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory >> chip card. The data stored on this card is freely rewritable once a >> three-byte security code has been presented to the card's security >> logic. Neither this security code nor the data stored on the card is >> encrypted; anyone able to obtain the security code is free to rewrite >> the data stored on the card using an inexpensive commercially >> available smart card reader/writer. >> >> The first thirty-two bytes of the memory chip card are writable and >> subsequently permanently write-protectable (in this application, >> these >> bytes are write-protected), and contain a header which identifies the >> card as an ExpressPay stored-value card. Bytes 0x20 through 0x27 >> contain the value stored on the card, represented in IEEE 754 >> double-precision floating point format. Bytes 0x60 through 0x6A >> contain the card's eleven-digit serial number stored as unsigned >> zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the >> card was initially issued at, and the remaining seven digits are >> assigned sequentially at the moment of first issue. A timestamp >> indicating date and time of issue are located from 0x30 through 0x37, >> and is repeated from 0xC7 through 0xCE. >> >> In order to write to the card, a three-byte security code must be >> presented in a specific sequence of commands as outlined by the >> SLE4442's white paper. By soldering wires to the contact points of >> the card and then connecting those wires to an inexpensive logic >> analyzer, an attacker can sniff the three-byte code as the kiosk or a >> card terminal prepares to write data to the card. This security code >> appears to be the same across all FedEx Kinko's ExpressPay cards >> currently in circulation. >> >> Once the three-byte code is known to the attacker, the card's stored >> value and serial number can be changed to any value. The ExpressPay >> system appears to implicitly trust the value stored on the card, >> regardless of what that value actually is. The system will also >> accept cards with obviously fake serial numbers (e.g. a non-existent >> store number followed by all nines). Using these altered cards, >> xeroxes can be made from any machine with a card reader, and computers >> can be rented anonymously and indefinitely. Most disturbing, however, >> is that since stored-value cards can be cashed out by an employee at >> the register at any time, an attacker could cash out altered cards >> obtained at little or no monetary cost. If a card is cashed out, its >> serial number does not appear to be invalidated in the system. If an >> attacker were to clone a known good card and cash it out, the clone >> would still be usable. >> >> >> Tested Vendors: >> --- >> - FedEx Kinko'
Re: [Full-disclosure] Re: Fedex Kinkos Smart Card Authentication Bypass
Dude VanWinkle wrote: > On 2/28/06, Lance James <[EMAIL PROTECTED]> wrote: > >> Eric B wrote: >> >>> Wait, so if I read this right, consumers with existing cards could >>> dupe their legit cards for fake ones and cash in the fake ones yet >>> still have credit on the legit card? >>> >>> So I'm assuming Fedex has no database/authentication system storing >>> these serials...brilliant. >>> >>> >> Yup. >> >> According to Fedex Kinko's: >> "Our analysis shows that the information in the article is inaccurate >> and not based on the way the actual technology and security function. >> Security is a priority to FedEx Kinko's, and we are confident in the >> security of our network in preventing such illegal activity." >> >> Our response: >> >> http://ip.securescience.net/exploits/P1010029.JPG >> > > lol, now thats a funny picture! > > So am I to assume that normally you can go beyond 31337 on a Kinko's > card and this is a modding of the original to produce the displayed > picture? > > The max is $100.00 > -JP > > > ___ 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] Re: Fedex Kinkos Smart Card Authentication Bypass
Eric B wrote: > Wait, so if I read this right, consumers with existing cards could > dupe their legit cards for fake ones and cash in the fake ones yet > still have credit on the legit card? > > So I'm assuming Fedex has no database/authentication system storing > these serials...brilliant. > Yup. According to Fedex Kinko's: "Our analysis shows that the information in the article is inaccurate and not based on the way the actual technology and security function. Security is a priority to FedEx Kinko's, and we are confident in the security of our network in preventing such illegal activity." Our response: http://ip.securescience.net/exploits/P1010029.JPG > Good write-up, thanks! > > On 2/28/06, *Lance James* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Abstract: > - > The ExpressPay stored-value card system used by FedEx Kinko's is > vulnerable to attack. An attacker who gains the ability to alter the > data stored on the card can use FedEx Kinko's services fraudulently > and anonymously, and can even obtain cash from the store. > > > Description: > > The FedEx Kinko's ExpressPay system, developed by enTrac Technologies > of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory > chip card. The data stored on this card is freely rewritable once a > three-byte security code has been presented to the card's security > logic. Neither this security code nor the data stored on the card is > encrypted; anyone able to obtain the security code is free to rewrite > the data stored on the card using an inexpensive commercially > available smart card reader/writer. > > The first thirty-two bytes of the memory chip card are writable and > subsequently permanently write-protectable (in this application, > these > bytes are write-protected), and contain a header which identifies the > card as an ExpressPay stored-value card. Bytes 0x20 through 0x27 > contain the value stored on the card, represented in IEEE 754 > double-precision floating point format. Bytes 0x60 through 0x6A > contain the card's eleven-digit serial number stored as unsigned > zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the > card was initially issued at, and the remaining seven digits are > assigned sequentially at the moment of first issue. A timestamp > indicating date and time of issue are located from 0x30 through 0x37, > and is repeated from 0xC7 through 0xCE. > > In order to write to the card, a three-byte security code must be > presented in a specific sequence of commands as outlined by the > SLE4442's white paper. By soldering wires to the contact points of > the card and then connecting those wires to an inexpensive logic > analyzer, an attacker can sniff the three-byte code as the kiosk or a > card terminal prepares to write data to the card. This security code > appears to be the same across all FedEx Kinko's ExpressPay cards > currently in circulation. > > Once the three-byte code is known to the attacker, the card's stored > value and serial number can be changed to any value. The ExpressPay > system appears to implicitly trust the value stored on the card, > regardless of what that value actually is. The system will also > accept cards with obviously fake serial numbers (e.g. a non-existent > store number followed by all nines). Using these altered cards, > xeroxes can be made from any machine with a card reader, and computers > can be rented anonymously and indefinitely. Most disturbing, however, > is that since stored-value cards can be cashed out by an employee at > the register at any time, an attacker could cash out altered cards > obtained at little or no monetary cost. If a card is cashed out, its > serial number does not appear to be invalidated in the system. If an > attacker were to clone a known good card and cash it out, the clone > would still be usable. > > > Tested Vendors: > --- > - FedEx Kinko's > > > Suspected Vendors: > -- > - Any client of enTrac Technologies who uses the ExpressPay > stored-value card system. > - Any company which uses a stored-value card system based on the > SLE4442 > > > Vendor and Patch Information: > - > Proof-of-concept of the initial security vulnerability was > achieved on > 8 February 2006, with research into the ramifications continuing > throug
[Full-disclosure] Fedex Kinkos Smart Card Authentication Bypass
Abstract: - The ExpressPay stored-value card system used by FedEx Kinko's is vulnerable to attack. An attacker who gains the ability to alter the data stored on the card can use FedEx Kinko's services fraudulently and anonymously, and can even obtain cash from the store. Description: The FedEx Kinko's ExpressPay system, developed by enTrac Technologies of Toronto, Ontario, is based on a Siemens / Infineon SLE4442 memory chip card. The data stored on this card is freely rewritable once a three-byte security code has been presented to the card's security logic. Neither this security code nor the data stored on the card is encrypted; anyone able to obtain the security code is free to rewrite the data stored on the card using an inexpensive commercially available smart card reader/writer. The first thirty-two bytes of the memory chip card are writable and subsequently permanently write-protectable (in this application, these bytes are write-protected), and contain a header which identifies the card as an ExpressPay stored-value card. Bytes 0x20 through 0x27 contain the value stored on the card, represented in IEEE 754 double-precision floating point format. Bytes 0x60 through 0x6A contain the card's eleven-digit serial number stored as unsigned zoned-decimal ASCII; digits 0x60 through 0x63 are the store number the card was initially issued at, and the remaining seven digits are assigned sequentially at the moment of first issue. A timestamp indicating date and time of issue are located from 0x30 through 0x37, and is repeated from 0xC7 through 0xCE. In order to write to the card, a three-byte security code must be presented in a specific sequence of commands as outlined by the SLE4442's white paper. By soldering wires to the contact points of the card and then connecting those wires to an inexpensive logic analyzer, an attacker can sniff the three-byte code as the kiosk or a card terminal prepares to write data to the card. This security code appears to be the same across all FedEx Kinko's ExpressPay cards currently in circulation. Once the three-byte code is known to the attacker, the card's stored value and serial number can be changed to any value. The ExpressPay system appears to implicitly trust the value stored on the card, regardless of what that value actually is. The system will also accept cards with obviously fake serial numbers (e.g. a non-existent store number followed by all nines). Using these altered cards, xeroxes can be made from any machine with a card reader, and computers can be rented anonymously and indefinitely. Most disturbing, however, is that since stored-value cards can be cashed out by an employee at the register at any time, an attacker could cash out altered cards obtained at little or no monetary cost. If a card is cashed out, its serial number does not appear to be invalidated in the system. If an attacker were to clone a known good card and cash it out, the clone would still be usable. Tested Vendors: --- - FedEx Kinko's Suspected Vendors: -- - Any client of enTrac Technologies who uses the ExpressPay stored-value card system. - Any company which uses a stored-value card system based on the SLE4442 Vendor and Patch Information: - Proof-of-concept of the initial security vulnerability was achieved on 8 February 2006, with research into the ramifications continuing through 12 February. Copies of this report were sent to both FedEx Kinko's and enTrac Technologies on 15 February; a read receipt was returned from enTrac on 19 February, while no receipt has yet been received from FedEx Kinko's. Solution: - - Encrypt data before storing it on the SLE4442 card, or migrate to a system which uses cards which have built-in encryption functionality. - Verify that the stored value on the card does not significantly differ from a reference value stored in a database. - Do not allow the use of cards with invalid serial numbers. - Invalidate serial numbers of cards that are cashed out. Credits: Strom Carlson, Secure Science Corporation: Hardware Security Division [EMAIL PROTECTED] ___ 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] Re: First WMF mass mailer ItW (phishing Trojan) - think singularities
I don't disagree with you one bit - I was simply making a similar point, they are fly below the radar, with that intent. But there are ways to make pre-emptive signatures based on tracking certain phishing/spam/porn rings and noting their serial pattern. This is how you detect "below the radar" attacks. This isn't for prevention, but detection only. I don't agree with signatures as a reactive response to most problems, rather I believe in problem response as a whole. These class of attacks have been definitely observed since the Korgo/Padonock days and have been going nice and steady for these rings quite frequently. The time to discovery by AV vendors that we have observed has been from 2 weeks, all the way to 9 months. Low distribution, low detection and it allows for rapid deployment. And slight modifications in variants at such rapid deployment tends to cause problems for AV vendors in general. I think to sum it up, we're on the same page - the snort sigs that were avail were designed to look at trojans such as these in a general problem response by examing the way they are packed, rather than just the specific malware. -Lance James Ken Kousky wrote: > Are we missing the point. Hope this isn't too long but here goes . > > Worms and viruses spread and get found out but there's a large class of > Trojan who don't want to be found out. > > The propagation vector matters a lot if we can use it as a means of finding > malware and capturing signatures. Worms, Spam and viruses that have broad > propagation scheme get found out pretty fast - that's the good part of their > efforts to spread but not all malware wants to spread so recklessly. > > Sometimes it's more important to remain undiscovered which is more likely > the case in the world of Trojans. > > Last year IP3 focused a great deal of analysis on what we called > Singularities - non-signatured exploits due to their low volume presence. > This goes way beyond day zero since some reported Trojans hit day 1,000 > without being discovered! > > Spam, defacement or propagation proof-of-concept worms all have been > reasonably controlled because of their expansive propagation which leads to > their discovery. > > Most economic exploits including ddos zombie nets or identity theft > campaigns could easily continue to use these same kind of exploits, like WMF > and are not likely to show up unless they're reckless in distributing > phishing emails or eventually launching a worm that propagates into a > discovery zone. > > The same root problems that gave rise to WMF will persist in many > server-side applications for years to come. > > The point is that we may spend way to much time looking at the mass mailer > variants and not enough time looking at the targeted and purposeful > exploits. > > Remember, these exposures existed across our Microsoft platforms for over a > decade. The exposure didn't begin with it's public disclosure or patch > release. > > Because gaming and pornography continue to be major revenue streams for > online providers and because they get very little protection through law > enforcement, even when legal enterprises, we've allowed a very lucrative > extortion industry to thrive with individuals well paid to find these > vulnerabilities. It's hard to believe the potential disparity in good-guy vs > bad-guy spending on exploring for openings. > > We've cataloged hundreds of buffer overflow patches over the last year alone > that prove that virtually all enterprises have been widely exposed and have > little or no way of knowing if anything other than a widely propagating (and > therefore signatured) exploit has occurred. > > Signatures filters do not fix the WMF exposure but they've done a great job > stopping most of the propagations but it's not the whole story. > > -Original Message- > From: Lance James [mailto:[EMAIL PROTECTED] > Sent: Friday, February 17, 2006 2:03 PM > To: bugtraq@securityfocus.com > Cc: full-disclosure@lists.grok.org.uk > Subject: Re: First WMF mass mailer ItW (phishing Trojan) > > Gadi Evron wrote: > >> The first worm (mass mailer) to (ab)use the WMF 0day is now spreading in >> Australia. >> >> > Respectfully speaking: > > There are a few corrections to this that need to be expressed. > > The language you're using describing it as a mass-mailing worm is coming > off confusing to some. The WMF exploit is actually seeded on a website, > and the mass-mailing is used to get people to go to that site. Stating > that it's a worm is similar to saying that phishing emails and spam are > worms. I have seen some actual phishing worms, and t
[Full-disclosure] Re: First WMF mass mailer ItW (phishing Trojan)
Lance James wrote: > Gadi Evron wrote: > >> The first worm (mass mailer) to (ab)use the WMF 0day is now spreading in >> Australia. >> >> Also to quickly reply to my own post (sorry) - but a quick historical analysis of the exploit and trojan itself demonstrates this: Bulk Mailing via a mass-mailer was sent out (basically a phishing email) to lure victims to click on a link with: http://[censored]/xpl.wmf This will then make a request to http://[censored]/1.exe which is downloader packed with FSG. Bleeding Snort sigs would detect this immediately from both the WMF and the FSG packing itself. (http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/MALWARE/MALWARE_Corpsespyware?rev=1.7&view=markup) 1.exe will then download installer.exe from the site. This file in short puts the trojan on the system as %system32%\msnscps.dll and registers it as a Browser Helper Object. (this DLL file is packed with UPX). It names it in the Add-Ins extensions as: Software Installation Snapin Extenstion (typo included) There is no sign of mass-mailing within the trojan itself, it's a standard Remote Admin Tool used to steal data. The format which is stored in %system32%/form.txt looks like this when you log into submission forms: - CompID: 8746B936FCAF484AA9D2D49B60EBD47B1B945D4B00874879853470B023A0B9C3 Ver: 2.0RC49 host: sandbox-1 if1 : 172.16.234.128 - - - Sun Feb 19 18:55:05 2006 URL: https://www.banksite.com/ Action: https://banksite.com/signon Method: post userid(text): 234234234234 password(password): 23423423423 destination(select): AccountSummary [checked] Action: /search/search.html Method: get query(text): REQ: userid=234234234234&password=23423423423&destination=AccountSummary&screenid=SIGNON --(EOF) It also has some TAN Grabbing Features, Email account theft, and so on. This data will get sent to a remote HTTP host (in this case it appears to be http://european-business-organization.com/chat.php) This is the standard ol' blended threat attacks seen by phishers since '03. They used the WMF exploit because it's available to them, but before that they have used hta, chm/adb, and other object/ActiveX exploits to get the user into downloading the payload. This information and type of attack is old school, and no mass-mailing worms or 0day WMF techniques were used. Thanks. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ > Respectfully speaking: > > There are a few corrections to this that need to be expressed. > > The language you're using describing it as a mass-mailing worm is coming > off confusing to some. The WMF exploit is actually seeded on a website, > and the mass-mailing is used to get people to go to that site. Stating > that it's a worm is similar to saying that phishing emails and spam are > worms. I have seen some actual phishing worms, and this is definitely > not it. > > A correction also needs to be made on this comment > > "Abusing websites is mostly how WMF is > exploited, but no much in the way of emails before today." > > > This is grossly incorrect - here are the dates we started seeing this > activity: > > January 3rd - WMF exploit distributing identified phishing trojan > January 9/10th - WMF exploit distributing identified phishing trojan > Jan 18th/19th - WMF exploit distributing identified phishing trojan > Jan 22nd-25th - WMF exploit distributing identified phishing trojan > Jan 24th - WMF exploit distributing identified phishing trojan > > > I can go into February but we get the point. > > This same phishing group works in regions, so it's not surprising that > they are now targeting Australia. They are also targeting Europe as well > in February. > > Summary: > WMF Mass-Mailing phishing has not been uncommon, just in small > distributions, so it may have not been seen on the radar. Since the > public discovery of the WMF exploit, there have been a few mass-mailings > taking users to a site that distributed WMF exploits to date. > > > ___ 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] Pharming breaks SSL via Trojan {Emerging Threats}
An advisory written by Secure Science was issued for a recent Pharming attack found within malware. A public version of this document is available: http://www.securescience.net/advisories/SSC_MSAT_FEB_02_2006-public.pdf External Threat Assessment Team Secure Science Corp. www.securescience.net ___ 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] Re: First WMF mass mailer ItW (phishing Trojan)
Gadi Evron wrote: > The first worm (mass mailer) to (ab)use the WMF 0day is now spreading in > Australia. > Respectfully speaking: There are a few corrections to this that need to be expressed. The language you're using describing it as a mass-mailing worm is coming off confusing to some. The WMF exploit is actually seeded on a website, and the mass-mailing is used to get people to go to that site. Stating that it's a worm is similar to saying that phishing emails and spam are worms. I have seen some actual phishing worms, and this is definitely not it. A correction also needs to be made on this comment "Abusing websites is mostly how WMF is exploited, but no much in the way of emails before today." This is grossly incorrect - here are the dates we started seeing this activity: January 3rd - WMF exploit distributing identified phishing trojan January 9/10th - WMF exploit distributing identified phishing trojan Jan 18th/19th - WMF exploit distributing identified phishing trojan Jan 22nd-25th - WMF exploit distributing identified phishing trojan Jan 24th - WMF exploit distributing identified phishing trojan I can go into February but we get the point. This same phishing group works in regions, so it's not surprising that they are now targeting Australia. They are also targeting Europe as well in February. Summary: WMF Mass-Mailing phishing has not been uncommon, just in small distributions, so it may have not been seen on the radar. Since the public discovery of the WMF exploit, there have been a few mass-mailings taking users to a site that distributed WMF exploits to date. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ ___ 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] Re: [security] What A Click! [Internet Explorer]
yossarian wrote: > There is an easy trick to avoid a .HTA related 'thingie' such as this > one: tell your windows to open .HTA files in notepad. It broke the > beautifull PoC I guess, had it in place as long as this particular > machine (2 years or so), it never broke anything before. Is there a method of sandboxing the .HTA files? I mean, everything web, should stay web? > > Second hint for people protecting lusers: design a nice corporate > colors standard theme and disable the standard theme. Exit this kind > of attack (since there are more ways to cover windows with malicious > lookalikes). > > regards, > > yossarian > > - Original Message - From: "mikx" <[EMAIL PROTECTED]> > To: > Cc: > Sent: Tuesday, January 24, 2006 8:06 PM > Subject: [security] What A Click! [Internet Explorer] > > >> It's now almost 18 months ago that i posted my first security >> advisory "What A Drag! -revisited-", seems to be a good time to post >> "What A Click!". >> >> Both bugs had about the same exploit potential, but i assume this one >> will have far less impact and media response (which i consider a >> great thing for various reasons). Thanks to everybody who researched, >> worked, chatted, discussed and got drunk with me in the last months >> to make this change happen - you know who you are. >> >> __Summary >> >> Using custom Microsoft Agent characters it is possible to cover any >> kind of windows, including security or download dialogs. This is an >> expected feature of the Microsoft Agent control. To quote the product >> homepage: "Animations are drawn on top of any underlying application >> window, characters are not bounded within their own, separate window" >> (http://www.microsoft.com/msagent/prodinfo/datasheet.asp). Custom >> characters can be created with tools downloadable from that homepage. >> >> Because custom characters are fully scriptable, can have any kind of >> shape and are downloaded automaticly, this can be used as a flexible >> tool to cover and/or spoof any kind of window and lure the user to >> execute arbitrary code by performing one or two clicks (depening on >> security zone configuration and Windows version). >> >> __Proof-of-Concept >> >> http://www.mikx.de/fireclicking/ >> >> The PoC is designed for Internet Explorer 6 on Windows XP SP2 in >> Windows classic theme. By clicking on the button in the upper left >> corner you start the download of a hta file. The download dialog gets >> covered by a Microsoft Agent character which fakes a button (basicly >> a large white image with a button border in the middle). Move the >> character by dragging to see how it uses a "transparent spot" to make >> room for clicking on the underlying dialog through the button space. >> Transparent areas in characters are really "not there", meaning you >> can click through them. >> >> When you click that button you execute arbitraty code in the hta >> file, in this case you create the folder "c:\booom!". The button in >> the upper left corner is only need to get around the "drive by >> download" protection of Windows. When this protection is not in place >> (e.g. on Windows 2000) this PoC could be reduced to a single click >> interaction to execute arbitrary code. >> >> __Status >> >> The bug got fixed as part of the Microsoft Security Bulletin MS05-032 >> (yeah, last summer). >> >> The patch adds an additional security dialog before loading a custom >> agent character. Be aware that in trusted zones that dialog might not >> raise. >> >> 2004-10-04 Vendor informed >> 2004-10-06 Vendor opened case, could not repro >> 2004-10-06 Vendor got new testcase >> 2004-10-12 Vendor confirmed bug >> 2005-06-14 Vendor relased patch and advisory >> 2006-01-22 Public disclosure >> >> __Affected Software >> >> Internet Explorer on Windows 98, 98 SE, ME, XP, 2000, Server 2003 >> with different severity. See Microsoft Security Bulletin MS05-032 for >> details. >> >> __Contact >> >> Michael Krax <[EMAIL PROTECTED]> >> http://www.mikx.de/ >> >> mikx >> >> >> ___ >> Get your free port scan here: http://www.seifried.org/freescan2/ >> >> security mailing list >> [EMAIL PROTECTED] >> https://lists.seifried.org/mailman/listinfo/security > > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
