Tag Info

Hot answers tagged

11

The standard way is to put the credentials into a config file, and attempt to protect the config file from being more readable than the perl file. This offers a moderate increase in security; for example, the code may be in source control and accessible to developers, the config file wouldn't be. The code needs to be in the web server's cgi root, and ...


7

I often pass the password to the script in an environment variable that way the script need not have access to the secure location that contains the password. PASSWORD=`cat passwd_file` perl_script.pl then the script reads the password my $password = $ENV{'PASSWORD'} bonus points if the perl script drops privileges


6

Essentially it XORs two strings together and then executes the result. You can view the original code just by XORing the two strings and printing the result instead. I stripped off the ''=~('(?{'.( and ).'$/})'); bits and wrapped it in a print statement, and here's what I got: Some random malware (pastebin)


5

I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user). However as an aside, ...


4

Disabling perl is useless. The exploit that can be written in Perl can also be written in another language. Say, PHP, which you obviously aren't going to disable. If you take a system that's already very secure (as in: vulnerabilities are rare and tend to affect only a small part of the system with no direct way of enabling the execution of arbitrary code), ...


4

There are many ways in which a session management mechanism can fail and this could lead to severe security risks. As a good practice you should: Use HTTPS, so that the information in the cookies could not be intercepted in transit. Set the secure flag for the cookies, so that they are not sent over unencrypted connections. Set the HTTPOnly flag for the ...


4

You need memory. If the server does not remember who clients are and when they were last authenticated, and instead trusts the clients for keeping track of themselves, then the clients are in position to fool the server. What you describe (saving and then resetting the cookie) is called, in all generality, a replay attack. To see things conceptually, with ...


3

This functionality already exists in Nmap, in the pjl-ready-message NSE script. Here's an example usage: nmap -p 9100 --script pjl-ready-message --script-args pjl_ready_message="your message here" 192.0.2.0/24 The script already checks for a real PJL service before sending the command, so you probably don't have to check for OS fingerprint results.


3

As others have already said, put the credentials in a separate file which the script will load. Risks of having the password in the script include its being exposed to shoulder surfing, its being committed in revision control systems or configuration management systems and distributed far beyond what it should be, accidentally copying to another location ...


3

CERT has create a CERT Perl Secure Coding Standard and there's been discussion of having Perl::Critic have a set of policies that match their standard. As far as I know, nothing's been done yet. Here's the start of the discussion on the Perl::Critic dev mailing list.


2

Hmm, I'm going to have a stab at this. I'll probably fail, but here goes! First line is just the shebang for convinience of execution and to set warning mode. Not sure why warnings would be enabled for a script like this, but it's here. #!/usr/bin/perl -w The next line I've broken down. The first bit: '' =~ It's asking whether the next bit of code ...


2

Try "Perl::Critic". I haven't used it yet but i came across the answer of a similar question in the below link: http://stackoverflow.com/questions/1149447/perl-code-security-scanner-other-than-rats-must-be-static link to the Perl::Critic details: http://search.cpan.org/~thaljef/Perl-Critic-1.118/lib/Perl/Critic.pm


2

The attack you are experiencing is called a Remote File Inclusion (RFI) technique. It's basically the outcome of a vulnerable web application which is being taken advantage of to upload malicious code to spawn a remote shell. You do not need to specifically disable Perl. You can start identifying the vulnerable application like for example phpBB that the ...


2

The consensus seems to be: The password should be in a separate file, not part of version control, and protected with permissions more restrictive than that of the script. Encrypting the stored password is a waste of time since the script needs to be able to decrypt the password anyway. But I'm thinking of adding a third control on top of those: Time Based ...


2

Can he point out the section in the PCI DSS Requirements an Security Assessment Procedures 2.0 which he is using to justify this? It's not quite clear if the problem is the fact that it's third party code, or that it's sourced via a collectively managed repository. If this is only a PCI-DSS audit, then argue your case: PA-DSS does not apply to payment ...


2

Not every attack requires running Perl/Python scripts on your machine. Exploiting buffer overflows, SQL injection via a network interface and others have no requirement for Perl/Python. Using those languages can make creation and delivery of the payload much easier Yes, an attacker could install their own interpreter. Depending upon the level of compromise ...


1

In most cases the hacker has whatever scripting language he/she prefers on their own system. They use that scripting language to build their custom attacks to exploit a vulnerability in a remote exposed service. You may be under the impression that the hacker uses python/perl to install their program on a remote host. This indicates that the hacker already ...


1

This would be trivial to attack if the code actually did what you intended and it was decryptable. (It doesn't though). You have to try all 63 (length of your alphabet) different values of the hashes modulo the alphabet size and then you can decrypt any message. Essentially you shift each character by Hp+1 modulo 63, where H is the computed hash value. ...


1

He thinks that we should have someone from the outside audit all the code from CPAN we want to install. This person would need to have strong security background and deep knowledge of Perl. Unfortunately, they don't know anyone like that. Well why doesn't he think the same for the rpms? It just seems riskier to him because he feels lost there. But it's ...


1

Looks like this could be facilitated by using NSE. Take for instance the following script (called hp.nse): function portrule(host, port) if port.state == "open" then cmd = "echo " .. host.ip .. " >> targets.txt" os.execute(cmd) end end function hostrule(host) end function action() end If you run: nmap -p 9100 -n --script=./hp.nse ...


1

As mentioned in the comments, it seems that someone has been attempting to infect your server with their IRC botnet/worm. Essentially, this would be the flow of the attacker: Locate hosts to attempt a public or 0day exploit on (in this case, a few joomla exploits) Attempt to infect the hosts with their perl based script, which connects your server, to ...


1

This script begins by require './lib.pl', which will read and execute the contents of the lib.pl file, from the same directory. Without seeing the contents of this file, your question is (provably) unanswerable. The generic method for reverse engineering is: do things in due order. The script engine will read the script code top-to-bottom, left-to-right. It ...


1

Almost certainly. cpanel doesn't enforce access control and /etc/passwd is readable to everyone. /etc/shadow is the important file anyway, this contains the password hashes and is only readable by root.



Only top voted, non community-wiki answers of a minimum length are eligible