STICKY rules for CXS.XTRA regs.

[Sergio]

I will try first to get the domain names as this:

regall:\.akamai.net
regall:wellsfargo\.com

Or, you can go and check for this:

regall:src=\"https\:

the problem with the second option is that you can trigger false positives if any of your webpages are using as src a SSL page.

[tvcnet]

Ok, though the other reporting service used this to locate the hack:

/<script.+?src\s*=\s*['\"]?(ht|f)tp.+?>(.*?<\/script>)?/

Is that something we can rewrite for this system to catch this sort of hack?

Thanks,
Jim

[Sergio]

Ok, though the other reporting service used this to locate the hack:

/<script.+?src\s*=\s*['\"]?(ht|f)tp.+?>(.*?<\/script>)?/

Is that something we can rewrite for this system to catch this sort of hack?

Thanks,
Jim

Jim,
I think you can use that in CXS, as it is a regex expresion, so, you can try with:

regall:/<script.+?src\s*=\s*['\"]?(ht|f)tp.+?>(.*?<\/script>)?/

[tvcnet]

I tried the regex earlier as well but did not work (and no workie this morning as well).

You can test there as well but putting that iframe text in a file and running a scan on it.

Many thanks,
Jim

[Sergio]

ok, try with this:

regall:<script type=\"text\/javascript\" src=\"https\:
regall:<script type=\"text\/javascript\" src=\"ftp\:

this will work for sure.

[tvcnet]

ok, try with this:

this will work for sure.

Yes, no question that will work.
Though I'm not sure the value just yet. Pretty sure that's going to lead to a lot of false positives, but agreed not to many folks use script calls to ftp (so that might be a good one).

I recommend adding this to the regall: list as well:
regall:wellsfargo\.com
regall:bankofamerica\.com

I can't imagine too many folks are going to have links to banks, though your mileage may vary.

Thanks,
Jim

[Sergio]

Just elaborating a little bit more, you can use this rule:

regall:<script type=\"text\/javascript\" src=\"(ht|f)tp.\:

and this works checking for http, https and ftp.

----------- SCAN REPORT -----------
(/usr/sbin/cxs -mail root --exp --vir -I /etc/cxs/cxs.ignore -X /etc/cxs/cxs.xtra -o mMOLfSGchexdnwW -vo eT --sum -E


Scanning
# Regular expression match = [<script type=\"text\/javascript\" src=\"(ht|f)tp.\:]:

----------- SCAN SUMMARY -----------
Scanned directories: 0
Scanned files: 1
Ignored items: 0
Suspicious items: 1
Viruses found: 0
Data scanned: 0.00 MB
Scan time/item: 0.002 sec
Time: 0.002 sec

[tvcnet]

One of the common phishing installer scripts creates a log file named:
error_log

(and FYI purposes other filenames in this phishing installer are
login.php, regions.zip and index.htm)

In this log file the one thing I believe could be ID's as a likely hack would be this line:

[26-Feb-2010 16:12:02] PHP Notice: Undefined index: pin in /home/xxx/public_html/images/ucon/login.php on line 7

In specific, I'm referring the the section:
Undefined index: pin

What you think about the relevance of this?

I tried this but it didn't catch it:
regall:Undefined index\: pin

-Jim

[tvcnet]

One of the common phishing installer scripts creates a log file named:
error_log

(and FYI purposes other filenames in this phishing installer are
login.php, regions.zip and index.htm)

In this log file the one thing I believe could be ID's as a likely hack would be this line:

[26-Feb-2010 16:12:02] PHP Notice: Undefined index: pin in /home/xxx/public_html/images/ucon/login.php on line 7

In specific, I'm referring the the section:
Undefined index: pin

What you think about the relevance of this?

I tried this but it didn't catch it:
regall:Undefined index\: pin

-Jim

I take that back regarding the scan.
regall:Undefined index: pin
"does" work fine though only with a deep scan.

-Jim

[Sergio]

I take that back regarding the scan.
regall:Undefined index: pin
"does" work fine though only with a deep scan.

-Jim

Jim,
you are not writing your RegEx as it should, that line has to be:

regall:Undefined index\: pin

but I don't think this will work, as the error that you are referring to is a log line and is not inside any php, cgi or html file. CXS only searches for strings inside files, if you set this rule, you will have a lot of positives when your CXS checks your error_log file but not the compromised one.