Hi markooff,
Maybe you have an interesting read here, as there is PHP involved in the code injection from within:
http://blog.fortinet.com/code-injection-from-within/JQuery (
http://jquery.com/ ) is a respectable and popular JavaScript library by John Resig (who's also a Mozilla employee).
The problem is that most site embeds it in its minified version (for bandwidth reasons), which makes differential fingerprinting from malicious obfuscated code OMG :shock: quite difficult.
Furthermore jquery-1.3.2.min.js can contains recognition pattern of JS/Dldr.Agent.Agr.1 java script virus.
Index.js see: htxp://www.wolframalpha.com//common/jav ... 3.2.min.js is not something to show to the world and malcoders..
If the software code you have there is not fully updated and patched, or there is some old usable crap-code still somewhere laying around on that site, the hacker just needs a little maneuverability to perform these inline injection attacks outside HTML. You can check your whole site here:
http://www.blacklistdoctor.com/bld/diagnose.phpPossible attack scenario, not your example necessarily...
1) The attacker finds a hole in your users local PHP script
2) The inject their own PHP code from a remote file making it run as if they are uploading the page through regular FTP.
3) There are various ways you can easily collect the usernames of accounts, extremely easily performed.
4) You can start to then bruteforce attacks on passwords of user accounts
5) You can then start scouring the server for local exploits and use them to your advantage. e.g.: the script you mentioned in that include checks to see if wget, gcc and other system binaries are on the system and accessible for the attacker to use.
6) With a list of whats installed and what they can use, they can now download hacks and start trying to crack your machine and compiling code attempting to gain root, etc.
7) They can search any and all 777 permission files/directories and inject whatever they feel like. Good times for them, crappy time for the site owners and server owners to clean up the mess after the site software was compromised.
Preventing this is a combination of things that I won't go into complete details about but I'll brief over so you get the idea.
1) Lock your system binaries, like wget, gcc, and others to stop anyone from using them.
2) Secure PHP by disabling functions used such as: proc_open, exec, system, passthru, etc..
3) Make sure PHP/Apache is up to date
4) Install mod_security and have CURRENT ruleset! Mod_security through cPanel install has NO rule-set! Use a rule-set that is handed out to all clients which was tried, tested and true.
5) Have a current kernel installed, there are many exploits that still work on a lot of providers.
There are tons of measures you can do to help lock your machine, so the hacker has less room to maneuver and turn you into a victim,
polonus