avast blocking piriform forum

[JohnnyBob]

The forum.piriform.com website is back up now. I've been able to go there and login as usual, with no more avast blocks/warnings. It is still producing some errors but I believe that's faulty coding or a server error. I believe the former virus block was probably a false positive from avast, but that's just my impression. Possibly it was infected and they've fixed it already. I don't know of any way to find out except - I've finally managed to send them the info via a support ticket.

[true indian]

yep! infected..

I sent a copy of infected HTML to Avira labs and even they confirmed it:

The file 'Piriformforum_infection.html' has been determined to be 'MALWARE'. Our analysts named the threat JS/Redir.BF. The term "JS/" denotes a Java scriptvirus. Detection will be added to our virus definition file (VDF) with one of the next updates.

[essexboy]

Why the insistence that it was a coding error... Three antimalware programmes call it infected along with several URL checkers ?

[essexboy]

Oops not fully cleaned

[true indian]

Me neither...Spoke too soon..went there once got nothing from avast...second attempt and got a hit 
scanned my chrome folder and temp files and didnt find anything...it looks like it comes clean once and a hit at next atttempt!

[Gopher John]

Piriform's various programs, including CCleaner, check for program updates when run by default.  Could this somehow be leveraged to spread infections to the machines using their programs, short of the actual installer programs on Piriform's site being infected?  Right now, the discussion is only about their forum.

[true indian]

OK it looks like this:

HTML Redirector>>Redirects to Blackhole exploit!>>Infected!!

[true indian]

Looks like it was cleaned...then re-infected again and again cleaned now...Infected HTML was removed and clean one looks to be restored back again.

Scan of the new HTML: https://www.virustotal.com/file/6258da3cd6fb37ad51dab41fc576bf1ab14a66947b987b1c257a728bbf0a2726/analysis/1351871681/

[DavidR]

The forum.piriform.com website is back up now. I've been able to go there and login as usual, with no more avast blocks/warnings. It is still producing some errors but I believe that's faulty coding or a server error. I believe the former virus block was probably a false positive from avast, but that's just my impression. Possibly it was infected and they've fixed it already. I don't know of any way to find out except - I've finally managed to send them the info via a support ticket.

If you have read my post above yours do you really think this is a coding problem or a false positive, I don't. Revisit  the urlquery link given by Pondus in reply #4 and that shows what is going on quite clearly. Look at the Intrusion Detection Systems entries, expand the two GET entries. At the very least it looks very strange.

[polonus]

Hi GopherJohn,

I do not think it is malcious intent on their side, but they "blundered" by not defining absolute path - file does not exist, and they have to go over their file logs.

"Virtual server path" from "filesystem path" is not distinguised, and then we get a PHP error: Fatal error</b>: require_once() [<a href='function.require'>functi...
but that is neither Apache nor PHP related. See whether this is just a programming error or malware related as described here: http://labs.sucuri.net/db/malware/php-error-fatal-error.
They have to "run php -f /common/configs/config_templates.inc.php"there as a validity check for the PGP syntax.
People (webmasters, hoster admins, etc.) keep websites up, not very savvy at serversecurity (hardening) or securing PHP etc.
@true indian, and then they were infected...

Not actually with Blackhole  because that was when the site had another IP 46.166.147.133 and is now at 50.28.75.78
Check the ip against the IDS alert IP...
@DavidR ->  check this further down on the urlquery result page....
The PHP hick-up error  could be due to the former iFrame injection,  but I do not have their logs, so that is an assumption...
At least I think the site is still vulnerable...but they are not alone there 

polonus

[JohnnyBob]

I don't know. It's working OK for me now which is all I care about. I posted in their forum and referenced this thread, so at least they're notified now.

In general I assume all avast blocks are false positives, which is usually the case in my experience. It's only a warning of a possible infection. I don't let my panties get tied up in a knot about it.

[DavidR]

@ polonus
Yes, the Russian IP to a site considered malicious by avast is basically the point I'm trying to make this really had to have started out as a genuine infection (injected iframe). So a case of avast making a good detection on a site which would otherwise have been considered safe/good.

It just proves the rule that there is no such thing as a safe site (any more) as the volume of hacked sites marches on.

Not to mention the power of the web and network shields to protect avast users and a function that many antivirus tests are incapable of testing. True life scenarios, where avast isn't reliant on the actual payload being detected by conventional on-demand scanning.

[true indian]

In general I assume all avast blocks are false positives

It is correct detection...every scanner confirms it..its not a FP... avast just saved your ass!! 

[JohnnyBob]

In general I assume all avast blocks are false positives

It is correct detection...every scanner confirms it..its not a FP... avast just saved your ass!! 

You can believe that, but I am not convinced.

[Gopher John]

Hi GopherJohn,

I do not think it is malcious intent on their side, but they "blundered" by not defining absolute path - file does not exist, and they have to go over their file logs.

"Virtual server path" from "filesystem path" is not distinguised, and then we get a PHP error: Fatal error</b>: require_once() [<a href='function.require'>functi...
but that is neither Apache nor PHP related. See whether this is just a programming error or malware related as described here: http://labs.sucuri.net/db/malware/php-error-fatal-error.
They have to "run php -f /common/configs/config_templates.inc.php"there as a validity check for the PGP syntax.
People (webmasters, hoster admins, etc.) keep websites up, not very savvy at serversecurity (hardening) or securing PHP etc.
polonus

I trust Piriform (I use several of their free programs), and my question was more about these programs phoning home to check for updates and triggering a payload from Piriform's servers somehow.  I would guess that the server that hosts the install programs is much better protected and may not be compromised.  The programs use port 80 during their update checks.