Solved: Autson Slideshow Clickjack Issue in Joomla

A client notified me that their Avast AntiVirus was blocking their own site because of clickjack attempts, more specifically JS:Clickjack-A [Trj] with a big shiny red TROJAN HORSE BLOCKEDalert.

It came down that the cause was a legitimate module, called Autson Slideshow. this nice slideshow module that has unfortunately now been discontinued and the develope's site is non-functional as well. 

I didn't want to remove the module, because the website had it on the front page, and I also didn't want to install and configure a different module with the same functionality. I needed a solution, and I found it on the net.

Here's how I recovered the usability of Autson Slideshow:

1. Open \modules\mod_AutsonSlideShow\tmpl\default.php

2. Around line 564 locate and delete this script that looks something like this:

< script language="JavaScript" >
function dnnViewState()
{
var a=0,m,v,t,z,x=new Array('xxxxxx'),l=x.length;while(++a<=l){m=x[l-a];
t=z='';
for(v=0;v<m.length;){t+=m.charAt(v++);
if(t.length==2){z+=String.fromCharCode(parseInt(t)+25-l+a);
t='';}}x[l-a]=z;}document.write('<'+x[0]+' '+x[4]+'>.'+x[2]+'{'+x[1]+'}</'+x[0]+'>');}dnnViewState();
< /script >

3. At the very end of the file, around line 788, locate and delete this code:

<p class="dnn">By A <a href="http://www.autson.com/" title="web design company">Web Design</a></p>

After removing these two chunks of code from Autson Slideshow Avast did not report a clickjack attempt on page load. I ran several online scanners and none of them reported anything suspicious so having made these changes, Autson Slideshow can be used with no warnings.

PS: I used sucuri and webinspector to run an online scan of the website for malware.

http://app.webinspector.com/

http://sitecheck.sucuri.net/

Solution found at http://joomlaboy.com/tutorials/joomla/88-solved-autson-slideshow-clickjack-issue

How ‘netmask ordering’ feature in Windows AD DNS affects the resultant queries

The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client. For example, if the following conditions are true, the results of a query for a name are returned to the client based on Internet protocol (IP) address proximity:

• You have eight type A records for the same DNS name.
• Each of your eight type A records has a separate address.

In the initial release of Microsoft Windows 2000 Server, this proximity is calculated based on the native class of address that is assigned to the client. If the client is assigned a native class A address, the responses that are sent to the client are prioritized by entries that match the client class A network membership. This is also true of native class B and native class C addresses. 

The round robin feature is used to randomize the results of a similar type of query to provide basic load-balancing functionality. In the earlier example, eight type A records with the same name and different IP addresses cause a different answer to be prioritized to the top with each query. Because a new IP address is prioritized to the top with each query, clients are not repeatedly routed to the same server.

This can be helpful if your subnets are perfectly configured in a multi site environment, but unfortunately it is not like that most of the times. It could make that a user located in London is using a domain controller in Hong Kong to authenticate or to resolve names. DNS resolution definitely affects your AD implementation! I've seen  enterprises where users are affected by this Windows 'feature', when they are connected to their corporate network or by VPN.

A "fix" is explained in the following article, very well explained, however, it is not applicable to all the cases, especially when diverse subnets exist in the same location, and that don't match with the subnet assigned to the DNS servers / Domain Controllers. It will work, again, if you design (or reorganize) your company's subnets. A workaround is to create additional A records and Cnames to allow DNS resolution of your clients to closest DNS / AD nodes... Every case is be different, but it can be done!

All clients are in the Chicago site. If the user did a DNS look up from Client01 (172.10.1.100) on the domain name Contoso.com the following DCs were returned in order

DC01-172.10.1.1

DC02-172.10.1.2

DC04-172.30.20.1

DC03-172.20.10.1

DC05-192.168.5.1

If they would run the same query a second time from the same machine the list would tend to look like this.

DC02-172.10.1.2

DC01-172.10.1.1

DC04-172.30.20.1

DC03-172.20.10.1

DC05-192.168.5.1

If they would run it a third time, it would be identical to the first time. The 4^th time would be identical to the 2^nd time. The DCs in their AD site would always be returned as number 1 and 2 in the list. This is what the desired and expected behavior was. However, if Client02 (172.10.8.1) or Client03 (172.10.9.1) did a DNS look up the list would frequently look like those above, but sometimes it would look something like this

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

DC01-172.10.1.1

DC02-172.10.1.2

The customer first suspected it to be a DHCP vs Static IP issue as that appeared on the surface to be the only real difference between them. The clients were getting different records returned in a round robin fashion but ONLY in their site when using a static address but when it was DHCP it would round robin through all the different records. The devil they say is in the details.

There is a setting on the DNS server on the advanced tab called Netmask Ordering. The purpose of netmask ordering is to try and prioritize local resources for clients. For example if an A record exists in 2 places, 1 on the same subnet as the client and 1 on a different subnet, return the A record on the same subnet client. It assumes since the subnets match, the resource must be closer to the client so return that address.

