Perl Tip: finding module path

I thought I'd share a little Perl Tip/Trick that saves me a lot of trouble. Say you have a perl module installed and you need to make a correction to the source code. For some reason you can't find where the module installed to though. You could spend time using 'find' searching through folders or do this:

perl -M'Data::Dumper' -M'' -e 'print Dumper(\%INC)' 

This will dump all the modules loaded out to screen for you. You can of course pipe this into grep to look for the specific module or modules you want. You will then get the path.

Observe:



c0malod@Takeshi:/Tools$ perl -M'Data::Dumper' -M'Time::HiRes' -e 'print Dumper(\%INC)'
$VAR1 = {
          'warnings/register.pm' => '/usr/share/perl/5.10/warnings/register.pm',
          'bytes.pm' => '/usr/share/perl/5.10/bytes.pm',
          'XSLoader.pm' => '/usr/lib/perl/5.10/XSLoader.pm',
          'Carp.pm' => '/usr/share/perl/5.10/Carp.pm',
          'Exporter/Heavy.pm' => '/usr/share/perl/5.10/Exporter/Heavy.pm',
          'vars.pm' => '/usr/share/perl/5.10/vars.pm',
          'strict.pm' => '/usr/share/perl/5.10/strict.pm',
          'Time/HiRes.pm' => '/usr/lib/perl/5.10/Time/HiRes.pm',
          'Exporter.pm' => '/usr/share/perl/5.10/Exporter.pm',
          'warnings.pm' => '/usr/share/perl/5.10/warnings.pm',
          'AutoLoader.pm' => '/usr/share/perl/5.10/AutoLoader.pm',
          'overload.pm' => '/usr/share/perl/5.10/overload.pm',
          'Config.pm' => '/usr/lib/perl/5.10/Config.pm',
          'DynaLoader.pm' => '/usr/lib/perl/5.10/DynaLoader.pm',
          'Data/Dumper.pm' => '/usr/local/lib/perl/5.10.1/Data/Dumper.pm'
        };

OR:

c0malod@Takeshi:/Tools$ perl -M'Data::Dumper' -M'Time::HiRes' -e 'print Dumper(\%INC)' | grep 'HiRes'

          'Time/HiRes.pm' => '/usr/lib/perl/5.10/Time/HiRes.pm',

Simple little trick, but it works wonders. Cheers.

Two must haves for PCI-DSS

For better or worse, my life revolves around PCI-DSS these days. As I move along through the realm of PCI-Compliance, I thought I would start sharing some observations. I am going to start today with two standards that should be implemented to save you a lot of time and energy. If you have these in place before you start your vulnerability scanning, you won’t have to deal with an avalanche of results from these issues.

1.       Disable SSHv1 Support. Version 1 of the SSH protocol is prone to a number of issues. For this reason, it has been essentially abandoned in favour of SSHv2. I have included instructions for disabling SSHv1 in a few of the more common setups.

a.      OpenSSH

                                                              i.      Edit the sshd_config file. This file is normally located in /etc/ssh/ .

                                                            ii.      Change the line that reads Protocol 1,2  so that it instead reads Protocol 2

                                                          iii.      Restart the SSHD Service

b.     Cisco

                                                              i.      Enter the command ip ssh version 2

                                                            ii.      This will enable SSH v2 and disable SSH v1 when SSH is already configured.

c.      F5 Big-IP 4.x

                                                              i.      Log in to the BIG-IP command line.

                                                            ii.      Change directories to the /config/ssh directory by typing the following command:

                                                          iii.      cd /config/ssh

                                                           iv.      Use a text editor to edit the sshd_config file.

                                                             v.      Edit the Protocol entry used to configure the SSH versions supported by sshd daemon by replacing #Protocol 2,1with Protocol 2.

                                                           vi.      Save the sshd_config file.

                                                         vii.      Restart sshd by typing the following command:

                                                       viii.      bigstart restart sshd

2.       Enforce Strong SSL Encryption. There is a little more to this step than the previous one. Enforcing strong Cryptographic standards in general is extremely important. Right now we’re just going to talk about how to enforce proper usage of SSL on IIS and apache web servers.

a.      Apache 2.x

                                                              i.      Disable SSL 2.0 support

                                                            ii.      Disable weak ciphers

                                                          iii.      Disable MD5 Hashing for MAC

                                                           iv.      Disable Null Authentication

                                                             v.      To accomplish this include the following lines in the httpd.conf file:

·   SSLProtocol –ALL +SSLv3 +TLSv1

·   SSLCipherSuite  ALL:!aNULL:!ADH:!eNULL:!LOW:!MD5:!EXP:RC4+RSA:+HIGH:+MEDIUM

b.     Windows/IIS

                                                              i.      Enforce the use of SSL 3.0 and TLS by disabling support for PCT 1.0 and SSL 2.0

1.       Find HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\PCT 1.0\Server in the registry

2.       Add a new DWORD called ‘Enabled’ and set this to 0x00000000

3.       Find HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\SSL 2.0\Server

4.       Add a new DWORD called ‘Enabled’ and set this to 0x00000000

                                                            ii.      Disable all weak(less than 128-bit) ciphers

1.     Add a DWORD value called “Enabled”, set to 0x000000 to the following keys:

2.     SCHANNEL\Ciphers\RC4 128/128

3.     SCHANNEL\Ciphers\RC2 128/128

4.     SCHANNEL\Ciphers\RC4 64/128

5.     SCHANNEL\Ciphers\RC4 56/128

6.     SCHANNEL\Ciphers\RC2 56/128

