Author Topic: JS:Redirector-H [Trj] at website  (Read 36233 times)

0 Members and 1 Guest are viewing this topic.

kubecj

  • Guest
Re: JS:Redirector-H [Trj] at website
« Reply #15 on: April 29, 2009, 10:47:06 PM »
Try the simplest first.
1) Change the passwords
2) Don't store passwords in upload programs (definitely not in older versions of Total Commander)
3) Be sure your computer is not infected.

Offline DavidR

  • Avast √úberevangelist
  • Certainly Bot
  • *****
  • Posts: 89348
  • No support PMs thanks
Re: JS:Redirector-H [Trj] at website
« Reply #16 on: April 29, 2009, 10:57:08 PM »
You need to change your passwords for stronger ones for uploading or modifying pages. Speak to your Host and ensure that the PHP software is fully up to date as older versions are vulnerable to exploit. Also tell them about the hack and what they and you can do to ensure it doesn't happen again.
Windows 10 Home 64bit/ Acer Aspire F15/ Intel Core i5 7200U 2.5GHz, 8GB DDR4 memory, 256GB SSD, 1TB HDD/ avast! free 24.5.6116 (build 24.5.9153.762) UI 1.0.808/ Firefox, uBlock Origin, uMatrix/ MailWasher Pro/ Avast! Mobile Security

lackofvoice

  • Guest
Re: JS:Redirector-H [Trj] at website
« Reply #17 on: April 30, 2009, 05:21:58 PM »
Hello, this is my first post here.
I am the owner of a small website with a phpbb forum called hxxt://www.problemefiat.ro . Problem is I've been hit by this  JS:Redirector-H [trj] 3 days ago . So far I tried cleaning the php code...no result. Today I have deleted my files from the hosting and copied a back-up I have made a while back. The site stayed clean for about 16 hours and now is infected again. Does anyone know how to protect your website from these type of atacks? Or do I need to restore my back-up every day ? :(
Thanks!

Allex how did you originally go about editing you PHP? I too am having troubles and unfortunately do not have a backup to throw back up.

Allex

  • Guest
Re: JS:Redirector-H [Trj] at website
« Reply #18 on: May 05, 2009, 07:48:55 AM »
Hello lackof voice. In my opinion the files modified are only the index.php ones (all that you have) . You can edit them with wordpad or if you have Dreamweaver which is much better. I examined the fileand saw a big chunk of garbage(crypted stuff) at the begining of the file and an iframe line at the end which was directing me to another website in China. I deleted those thow parts and all seemed to be ok, for about 2 days  ::) I hope this helps.
At this time after 4 days I restored the back-up all seems fine. I also talke dto the HOSTS folks and I hope it will be just fine.
Thanks!

lackofvoice

  • Guest
Re: JS:Redirector-H [Trj] at website
« Reply #19 on: May 07, 2009, 04:15:09 PM »
Allex, i'm attempting to edit in Dreamweaver... but i do not want to screw anything up! the actual site html shows me the injected script, but the php file's a bit more cryptic. based on the pictures, what is the code i should target to delete? thanks.
SOURCE VIEWED:

PHP:

Offline jsejtko

  • Avast team
  • Full Member
  • *
  • Posts: 171
    • ALWIL Software
Re: JS:Redirector-H [Trj] at website
« Reply #20 on: May 07, 2009, 09:01:52 PM »
Allex, i'm attempting to edit in Dreamweaver... but i do not want to screw anything up! the actual site html shows me the injected script, but the php file's a bit more cryptic. based on the pictures, what is the code i should target to delete? thanks.

Hello,

Could you please send those infected php files to virus@avast.com. Its very hard to get original php source. We will analyze these samples that will cause detection on php layer of this threat. Please send those files in compressed archive using password "virus" without qoutes.

We will be grateful, thank you
« Last Edit: May 07, 2009, 09:37:07 PM by jsejtko »

Offline polonus

  • Avast √úberevangelist
  • Probably Bot
  • *****
  • Posts: 33933
  • malware fighter
Re: JS:Redirector-H [Trj] at website
« Reply #21 on: May 07, 2009, 09:50:09 PM »
Hi Allex,

Read about this malware here: http://blogs.technet.com/antimalware/
Never trust user input, used in a query, always use add-slashes at variables. In a numeric SQL field do not use slashes in a WHERE statement, else you are vulnerable and your open to SQL injection. Encrypted data from a cookie and from a URL-variable should always be add-slashed.
So the following string 'Mtp0cm91Ynk6M2U5YzliNzcxZGZkY2QyMjlhMTk0MDE1ZmViYTQ1MWM=' had been add-slashed(). The decoded base-64 string was not add-slashed as such within a script, and bingo vulnerable! Always do this for cookie, post, variable,

