ib.adnxs.com
 

os fedora 14, kernal 2.6.35.14-106.fc14.i686

application firefox mozilla 5.0

i have picked up some malware, ib.adnxs.com. it redirects my browser when i am on sites with lots of ad content and can make things so slow that i eventually give up. i have solved the problem by redirecting the url to local host, 127.0.0.1 in /etc/hosts. what bothers me now is how the redirection to ib.adnxs.com is accomplished. there is no entry in /etc/hosts. i can't find any suspicious processes running. any ideas?

thanks-

larry

Besides logging requests (use a local proxy?) and looking at pages source code there's a few sites you can submit addresses to to diagnose what's happening like http://google.com/safebrowsing/, http://safeweb.norton.com/, http://www.avgthreatlabs.com/sitereports/domain/, http://www.mcafee.com/threat-intelligence/ or diagnose Javascript fun at say http://urlquery.net and http://jsunpack.jeek.org. I highly doubt it's malware more likely Flash ads, I-frames, Javascript fun and other stuff like that.

*BTW Fedora is at 17 so either update or choose another distribution and keep your SW current.

Sounds like DNS poisoning.

Wipe an install a newer OS like Debian. And TURN OFF those unneeded daemons and install Shorewall! Then use DNSCrypt chained to unbound. (You must turn off DNSSEC)

In this forum providing proof would be prudent before making statements like that.
If you don't have proof then either don't post or phrase your "advice" as a question.


Even if this were about DNS poisoning what exactly would that accomplish to mitigate things?

Put your shirt back on unSpawn.

Why don't you act like a man and prove I'm wrong? Is it that you don't know what I'm talking about?

You made a statement w/o providing proof any so I asked you to support your claim. Instead what I get is a lack of respect, you trying to counter-challenge me and a completely unwarranted personal attack, the latter of which earns you this official warning:

some other ideas
 

i have some new ideas about this problem. the site that seems to be worst is the seattle post web site. perhaps they have been hacked. meanwhile i have added about thirty entries to /etc/hosts to block rogue ad and tracking urls found at seattlepi.com. i will use another computer and/or os. to see if the problem is local.

i know that fedora 14 is stone age but i am an old fart and set in my ways. once i get something working well i tend to hang on to it. also, i don't much like the latest from gnome. i probably have an old box somewhere with suse 5.5 running on two pentium 3's.

thanks for the help-

larry

Well as it happens I read the P-I every day and could help, but I'm sure not now.

update
 

seattlepi.com seems to be free of the abundant ad urls this morning. i suspect that the problem was on their end. it looks like unscrupulous characters are posting adds on websites without paying for the privilege, cyber-tresspass. someone in eastern europe probably made a few currency units, just a theory. meanwhile, i wore a blister on my thumb editing /etc/hosts.

thanks again-

larry

Ideas, nice, but saying "perhaps they have been hacked" is not. I posted resources for you to check and possibly provide feedback with (call it reciprocity) so we can avoid misinterpretation and speculation and draw a conclusion based on analysis. Since you haven't here's the result of Google safebrowsing, Jsunpack and urlquery.net.


If you use Firefox (current version: 14.0.1) then consider using the NoScript and RequestPolicy addons in addition to using a profile without Java and as little plugins as possible.


.*BSD, OpenIndiana or Linux OK, but if you mean Microsoft or Apple platforms then I'm sure there's people other than me that would be interested in any such results.


I can understand how it must be difficult to make backups and upgrade regularly but there's overarching reasons and I'm sorry to say but yours just isn't a valid one.

thank you for the feedback. i did scan seattlepi.com with the avg tool and with urlquery. google and jsunpack were unavailable. the url came thru with flying colors. on urlquery i looked only at the report that was dated yesterday. as i said earlier the problem of numerous urls attempting to load when accessing a seattlepi.com url seems to have vanished. the worst was ib.adnxs.com which would come up and time out(?) numerous times while loading at seattlepi.com url. i also checked several of the urls that i entered into /etc/hosts (redirected to 127.0.0.1) no alerts were shown but in the same column of the report was a value, IDS. i don't know what that is.

