What has Iran been up to lately?

Published: 2013-02-22
Last Updated: 2013-02-22 20:28:35 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

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:

port scans from Iran over February 2013

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 .

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 | 
Interesting that the number of reported targets is rather small. Each target IP receives about 1,000 packets. But not all submitters report distinct target IPs and rather include a "dummy target IP" instead.
Sadly, we don't have any reports about the nature of the activity. Our ssh honeypot database is empty for this IP (and the /16 that goes with it). So if you have an ssh honeypot... check it ;-) and let us know what you find.

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: iran
4 comment(s)

When web sites go bad: bible . org compromise

Published: 2013-02-22
Last Updated: 2013-02-22 16:17:28 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

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

1 comment(s)

Zendesk breach affects Tumblr/Pinterest/Twitter

Published: 2013-02-22
Last Updated: 2013-02-22 13:40:16 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

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.


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. 


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

0 comment(s)

VMware releases new and updated security advisories

Published: 2013-02-22
Last Updated: 2013-02-22 08:05:52 UTC
by Chris Mohan (Version: 1)
0 comment(s)

VMware has released the following new and updated security advisories:


VMSA-2013-0003 http://www.vmware.com/security/advisories/VMSA-2013-0003.html


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

0 comment(s)
Chrome 25.0.1364.87 addresses multiple vulnerabilities http://googlechromereleases.blogspot.com.au/2013/02/stable-channel-update_21.html
ISC StormCast for Friday, February 22nd 2013 http://isc.sans.edu/podcastdetail.html?id=3142
PHP 5.4.12 and PHP 5.3.22 released http://www.php.net/ChangeLog-5.php


eweew<a href="https://www.seocheckin.com/edu-sites-list/">mashood</a>
dwqqqwqwq mashood
[https://isc.sans.edu/diary.html | https://isc.sans.edu/diary.html]
What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission

Diary Archives