Was the problem here: hxtp://www.problemefiat.ro/scripts/ac_runactivecontent.js

Websites can detect if you've got Flash installed. How does that work and could it be used for both of my goals? " - it's quite a bit simple, your browser try to render some additional files, with some specific formats such as flash .swf and I the browser doesn't find installation, than will be start downloading, or you will got the option to download that program. Flash also use AC_RunActiveContent.js please take a look at this js, people usually put this on their webpages

Code: [Select]
if (AC_FL_RunContent == 0) {
alert("This page requires AC_RunActiveContent.js.");^^
} else {
AC_FL_RunContent( 'codebase','xttp://download.macromedia.com/pub/shockwave cabs/flash swflash.cab#version=8,0,0,0','width','981','height','635','id','build5','align','middle','src','build5','quality','high','bgcolor','#ffffff','name','build5','allowscriptaccess^^','sameDomain','allowfullscreen','false','pluginspage','xttp://www.macromedia.com/go/getflashplayer','movie','build5' ); //end AC code
}
vulnerable to SQL exploit

Protecting against SQL injection is easy:

    *

      Filter your data.

      This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.

    *

      Quote your data.

      If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.

    *

      Escape your data.

      Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort. But Actually the most effective way to defend yourself against SQLI is using prepared statements: http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

Addslashes() is rather dangerous because it gives a false sense of security. In facts, it can be fooled by exploiting character set mismatches between input and database, and it works (badly) with MySQL only (none of the other SQL-compliant databases use slashes to escape special characters).

If you can't use prepared statements, e.g. because you're stuck with PHP 4 and the its old mysql client API, you must escape all the data you put in your SQL statement with mysql_real_escape(), rather than addslashes()

polonus
« Last Edit: May 08, 2009, 01:04:32 AM by polonus »
Cybersecurity is more of an attitude than anything else. Avast Evangelists.

Use NoScript, a limited user account and a virtual machine and be safe(r)!

lackofvoice

  • Guest
Re: JS:Redirector-H [Trj] at website
« Reply #22 on: May 09, 2009, 06:30:28 PM »
Hi Allex,

Read about this malware here: http://blogs.technet.com/antimalware/
Never trust user input, used in a query, always use add-slashes at variables. In a numeric SQL field do not use slashes in a WHERE statement, else you are vulnerable and your open to SQL injection. Encrypted data from a cookie and from a URL-variable should always be add-slashed.
So the following string 'Mtp0cm91Ynk6M2U5YzliNzcxZGZkY2QyMjlhMTk0MDE1ZmViYTQ1MWM=' had been add-slashed(). The decoded base-64 string was not add-slashed as such within a script, and bingo vulnerable! Always do this for cookie, post, variable,

Was the problem here: hxtp://www.problemefiat.ro/scripts/ac_runactivecontent.js

Websites can detect if you've got Flash installed. How does that work and could it be used for both of my goals? " - it's quite a bit simple, your browser try to render some additional files, with some specific formats such as flash .swf and I the browser doesn't find installation, than will be start downloading, or you will got the option to download that program. Flash also use AC_RunActiveContent.js please take a look at this js, people usually put this on their webpages

Code: [Select]
if (AC_FL_RunContent == 0) {
alert("This page requires AC_RunActiveContent.js.");^^
} else {
AC_FL_RunContent( 'codebase','xttp://download.macromedia.com/pub/shockwave cabs/flash swflash.cab#version=8,0,0,0','width','981','height','635','id','build5','align','middle','src','build5','quality','high','bgcolor','#ffffff','name','build5','allowscriptaccess^^','sameDomain','allowfullscreen','false','pluginspage','xttp://www.macromedia.com/go/getflashplayer','movie','build5' ); //end AC code
}
vulnerable to SQL exploit

Protecting against SQL injection is easy:

    *

      Filter your data.

      This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.

    *

      Quote your data.

      If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.

    *

      Escape your data.

      Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort. But Actually the most effective way to defend yourself against SQLI is using prepared statements: http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

Addslashes() is rather dangerous because it gives a false sense of security. In facts, it can be fooled by exploiting character set mismatches between input and database, and it works (badly) with MySQL only (none of the other SQL-compliant databases use slashes to escape special characters).

If you can't use prepared statements, e.g. because you're stuck with PHP 4 and the its old mysql client API, you must escape all the data you put in your SQL statement with mysql_real_escape(), rather than addslashes()

polonus

HOLY! I would not mess with Polonus! Man's got it going on! Don't know what he's speaking about but, IMPRESSIVE!