finally, i'm still puzzled. the problem could be on my computer or lan but it is odd that the bad behavior seems to have ceased without any known action by me.

i primarily use linux as an os. i use ms windows to run my big epson printer and to download audio books. although i consider the current apple os to be very good, it is not a good fit for me, so i avoid it.

and... yes, it is probably time to update my linux boxes to the latest. funny though that redhat is probably still running an older, more stable version of fedora. i do keep my packages up to date.

thanks again-

larry

That seems to be the general consensus if you google for adnxs.com nfo.


I don't know what site you refer to, maybe post an example URI, but if it's urlquery then it's about Suricata / Snort IDS results. The Emerging Threats rule set provides data on quite a few forms of tainting from what they dub "malvertisers" to RBN and Dshield-listed compromised hosts.


Sites using external advertising management services have their displayed ads rotated for them and (depending on contracts and criteria) may not even be aware they're running ad such-and-such until they visit the site themselves or visitors start complaining (or worse: stay away). It's not uncommon for advertising agencies to lapse and as a result distribute one or two bad ads. It's just that the consequences can be devastating. Likewise an advertising agency has no control (except blocking them) over those submitting ads so if one of their hosts gets compromised it takes time for anyone in the chain to respond to visitor, client, provider or carrier complaints. Back to your reply: using an IDS and a proxy (caching or not) allows you to get a grip on requests and responses. Most of the time it'll be of limited use (statistics) but if you ever need to check out past requests then at least you have a partial audit trail.


Completely different discussion but you should be aware RHEL practices backporting.

thanks-

yes, the first thing i did was google ib.adnxs.com.

you hit the nail on the head. i discovered that if i view the same content, comics or puzzles, in another newspaper, there is no problem. i will edit my home page and change certain links to another newspaper, drop seattle post intelligencer. it's a fine rag but so is the houston chronicle.

anyway, i'm going to consider this problem resolved. i do need to institute an audit trail. it would save time when problems come up in the future. maybe i could just go back to usenet.

here's part of my /etc/hosts file redirecting problem urls to localhost. most seem to display no actual content on the page that requests them leading me to wonder if someone just neglected to remove them after they became obsolete. others, like ad.doubleclick.net display content but slow things down.

127.0.0.1 rd.meebo.com
127.0.0.1 ib.adnxs.com
127.0.0.1 ad.doubleclick.net
127.0.0.1 outbrain.com
127.0.0.1 odb.outbrain.com
127.0.0.1 ads.undertone.com
127.0.0.1 p.raasnet.com
127.0.0.1 ct.buzzfeed.com
127.0.0.1 pixel.dimestore.com
127.0.0.1 a.collective-media.net
127.0.0.1 q1.checkm8.com
127.0.0.1 ad-l.media6degrees.com
127.0.0.1 vads-svx.adbrite.com
127.0.0.1 adbrite.com
127.0.0.1 adinterax.com
127.0.0.1 newsinc.com
127.0.0.1 sana.newsinc.com
127.0.0.1 a23-3-68-122.deploy.akamaitechnologies.com
127.0.0.1 quantserve.com
127.0.0.1 ad.yieldmanager.com
127.0.0.1 ads.revsci.net
127.0.0.1 rd.reebo.com
127.0.0.1 newrelic.com
127.0.0.1 beacon-1.newrelic.com
127.0.0.1 beacon.jumptime.com
127.0.0.1 plusone.google.com
127.0.0.1 tag.beanstalk.com
127.0.0.1 c10014.ic-live.com

don't confuse a problem url with a problem service. the entry there for akamai is slightly dubious I'd say. If you start binning random akamai addresses (of which there are SO SO SO many) you could easily find yourself being unable pull other very legit content on other sites that use their CDN.

chris-

thanks for the heads-up. i commented the cited line in /etc/hosts, did the same for yieldmanager and doubleclick, feeling they might be worthy of trust.

thanks again-

larry