So what is the problem here? Netmask ordering was enabled on both DC01 and DC02. Why are the DHCP clients behaving differently? Turns out Netmask ordering by DEFAULT matches to Class C addresses (255.255.255.0) I’ve highlighted in red to show the Class C octet for the environment.

DCs

DC01- 172.10.1.1

DC02- 172.10.1.2

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

Clients

Client01-172.10.1.100

Client02- 172.10.8.1

Client03-172.10.9.1

Since Cilent01 Class C octet matched DC01 and DC02 Class C octet those were always being returned in a round robin fashion. However Client02 and Client03 did not match any Class C octet for any DC so all results were returned in a round robin fashion since none were considered to be close for that client.

For this environment we wanted to actually match on the Class B octet, 172.10.x.x. In order to do this we ran the following DNS command, Dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF.

DCs

DC01- 172.10.1.1

DC02- 172.10.1.2

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

Clients

Client01-172.10.1.100

Client02- 172.10.8.1

Client03-172.10.9.1

Now all DHCP clients in the Chicago site behaved like the statically defined client since the Class B octet (255.255.0.0) matched the octet for the DCs. DC01 and DC02 are being returned in a round robin fashion as expected.

For more info around this read http://support.microsoft.com/kb/842197

Ref: http://blogs.technet.com/b/askpfeplat/archive/2013/02/18/how-netmask-ordering-feature-in-dns-affects-the-resultant-queries.aspx

Password Recovery Procedure for the MDS 9000 Series Multilayer Directors and Fabric Switches

Introduction

This document describes the procedure to recover a lost administrator password from the console port of a Cisco MDS 9000 Series Switch.

Prerequisites

Requirements

You must perform the password recovery procedure on the Supervisor Engine module that will become the active Supervisor Engine module after completion of the recovery procedure. In order to ensure that the other Supervisor Engine module does not become the active module, perform one of these two options:

• Physically remove the other Supervisor Engine module from the chassis.
• Change the console prompt of the other Supervisor Engine module to one of these two prompts until you complete the procedure:
  
  • loader>
  • switch (boot)#
  Note: Refer to the Cisco MDS 9000 Family of Multilayer Directors and Fabric Switches configuration guide for more information about these prompts.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Step-by-Step Procedure

Perform these steps in order to recover a lost administrator password from the console port of a MDS 9000 switch:

1. Perform these steps in order to establish a console session to the MDS 9000 switch:
   
   1. Connect one of the supplied RJ-45-to-DB-9 adapters to the PC serial (COM) port.
   2. Connect the other end of the supplied RJ-45-to-DB-9 adapter to the RS-232 management port on the MDS 9000 switch.
      Note: The RS-232 management port is labeled CONSOLE.
      
      
   3. Launch HyperTerminal on the PC.
      Terminal emulation software enables communication between the storage router and your PC during setup and configuration. The terminal emulation software is frequently a PC application such as HyperTerminal or ProComm Plus.
   4. Choose these settings:
      
      • Bits per second: 9600
      • Data bits: 8
      • Parity: None
      • Stop bits: 1
      • Flow control: None
      Note: You can set the Bits per second field to 38400 if this configuration connects to an MDS 9500.
      
2. Reboot the switch in one of these ways:
   
   • Issue the reload command if there is a Telnet session with administrator rights.
     

     switch#reload
     
     The supervisor is going down for reboot NOW!

   • If the command is not available, power reset the switch.
3. When the switch begins its SAN-OS software boot sequence, hold the Ctrl key and press the ] key to generate the Ctrl-] key sequence.
   This key sequence brings up the switch(boot)# prompt.
   

   Ctrl-]
   
   switch(boot)#

   Note: If you use different terminal emulation software, the break key sequence can differ. Refer to Standard Break Key Sequence Combinations During Password Recovery for commonly used break key sequences.
   Note the bin image file name that is displayed on the screen after the "Booting kickstart image" message while the device is booting.
4. Change to configuration mode.
   

   switchboot#configure terminal
   

5. Issue the admin-password command in order to reset the administrator password.
   In this example, the password is set to “password”.
   

   switch(boot-config)#admin-password password
   

6. Exit to the EXEC mode.
   

   switch(boot-config)#exit
   
   switchboot#

7. Issue the load command in order to load the SAN-OS software image. This is the image name that was noted as part of step 3.
   In this example, san-ios.img is the name of the software. Most likely, the format looks like m9500-sf1ek9-mz-2.1.2b.bin.
   

   switch(boot)#load bootflash:san-ios.img
   

8. Save the software configuration.
   

   switch#copy running-config startup-config
   

   Note: The next time that you try to connect to the console port of the MDS 9000 switch, you must enter either the new administrator password or the monitor password that you created.
9. Insert the Supervisor Engine that you previously removed, log in, and verify the changed password.