What has Iran been up to lately?
Going over some data earlier today, I noted that a few days ago, we had a notable spike of port scans from Iran in our DShield database. Iran is "spiking" at times, in part because we figure only a relative number of actors are scanning from Iran. So lets see what was going on. First, a plot of the activity from Iran for February:
Click on the image for the full size. This data is fairly "rough" as it is just counting number of dropped packets. This could be one host sending the same packet over and over to the same target. (ok... about 2-3 Million times on the peak days)
Lets look at the ports affected next. Below you will see the data for February 16th:
+------+--------+ | port | count | +------+--------+ | 21 | 466735 | | 53 | 465751 | | 23 | 458511 | | 22 | 457712 | | 80 | 455077 | | 179 | 453416 | | 3389 | 5750 | | 445 | 4926 | | 4614 | 4721 | | 5900 | 356 |
This is getting a bit more interesting. the top 6 ports have almost the same number of "hits", and they are well known server ports. 179 (BGP) is in particular interesting as it is not scanned a lot and more of an "infrastructure" port. But one could expect routers to respond on 23, 22 and 80 as well. 21 and 53? Not exactly router ports.
One host that sticks out for port 179 scans that day (port 179 is easier to investigatate as there are less scans for this port then the others), is 213.217.37.102 .
Scans originating from this particular host confirm the original picture:
+------------+---------+---------+ | targetport | reports | targets | +------------+---------+---------+ | 21 | 386903 | 368 | | 22 | 379809 | 363 | | 23 | 380493 | 365 | | 53 | 387051 | 365 | | 80 | 374014 | 360 | | 179 | 378105 | 366 | +------------+---------+---------+
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
When web sites go bad: bible . org compromise
NOTE: The site is STILL compromissed right now. DO NOT VISIT.
This is more of an "awareness" item to show to coworkers and relatives that you can't be careful enough. "bible . org" is a site that offers as the name implies access to the bible and related commentary as well as translations. Sadly, earlier this week the site go appearantly compromissed. The owner was notified, but didn't have the means or skills to clean the site so far.
Like in so many cases, the exploit inserts javascript at the very top of the page. Likely this may have happened via a compromised configuration file. But right now, we don't know. The malicious content is only shown to some browsers based on the user agent string. So a plain wget or curl won't get you the malware. You need to specify the user agent string (for wget, setup a .wgetrc file to do this automatically, or use the -U switch).
The exploit inserts an iframe with changing URL following the pattern http://[random string].ddns.name/b6noxa1/counter.php?fid=2 (the domains I saw have been reported to changeip.com ).
The wepawet analysis [1] shows that at least one Adobe PDF vulnerability is being exploited, luckily an older one (CVE-2010-0188), but there is an additional PDF that webawet didn't analyse. It can be tricky to retrieve all components of these exploit kits from a non-vulnerable or simulated browser.
[1] http://wepawet.iseclab.org/view.php?hash=ae81a29e04bd93994c1f92411e58975a&t=1361545134&type=js
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Zendesk breach affects Tumblr/Pinterest/Twitter
Users of tumblr, and likely the other sites mentioned in the subject line, received an e-mail informing them of a breach of a company called "Zendesk". Like myself, you may not have heard of Zendesk before, but they appearantly process customer support e-mail for these sites, including like in the Tumblr case, e-mail to aliases like lawenforcement@ and legal@. According to Zendesk, the attacker retrieved email addresses and subject lines, not e-mail bodies. According to the Zendesk home page, there are many other namebrand companies that are using Zendesk, but the breach notification mentions only the three I listed in the subject.
Lessons learned:
- yet another "internet chokepoint" nobody thought about. A company like Zendesk, dealing with customer support for several large internet properties is a great point to monitor and collect intelligence as well as spreading malware. None of this has happened here.
- Limit confidential information in customer support e-mails. NEVER mention a password. But other information should be limited to what is necessary to describe the problem. Of course, this may have to include sensitive data (account numbers, software versions and configurations.
<Opinion>
With all the "Bad stuff" happending, we dodged some bad bullets this week. The NBC compromisse only led users to a rather old exploit. This Zendesk exploit didn't get very far (no e-mail bodies). The Bit9 exploit, even though it lasted for 6 months or so, was only used against 3 targets. Facebook/Apple developer compromisse didn't lead to backdoored code (we hope).
I think in particular the use of a "lame" exploit in the NBC case kind of points to another problem: It was probably pretty easy to deface the site.
</Opinion>
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
VMware releases new and updated security advisories
VMware has released the following new and updated security advisories:
New:
VMSA-2013-0003 http://www.vmware.com/security/advisories/VMSA-2013-0003.html
Updated:
VMSA-2012-0018 http://www.vmware.com/security/advisories/VMSA-2012-0018.html
VMSA-2013-0001 http://www.vmware.com/security/advisories/VMSA-2013-0001.html
Chris Mohan --- Internet Storm Center Handler on Duty
Comments