7.     SCHANNEL\Ciphers\RC4 40/128

8.     SCHANNEL\Ciphers\RC2 40/128

9.     SCHANNEL\Ciphers\NULL

                                        iii.    Add a DWORD value called “Enabled”, set to 0xffffffff to the following keys:

1.     SCHANNEL\Ciphers\DES 56/56

2.     SCHANNEL\Ciphers\Triple DES 168/168

3.     SCHANNEL\KeyExchangeAlgorithms\PKCS

                                        iv.    Enforce the use of SHA hashes instead of MD5

1.       Add a DWORD value called “Enabled”, set to 0x000000, to SCHANNEL\Hashes\MD5

2.       Add a DWORD value called “Enabled”, set to 0xffffffff, to SCHANNEL\Hashes\SHA

                                                             v.      A reboot of the Machine is now required for the changes to take effect.

These two little things can save you a huge amount of work if you implement them.  When you go to run a PCI-DSS mandated vulnerability scan, these items will trip you up if you’re not careful. Get them implemented early; have them set as a standard, and save yourself a lot of headache.

Shameless Self Promotion

A little bit of shameless self-promotion. The good folks over at TechJournal South saw fit to publish an article by yours truly. The article is a counter-point to some of the nonsense being talked about bug bounties. Check out the first part of it here. Stay tuned for part two next week. Special thanks to the good people at Tech Journal South for giving me this opportunity. I ope to get a chance to work with them again in the future.

Security Researchers: Heroes or Vigilantes?

This is a touchy subject, especially for me. It is, however, one that I feel needs to be discussed. Michal Zalewski just put out an amazing announcement this weekend. He has created a new DOM fuzzer for testing Web Browsers, and has unsurprisingly turned up some interesting results. My first reaction to this is of course "Zalewski is the man!". I think this for a couple of reasons. Firstly, for creating this fuzzer. Secondly for tracking the flaws through the complex space of web browser. And finally for releasing the tool for the rest of us wannabes to get our grubby little hands on.

It has taken very little time for the criticism to start trolling...*ahem* rolling in. I want to take a moment to discuss this article before we move on. The authour posits that it is 'suspicious' that the posting mentions webkit browsers without explicitly stating that this includes Safari and Chrome. The implication is that their is some impropriety on the part of google, trying to downplay it's own weakness. Let's take an alternative view for a second though. 

Browser	Rendering Engine
Chrome	Webkit
Safari	Webkit
Internet Explorer	Trident
Firefox	Gecko
Opera	Presto

So what we see here, is a breakdown of the popular browsers and the rendering engines used. Internet Explorer, Firefox, and Opera each use their own rendering engines. IE's Trident and Opera's Presto are proprietary systems, while Gecko is open source but is maintained by Mozilla.

So why is it fairly honest to say Webkit instead of Safari and Chrome? Chances are that the bug actually resides in the Webkit engine and is thus the responsibility of the Webkit project team to correct. To claim the bug as being a fault of either the Safari or Chrome development teams, in this scenario would be actually less honest and unfair to those development teams. furthermore, msot people who are fans of Safari or Chrome already know that Webkit means their browser of choice. By the reverse of this it does not, however, make sense to specifically call out the other browsers by their rendering engines. Most people would have no idea what you mean if you told them there was a problem with the Trident Rendering Engine. Seeing as how it falls under the purview of the same company, it also does not accomplish anything to make such a distinction. So there is nothing underhanded about Mr. Zalewski saying Webkit instead of Chrome, he's just being factual.

Where i am really waiting for the other shoe to drop, is from the Microsoft side of things. Microsoft was apparently advised of the issue 6 months ago, and did no follow-up. Zalewski then pinged them again in December, at which point they confirmed the vuln, and asked that he postpone release of the tool indefinitely. Zalewski refused since they failed to provide any good reason as to why they ignored the bug for 6 months. This all comes on the heels of Tavis Ormandy's HCP vuln fiasco.  If you're not aware of the PR shit storm that resulted from that, go do some quick Google searches and you'll dig up plenty of vitriol and lots of opinions. 

Here's where things get a little fuzzy. Zalewski and Ormandy both refused Microsoft's requests for non-dislosure. Zalewski has not fully disclosed the details of the vuln yet, but has released the tool, so it's probably only a matter of time. I will be interested to see if the same furor starts up again, or if we've gotten over it. The interesting bit comes from the sense of almost vigilantism in this sector. Note that in both of these cases the involved researches released it on their own personal space and time. They are not acting, as far as I can tell, in an official capacity for google in these matters. They are however, making decisions on what to do with tis information, and that gives them a power separate from the entities to whom it most directly applies. 

Some people will make the case that this is not a good thing. That security researchers need to be reeled in a bit. Of course, Tavis Ormandy and Michal Zalewski are heroes to me, so i am very biased against this argument. I have to wonder, in fairness, does this argument have some merit? Do Security Researchers have more of an obligation to protect those we seek to help? Or is our obligation, in fact, to truth and the freedom of information? It is a perilous line between, I suspect. we must maintain some degree of professionalism and integrity, otherwise these companies cannot trust us or rely upon us. How do we define the lines of that trust, where do we determine where the trust is being violated by the other side, and what is the appropriate recourse for breaches of this trust? these are probably some of the hardest questions to answer in the information Security field right now.

In the meantime, I continue with my assertion that Tavis Ormandy and Michal Zalewski are heroes, and deserving of my respect and admiration. Maybe that's a self-serving viewpoint. I don't have any firm answers.