Vulnerability Development mailing list archives
Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days
From: solareclipse () SOFTHOME NET (Solar Eclipse)
Date: Mon, 17 Jan 2000 14:31:33 -0600
ICQ stealing CCs might be just FUD, but I am tempted to believe that something similar has happened or is going to happen soon. Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days Day 1. Find a victim. There are a lot of companies offering direct download of their software.Some of them have a HUGE user base. A site with shareware will be better, because more people will download the files. ICQ will be one of the best victims - they have a lot of downloads every day and their software will be downloaded mostly by clueless users. Day 2. Do some security research. Most of big software companies have fairly good protection for their development servers. But their weak point are the web servers. Often the system administrators think that isolating the web server from the rest of the internal network (aka Intranet) will be good for the overall site security. Sometimes they leave the web server less protected than the rest of their network. Breaking into the web server is much easier than breaking into the development servers. Fortunately for the hackers, everything they need is on the web server. Day 3. r00t the web server. Clean the logs, install a backdoor, have fun. Day 4. Download the latest ICQ version from the web server. You will attach your trojan code to it. Day 5. Write your trojan code and attach it to the executable ICQ file. You might want to use some InstallShield unpacker to get the ICQ.EXE file, infect it and than put it back into the packed SETUP.EXE. You don't need the source code of ICQ to put a trojan in it. There are ways to add executable code to existing binary files. Viruses have been doing this for years. Day 6. Upload the infected ICQ setup file to the server, replacing the old one. Questions to the sysadmins: How many of you are running Tripwire on your web server files? Day 7. Wait Day 8. Check your email account and see how many new CCs you've got. (I assume that you are using email for getting the CCs back to you. More advanced ways to do this exist, but I'll keep it simple and stupid) Day 9. - Day 20. Buy stuff. Day 21. Get busted and spend the rest of your life giving pleasure to big sweaty inmates. But hey, you might like it! Appendix A. Where are the CCs stored? There are 3 different approaches to getting the CCs from the user's computer. You can try scanning the whole hard drive for strings that look like credit card numbers. There is a simple algorithm for checking if a given string of digits is a credit card or not. Consult your favorite CCgen program. This way is slow and the chances of success are not very high. You can also try putting the user's network card in promiscuous mode, or capture the outgoing data from his modem. Unfortunately (or fortunately, depending on your point of view) almost everybody uses SSL nowadays and the number of unencrypted CCs floating around is not very high. The third way is to target a specific application. A good example is Microsoft Wallet. You might need to deal with the encryption of the stored CC data - it's not impossible, but quite hard. Btw, think about Internet Explorer. The vast majority of Windows users use IE for online shopping. Somewhere in MSIE there is a function that takes some parameters as its input and combines them into a URI encoded string, just like the thing that you see in your browser's location field after submitting a GET form. This function is called every time you submit a form and its parameters are the names and the values of the form input fields. A logical approach for the browser designers is to use this function for every form (both SSL and non-SSL) and to encrypt the data in the transport layer, just before passing them to the Winsock. If you know exactly where this function is located, you might be able to patch the DLL and make it pass the _unencrypted_ contents of every submitted form to you. It took me 18 hours of debugging and disassembling MSIE to find this function. Unfortunately, you will need to do the same with every version of MSIE, because the exact address of the code changes. Probably best approach is to do keyboard capture. Relatively few people use software like Microsoft Wallet. Most of the enter their CC number every time they buy something online. This is not only the most successful method, but also the simplest. Solar Eclipse solareclipse () phreedom org key ID: 4096D/3B98D2E9 (DSS) user ID: Solar Eclipse <solareclipse () phreedom org> fingerprint: E0FA 3B25 BDE5 9CC1 E67A 1E1D CEF6 9808 3B98 D2E9
Current thread:
- Re: Netdetect.exe with backdoor? (ICQ), (continued)
- Re: Netdetect.exe with backdoor? (ICQ) Brad Griffin (Jan 15)
- Re: Secure coding in C (was Re: Administrivia #4883) Iván Arce (Jan 14)
- Re: Secure coding in C (was Re: Administrivia #4883) kay (Jan 15)
- Re: Secure coding in C (was Re: Administrivia #4883) Brian Masney (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) K Martin (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Paul Cardon (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) K Martin (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Bennett Todd (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Aviram Jenik (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Craig H. Rowland (Jan 17)
- Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days Solar Eclipse (Jan 17)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days Blue Boar (Jan 17)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days kay (Jan 18)
- Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21Days Blue Boar (Jan 18)
- e-commerce site security (was: Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days) Jon Paul, Nollmann (Jan 18)
- Re: Secure coding in C (was Re: Administrivia #4883) Warner Losh (Jan 17)
- Re: Secure coding in C (was Re: Administrivia #4883) Tellier, Brock (Jan 20)
- Re: Secure coding in C (was Re: Administrivia #4883) Marco Walther (Jan 20)
- Re: Secure coding in C (was Re: Administrivia #4883) Seth R Arnold (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Blue Boar (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Mikael Olsson (Jan 21)