【情報】DNS cache poisoning report.

DNS cache poisoning report.
DNS キャッシュ中毒報告。
For background you may wish to review this report http://isc.sans.org/presentations/dnspoisoning.php
バックグラウンドのためにあなたはこの報告 http://isc.sans.org/presentations/dnspoisoning.php を再検討することを望むかもしれません
and this issue about BIND 4 or 8 not being suitable as forwarders http://isc.sans.org/diary.php?date=2005-04-28
そして BIND ４あるいは８についてのこの問題が forwarders http://isc.sans.org/diary.php?date=2005-04-28 として適当である

Next, a request. PLEASE review your dns servers logs and cache for 65.23.154.2 If you find it listed as authoritative for .com please send us an email with a dump of the dns cache. Directions for dumping, cleaning and protecting your cache are available in the write-up above.
次の、リクエストの。 どうかあなたの dns サーバーログを再検討してください、そうすれば６５.２３.１５４.２のためのキャッシュがもしあなたがそれが .com のために正式であると記載されているのを見いだすなら dns キャッシュのダンプでどうか我々に電子メールを送ります。 あなたのキャッシュをダンプして、きれいにして、そして守ることに対して、ディレクションは上記の批評記事で利用可能です。

Serverhome.com (65.23.154.2) is being reported for Kashpureff-style cache poisoning for the .com TLD.
Serverhome.com （６５.２３.１５４.２）は Kashpureff 式のキャッシュ中毒のために .com TLD のという理由で届け出られています。

This report shows there are about 16k domains hosted on this server.
この報告はこのサーバーでホストされたドメインが 16k についてあることを示します。
http://www.ipwalk.com/webhost/total_domains/webhost_name/serverhome.com
http://www.ipwalk.com/webhost/total_domains/webhost_name/serverhome.com

Be careful if you look up one of those domains there is a good chance you will see extra RR records including ones that claim they are authoritative for .com.
もしあなたがあなたが余分のＲＲを見るであろうという高い可能性が（彼・それ）らが .com のために正式であると主張する（の・もの・人）を含めて記録する存在するそれらのドメインの１つを検索するなら、注意深くしてください。

Sample packet showing the cache poisoning in action. Note the extra .com servers.
活動中キャッシュ中毒を見せているサンプルパケット。 余分の .com サーバーに気付いてください。

No. Time Source Destination Protocol Info
19 12.201047 65.23.154.2 192.168.0.3 DNS Standard query response A 65.23.154.2
Frame 19 (542 bytes on wire, 542 bytes captured)
Ethernet II, Src: Actionte_58:9d:0a (00:0f:b3:58:9d:0a), Dst: HonHaiPr_1d:cc:b4 (00:14:a4:1d:cc:b4)
Internet Protocol, Src: 65.23.154.2 (65.23.154.2), Dst: 192.168.0.3 (192.168.0.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: 3918 (3918)
Domain Name System (response)
Transaction ID: 0x0029
Flags: 0x8580 (Standard query response, No error)
Questions: 1
Answer RRs: 1
Authority RRs: 15
Additional RRs: 10
Queries
www.ibm.com: type A, class IN
Answers
www.ibm.com: type A, class IN, addr 65.23.154.2
Name: www.ibm.com
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 65.23.154.2
Authoritative nameservers
com: type NS, class IN, ns a.gtld-servers.net
Name: com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 20
Name server: a.gtld-servers.net
<SNIP b-m gtld-server list >
com: type NS, class IN, ns ns1.serverhome.com
Name: com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 17
Name server: ns1.serverhome.com
com: type NS, class IN, ns ns2.serverhome.com
Name: com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 6
Name server: ns2.serverhome.com
Additional records
a.gtld-servers.net: type A, class IN, addr 192.5.6.30
Name: a.gtld-servers.net
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
Data length: 4
Addr: 192.5.6.30

<SNIP b-gtld – g-gtld>

h.gtld-servers.net: type A, class IN, addr 192.54.112.30
Name: h.gtld-servers.net
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
Data length: 4
Addr: 192.54.112.30

I provided this information to the hosting provider Rackmounted.Com. They stated that
私はホスティング機能プロバイダ Rackmounted.Com にこのインフォメーションを提供しました。 （彼・それ）らはそれを述べました
"Returning unexpected answers to queries that will never occur in the wild is not abuse"
「決して荒野で起こらないであろう問合せへの意外な応答を返すことは虐待ではありません」

So I did a dig for serverhome.com a domain they own.
それで私は serverhome.com のために発掘現場に（彼・それ）らが所有するドメインをなしました。

dig @65.23.154.2 serverhome.com
; <<>> DiG 9.2.1 <<>> @65.23.154.2 serverhome.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15,
ADDITIONAL: 2
;; QUESTION SECTION:
;serverhome.com. IN A
;; ANSWER SECTION:
serverhome.com. 86400 IN A 65.23.154.2
;; AUTHORITY SECTION:
com. 86400 IN NS i.gtld-servers.net.
com. 86400 IN NS j.gtld-servers.net.
com. 86400 IN NS k.gtld-servers.net.
com. 86400 IN NS l.gtld-servers.net.
com. 86400 IN NS m.gtld-servers.net.
com. 86400 IN NS ns1.serverhome.com.
com. 86400 IN NS ns2.serverhome.com.
com. 86400 IN NS a.gtld-servers.net.
com. 86400 IN NS b.gtld-servers.net.
com. 86400 IN NS c.gtld-servers.net.
com. 86400 IN NS d.gtld-servers.net.
com. 86400 IN NS e.gtld-servers.net.
com. 86400 IN NS f.gtld-servers.net.
com. 86400 IN NS g.gtld-servers.net.
com. 86400 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
ns1.serverhome.com. 86400 IN A 65.23.154.2
ns2.serverhome.com. 86400 IN A 65.23.154.2




Highlights from the original Email thread reportng a DNS cache poisoning event.
オリジナルの電子メールスレッド reportng から DNS キャッシュ中毒イベントを強調します。

"I have been investigating a DNS problem my company experienced late
「私は（今まで）私の会社が遅れて経験した DNS 問題を調査していました
last week. Users were reporting that no matter what site they attempted to access they would receive a page indicating that the domain was for sale.
先週。 ユーザーが（彼・それ）らがどんなサイトにアクセスしようと試みたかにかかわらず（彼・それ）らがドメインが売りに出されたことを示しているページを受け取るであろうと報告していました。

I did some basic troubleshooting and found that all requests that were resolved against our internal DNS server were answered with the same address 65.23.154.2. I began digging in the DNS logs and found that NS record for the "com." zone had been inserted at what seemed to be a higher priority then the common TLD servers in the "com." domain.
私はいずれかの基本的なトラブル・シューティングをして、そして我々の内部 DNS サーバーに対して解決されたすべてのリクエストが同じアドレス６５.２３.１５４.２で答えられたことに気付きました。 私は DNS ログで堀り始めて、そして「com してください」地域のその NS レコードが（すでに）より高いプライオリティそれで共通の TLD サーバーであるように思われたもので「com してください」ドメインに挿入されていたことに気付きました。

After the cache became corrupted it caused our internal name servers to query 65.23.154.2 as a name server for the "com." zone. It would reply with the 65.23.154.2 address to any request that was requested.
キャッシュがだめになった後、「com してください」ゾーンのためにネームサーバーとして６５.２３.１５４.２を尋ねることは我々の内部のネームサーバーを起こしました。 それは６５.２３.１５４.２のアドレスで求められたどんなリクエストにでも答えるでしょう。

I was out of town at the time of the event and without understanding what it was I was
私はイベントの時点で旅行中で不在でした、そしてそれが何であったか理解しないで私はそうでした
dealing with I blocked access to 65.23.154.2 at our firewall, cleared the cache on all internal DNS servers and cleared the cache on our proxy.
１を扱うことは我々のファイアウォールにおいて６５.２３.１５４.２へのアクセスを阻止して、すべての内部 DNS サーバーでキャッシュをクリアして、そして我々のプロクシでキャッシュをクリアしました。

I then contacted the ISP and left word that I thought they may have
私はそれから ISP と連絡を取って、そして私が（彼・それ）らが持っているかもしれないと思った知らせを残しました
a misconfigured host on their network but I did not receive a response.
（彼・それ）らのネットワーク上の間違えて構成を設定されたホスト、しかし私は回答を受けませんでした。

Today, I was able to find the time to confirm these findings in a VM environment that I placed on our external network. The server is a MS Windows 2003 with SP1 installed and the "secure cache against pollution" check box was enabled.
今日、私は私が我々の外部ネットワークに対して与えたＶＭ環境でこれらの発見を確認するタイムを見いだすことが可能でした。 サーバーは、 SP1 がインストールするという状態で、ＭＳ Windows ２００３です、そして「汚染に対しての安全なキャッシュ」チェックボックスは使用可能でした。

I contacted MY_ISP yesterday and inquired as to what version of DNS they
私は昨日 MY_ISP と連絡を取って、そしてどんな DNS のバージョンについて尋ねた（彼・それ）ら
were running on our forwarders. They would only admit that they had
我々の forwarders 上で走っていました。 （彼・それ）らはただ（彼・それ）らが（すでに）そうしていたことを認めるだけでしょう
version(8.something) and seem quite defensive about the notion that they
バージョン（8.something）と概念について非常にディフェンスに思われますそれ（彼・それ）ら
had forwarded corrupt cache info that caused my company so much trouble
私の会社にそれほど多くの問題をもたらした不正なキャッシュインフォメーションを転送しました
late last week. It seemed as if they were insistent on saying that
先週遅く。 （彼・それ）らがそれを言うことを強く主張しているかのように思われました
their cache was not corrupted. I tried to explain that I didn't think
（彼・それ）らのキャッシュはだめになりませんでした。 私は私が考えなかったと説明しようとしました
that it was only that poisoned authority records had been passed to us
それがただ汚染された当局レコードが（すでに）我々に手渡されていたことだけということであったこと
from them as a result of an authoritative response from a malicious
（彼・それ）らから正式な応答の結果としてから悪意があります
server.
サーバー。

I am going to recommend that my company install its own DNS cache servers in our DMZ running the latest version of BIND and to NOT allow internal DNS servers to conduct recursive lookups."
私は私の会社がそれ自身の DNS キャッシュサーバーを BIND の、我々の DMZ を走っている最新のバージョンにインストールすることを勧めて、そして内部の DNS サーバーに回帰的なルックアップを行なうことを許さないために行きます。」

Additional DNS information.
追加の DNS インフォメーション。

There are a lot of other systems that are currently setup to do dns cache poisoning.
dns キャッシュ中毒をする現在セットアップである多くの他のシステムがあります。
http://dns.measurement-factory.com/surveys/200603-poison.txt
Cornell did a dns survey their report is available here:
コーネルはここで利用可能で（彼・それ）らの報告がそうである dns 調査をしました：
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html
ISC.com's DNS survey results
ISC.com の DNS 調査結果
http://www.isc.org/index.pl?/ops/ds/

（出展：ＳＡＮＳ）

【情報】What's a super.proxy.scanner and why is it

Published: 2006-05-02,
：２００６-０５ － ０２を発表しました、
Last Updated: 2006-05-02 20:58:42 UTC by Robert Danford (Version: 2(click to highlight changes) )
最新アップデート：２００６-０５-０２　ロバート Danford によっての２０：５８：４２の UTC （バージョン：２（変更を強調するクリック））

Disclaimers:
断り書き：
Visit the urls at your own risk.
自分の責任で URL を訪問してください。

One of our readers has come across an interesting phenomenon in his proxy logs that we're hoping someone can shed some light on.
我々の読者の１人が我々が誰かが若干の光を捨てることができることを希望している彼のプロクシログでの面白い事象を見つけました。

Imagine reviewing your webserver or proxy logs and seeing requests for a website completely unrelated to your organization,
あなたの Web サーバあるいはプロクシログを再検討して、そして完全にあなたの組織と血縁でないウェブサイトのためにリクエストを見ることを想像します、
but an IP address in your address block appears in the hostname.
けれどもあなたのアドレスブロックの中の IP アドレスがホスト名に現われます。

(Thanks to Jeremy for the report and the offer to share. I was able to find plenty of examples on the internet without referencing yours specifically)
（報告と分け合う申し出のためのジェレミーにありがとうございます。 私は特にあなたのを参照しないでたくさんの例をインターネットに見いだすことが可能でした）

So here is an example URL that might show up in your logs:
それであなたのログでここに現われるかもしれない例 URL があります：

http://check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
http://check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html

running the host command on the above hostname provides:
ホストコマンドを上記のホスト名上で走らせることは供給します：

check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn has address 61.135.170.153
check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn がアドレス６１.１３５.１７０.１５３を持っています

Hrm. 216.109.136.53 is a an IP in Hoboken, NJ. Thats about 6800 miles away from the host in China (61.135.170.153).
Hrm 。 ２１６.１０９.１３６.５３がそうである Hoboken 、ＮＪ、での IP . 中国（６１.１３５.１７０.１５３）のホストからおよそ６８００マイルの Thats 。

If you search for the string "super.proxy.scanner" in google you get 3 pages of proxy and web logs showing requests for various URLs that follow the form:
もしあなたがインチが Google で検索する文字列「super.proxy.scanner」を捜すなら、あなたは３ページのプロクシと web ログがフォームの後に続く種々の URL のリクエストを示しているようにします：

http://check.$ip_address.v.80.(pdx8|PCN22|mt1|pw1).super.proxy.scanner.(i.thu.cn|ii.9966.org)/Provy_OK.html
http://check.$ip_address.v.80.(pdx8|PCN22|mt1|pw1).super.proxy.scanner.(i.thu.cn|ii.9966.org)/Provy_OK.html

All of the hostnames resolve to 61.135.170.153. All of the logs I could find show this activity only in the March-April 2006 timeframe so relatively new.
ホスト名のすべては６１.１３５.１７０.１５３に確認します。 私が見いだすことができたログのすべてがそれほど比較的新しい３月 - ４月２００６年の timeframe でだけこの活動を見せます。

Visiting one of these hinkey URLs always provides the following (well at least in the few I tried):
これらの hinkey URL の１つを訪問することは常に（よく少なくとも私が試みた少数で）次のことを提供します：

"OK0001"
「OK0001」

The webserver is running lighttpd/1.4.11 (http://www.lighttpd.net/ )
Web サーバは lighttpd/1.4.11 (http://www.lighttpd.net/) を走らせています

Thats about all I could find. The string "super.proxy.scanner" showed up on a few sites as the top search results so someone or some program is looking for this traffic as well.
すべてについての Thats は、私は見いだすことができました。 ストリング「super.proxy.scanner」は少数のサイトでトップの検索結果の形で現われました、それで誰かあるいはいずれかのプログラムが同様にこのトラフィックを探しています。

So let us know if you have any theories (or maybe you know exactly whats going on here) See Below for new information. Also if you have any web/proxy log entries (or even better pcaps of all traffic related to one of these IPs) feel free to send them in. We'll post whatever we find in the diary.
それで我々にあなたがどんな理論でも（あるいは多分あなたはここで先へ進んで正確に whats を知っています）が新しいインフォメーションのために下を見るようにするかどうか知らせてください。 同じくもしあなたが Web / 代理を持っているなら、ログ参加者（あるいはこれらの IPs の１人と関係があるすべてのトラフィックのもっと良い pcaps さえ）が（彼・それ）らを呼び入れることを遠慮なくします。 我々は我々が日記に見いだすものは何でも公表するでしょう。

One interesting tidbit, while researching this I fat-fingered a lookup and the DNS server gave me an interesting IP back:
これを研究する間にルックアップと DNS サーバーが面白い IP 前に私に与えた私が脂肪 - 指で触った１の面白いかけら：

dig any suprt.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;suprt.proxy.scanner.ii.9966.org. IN ANY

;; ANSWER SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN A 61.135.170.153
suprt.proxy.scanner.ii.9966.org. 300 IN NS ns1.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS ns2.suprt.proxy.scanner.ii.9966.org.

;; AUTHORITY SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN NS ns2.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS ns1.suprt.proxy.scanner.ii.9966.org.

;; ADDITIONAL SECTION:
ns1.suprt.proxy.scanner.ii.9966.org. 300 IN A 61.135.170.159
ns2.suprt.proxy.scanner.ii.9966.org. 300 IN A 61.135.159.152

Here is what I would have gotten without my typo:
私のタイプミスなしでここに私が手に入れたであろうものがあります：
dig any super.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;super.proxy.scanner.ii.9966.org. IN ANY
;; ANSWER SECTION:
super.proxy.scanner.ii.9966.org. 300 IN A 61.135.170.153

;; AUTHORITY SECTION:
ii.9966.org. 86400 IN NS ns2.ii.9966.org.
ii.9966.org. 86400 IN NS ns1.ii.9966.org.

Some results from google:
check.216.109.136.53.v.80.pdx8.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.63.245.201.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.66.34.248.90.v.80.pcn22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.78.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.39.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.71.96.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.141.225.152.87.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.36.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.58.188.232.10.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.35.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.151.100.18.65.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.128.243.107.6.v.8080.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.167.196.204.113.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.htmlcheck.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html


Interesting entry from the web log for a webcam:
WebCam への web ログからの面白いエントリー：

Camera 1: Security alert:
カメラ１：セキュリティーの警告：
user from IP address: 61.135.170.159 is trying to read file:
IP アドレスからのユーザー：６１.１３５.１７０.１５９がファイルを読もうとすることです：
check.70.60.215.15.v.8080.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.70.60.215.15.v.8080.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html

Update: 5/2/06:
更新してください：５/２/０６：

Thanks to everyone who wrote in with theories and facts.
理論と事実で手紙を書いた皆にありがとうございます。

This activity appears to be related to a scanning tool call "proxy_scanner" which was released in Chinese hacker circles in 2004.
この活動は２００４年に中国のハッカーサークルでリリースされた走査のツールコール「proxy_scanner」と関係があるように思われます。
The site was.io8.org was used to distribute this tool and traffic related to that site was sent in to us as well.
サイト was.io8.org はこのツールを配布するために使われました、そしてそのサイトと関係があるトラフィックが同様に我々に提出されました。
(Note: we don't have a copy of the toolkit yet, so if anyone has a copy we can analyze.....)
（ノート：我々はまだツールキットのコピーを持っていません、それでもし誰かがコピーを持っているなら、我々は．．．を分析することができます。）

proxy_scanner details:
proxy_scanner の細部：

• Scans for proxies by breaking the sender queries into multiple parallel processes
  多数の平行したプロセスの中に送り主の問合せを破ることによって、代理を走査します
• Uses libpcap to listen for responses.
  libpcap を回答に聞き耳をたてるために使います。
• Target selection list is randomized
  目標セレクションリストが randomized されます

Here's an excerpt from a known Chinese hacker repository:
ここに周知の中国のハッカー倉庫からの抜粋があります：

http://proxy-scanner.thu.cn/proxy_scanner-0.0.14.tar.gz
http://proxy-scanner.thu.cn/proxy_scanner-0.0.14.tar.gz
It depends on libevent, and can run on Linux/FreeBSD box.
それは libevent に依存して、そして Linux / FreeBSD ボックス上で走ることができます。
No any document here now, all things is in source.
いいえ今、すべてものがソースでそうであるここのどんなドキュメントでも.
It's ugly but it's power full. it can scan whole B network in
それは醜いです、しかしそれはそれがＢネットワーク全体を走査することができるパワー full. です
60 seconds
http://was.io8.org/me/project

Related Hosts Details (thanks to Team CYMRU's wicked whois server):
関連した主催者の細部（チーム CYMRU の邪悪な whois サーバーのおかげで）：
AS Name
名前として
AS | IP | BGP Prefix | CC | Registry |

JINGXUN Beijing Jingxun Public Information Technology Co., Ltd
JINGXUN 北京 Jingxun 公共の情報技術社
9803 | 211.100.33.61 | 211.100.32.0/19 | CN | apnic |
９８０３ 　　 | ２１１.１００.３３.６１ 　　 | ２１１.１００.３２.０ / １９ 　　 | CN | apnic 　　 |

CHINANET-BACKBONE No.31,Jin-rong Street
4134 | 61.183.15.41 | 61.183.0.0/19 | CN | apnic |
4134 | 61.183.15.62 | 61.183.0.0/19 | CN | apnic |

CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
4808 | 61.135.159.152 | 61.135.128.0/19 | CN | apnic |
4808 | 61.135.170.153 | 61.135.0.0/16 | CN | apnic |
4808 | 61.135.170.159 | 61.135.0.0/16 | CN | apnic |

Note: If you see an IP you own in one of the above URLs you might want to check your proxy configuration.
ノート：もしあなたが上記の URL の１つであなたが所有する IP を見るなら、あなたはあなたのプロクシ形状をチェックすることを望むかもしれません。
Here is are a few resources regarding open proxies and how to secure them:
ここにそうである、公開されているプロクシと（彼・それ）らをしっかり固定する方法に関して：少数のリソースです
http://www.ftc.gov/secureyourserver/
http://www.us.sorbs.net/faq/proxy.shtml
http://en.wikipedia.org/wiki/Proxy_server

You can also refer to this list of open proxies and see if your site is listed:
あなたは同じく公開されているプロクシのこのリストに言及して、そしてあなたのサイトが目録に載っているかどうか見ることができます：
http://www.publicproxyservers.com/page1.html

The background as to why the proxies are entered into DNS is still a little sketchy.
プロクシがなぜ DNS に入力されるかについてのバックグラウンドはまだ少し概略だけです。
Several bright folks wrote in hypothesizing how this method might be capable of detecting nested proxy networks.
いくつかの頭が良い人々がこの方法がネストされたプロクシネットワークを検出することができるかもしれない方法を仮定して手紙を書きました。

Robert - SANS ISC Handler
ロバート － ISC 調教師なしで

（出展：ＳＡＮＳ）

【情報】Nugache

There's a new bot (known as "Nugache") going around. This one is not creating botnets via IRC as they most often do - it's using a peer-to-peer network via TCP port 8.
広まっている（「Nugache」として知られている）新しいロボットがあります。 （彼・それ）らが最もしばしばそうする（とき・から・につれて・ように）、これは IRC によって botnets を作っていません － それは TCP 港町８を経由してピアトゥーピアネットワークを使っています。

This is not the first malware to create p2p networks of infected hosts - Linux worm Slapper premiered this technology already in 2002.
これは感染しているホストの p2p ネットワークを作る最初の悪性ソフトではありません － Linux 虫 Slapper は２００２年にすでにこの技術を初演しました。

We currently detect this Nugache thingy as "Backdoor.Win32.SdBot.aqy".
我々は「Backdoor.Win32.SdBot.aqy」として現在この Nugache 何とかを発見します。

（出展：F-Secure）

【サイバー犯罪事件簿】2006年05月02日

----------------------------

■あまてらす

----------------------------

GW休暇で旅行へ行ってきます。

そのため、5月5日金曜日までは、ブログの更新は行いません。

申し訳ありませんが金曜日まで、お待ちください。

----------------------------

■セキュリティニュース

----------------------------

ハッカー

PCにハッカートラップを仕掛けるIntel

ハッキングで手札が丸見えだった

脆弱性

［米国］ ゼロデイ攻撃にシンプルなアプローチで対抗

DNS製品の一部に脆弱性──研究機関がテスト・ツールを提供

Winny

ボーダフォン、基地局関連情報がWinnyで流出したと発表

キングソフト、「キングソフトインターネットセキュリティ2006」でShare起動時に警告画面を表示

セキュリティ

生年月日なしでも決済ＯＫ 日銀、個人情報保護で検討

日本企業はセキュリティ意識高いが自信ない、IBM調査
日本IBM、サイバー犯罪への対策済み、世界の59％に対して日本は15％、世界3,002社へのセキュリティー調査結果発表

その他
「ドライブバイインストール」防止ツール、Exploit Prevention Labsが開発

インテルとAMD、次世代チップの売り文句は「仮想化」と「管理」

----------------------------

■不正なアクセス(日本を送信元とした攻撃)

----------------------------

自分の管理するグローバルIPアドレスが以下のリストに含まれている場合は、ウィルスまたはボットワームに感染している恐れが高いです。至急ウィルススキャンを実行される事を推奨します。

おやすみ

【情報】As the Bot Turns (NEW)#2

Update 2:
最新情報２：

A few hours ago, Bleeding Snort issued some rules to help people detect this botnet on their network. The signatures are located at bleedingsnort.com.
数時間前に、出血 Snort は人々が（彼・それ）らのネットワーク上でこの botnet を検出するのを手伝うために若干の規則を発行しました。 サインは bleedingsnort.com に位置しています。

Update 3:
最新情報３：

Below is the list of IPs that are contacted initially by this botnet. It is provided to give businesses an opportunity to block the IPs and protect their network.
下は初めにこの botnet によって連絡を取られる IPs のリストです。 それはビジネスに IPs を阻止して、そして（彼・それ）らのネットワークを守る機会を与えるために提供されます。

24.165.115.55
24.206.248.179
24.217.137.235
65.189.204.247
65.30.81.171
67.149.59.200
67.177.114.151
68.110.80.140
68.118.224.56
68.198.41.207
68.46.202.77
69.113.158.42
69.113.3.220
69.133.103.15
69.141.98.226
69.165.59.82
69.234.207.37
70.132.132.38
71.224.113.40
72.129.129.157
128.211.221.47
216.174.161.17

Hope all of you have a pleasant May day in the morning.
あなたたちみんなが朝楽しい５月の日を持つことを希望してください。

【サイバー犯罪事件簿】2006年05月01日

----------------------------

■あまてらす

----------------------------

Ｎｅｐｅｎｔｈｅｓという。Malwareを効率的に収集するためのツールをインストールしてみました。

検証でウイルスの検体が必要な場合があるとおもいますが、そんなときに役立ちそうなツールです。

----------------------------

■セキュリティニュース

----------------------------

ハッカー

UFO求め、米軍システムに侵入したハッカー

ボットをもっと知らしめなければ

Winny

防衛庁に習う Winny対策とは

ニフティ，「Winny」の速度制限を強化開始

政府が、ウィニー対策で独自ソフト開発へ

IPA、「Winny」だけでなく「Share」でも感染するAntinny亜種に注意

注意喚起

JPCERT、ゴールデンウィーク前にシステム管理者が確認すべきこと

セキュリティ

ゼロデイ攻撃遮断ツール「SocketShield」のβ版提供開始

国のセキュリティ対策プログラム「セキュア・ジャパン2006」案を公開
政府が「セキュア・ジャパン2006」案を公開、133項目に上る具体策を提示

その他
英国政府、IBMと協力してSELinuxを試験運用へ

政府が開発するセキュアOS環境とは？
米国が“IT後進国”になる!? “国家CIO”のリーダーシップで最悪のシナリオを回避せよ

----------------------------

■不正なアクセス(日本を送信元とした攻撃)

----------------------------

自分の管理するグローバルIPアドレスが以下のリストに含まれている場合は、ウィルスまたはボットワームに感染している恐れが高いです。至急ウィルススキャンを実行される事を推奨します。

おやすみ

【情報】Nepenthes インストール

■Ｎｅｐｅｎｔｈｅｓとは？

名前は、食虫植物「Nepenthes(うつぼかずら)」です。

このツールは、Malwareを効率的に収集するためのツールです。
攻撃を受けた場合に仕込まれるファイルを捕獲することができます。

■結果

昨日一日で、15種類のＭａｌｗａｒｅを捕獲することができました。

検証に使うための検体を集めるのに、便利なツールです。

■インストール（インストールの際、お世話になったサイトです。）

Nepenthes インストールメモ

http://grin.flagbind.jp/archives/2005/12/nepenthes.html

nepenthes　-Malware収集ツール-

http://kikuz0u.x0.com/memo/hiki.cgi?nepenthes%A1%A1-Malware%BC%FD%BD%B8%A5%C4%A1%BC%A5%EB -

【情報】As the Bot Turns (NEW)

Published: 2006-04-30,
：２００６-０４ － ３０を発表しました、
Last Updated: 2006-04-30 18:26:20 UTC by Scott Fendley (Version: 2(click to highlight changes) )
最新アップデート：２００６-０４-３０　スコット Fendley によっての１８：２６：２０の UTC （バージョン：２（変更を強調するクリック））

The below was sent to us as well as some of the ISACs around the net tonight. As there is quite a bit of information being conveyed by the author, I am going to leave the majority of the advisory as originally written. I will note that this started with a click happy user on AIM to the best of our knowledge.
下はネットの周りに今晩、アイザック家の人たちの若干と同様、我々に送られました。 著者によって伝えられている相当のインフォメーションがある（とき・から・につれて・ように）、私は同じぐらい元来大多数の助言が書かれる状態にしておくつもりです。 私はこれが我々の知る限りでは狙い打ちでクリックの幸せなユーザーで始まったことを指摘するでしょう。

---snip---
---切断---
A bot was seen spreading via AOL Instant Messenger (AIM) earlier today that appears to be using "encrypted"[1] peer-to-peer (P2P - possibly Waste?) as the Command and Control (C&C) mechanism. The bots communicate with each other via port 8/TCP.
「暗号化される」［ 1] 「対等者への対等者」（P2P － 多分廃物ですか？）をコマンドとコントロール（Ｃ＆Ｃ）メカニズムとして使用しているように思われるロボットが今日早く AOL インスタントメッセンジャー（狙い打ち）によって広まっているのを見られました。 ロボットはポート８ / TCP によってお互いとコミュニケートします。

The bot does not use DNS to find any C&C. It also does not use any human readable strings in its client/server communication. Therefore, many IDS measures will not help you detect infected hosts on your network. Flow analysis and/or tcpdump looking for mysterious port 8/TCP traffic seems to be the best way to detect these infections on your network.
ロボットは DNS をＣ＆Ｃを見いだすために使いません。 それは同じくそのクライアント／サーバコミュニケーションで人間が読むことができるストリングを使いません。 そのために、処置があなたが検出するのを助けないであろう多くのＩＤがあなたのネットワーク上でホストに伝染しました。 流れ分析そして／あるいは神秘的なポート８ / TCP トラフィックを探している tcpdump があなたのネットワーク上でこれらの伝染病を検出する最も良い方法であるように思われます。

I realize that phatbot has been able to use Waste as the C&C for several years. However, I remember finding these botnets years ago, and the bots involved, and they typically were 600KB or more in size. The bot involved here is comparatively lean at 173KB.
私は phatbot が（今まで）数年間廃棄物をＣ＆Ｃとして使うことが可能であったことを悟ります。 しかしながら、私は何年も前にこれらの botnets を見いだしたことを覚えています、そして関係しているロボットと（彼・それ）らは典型的に６００ＫＢ、あるいはいっそうサイズのでした。 ここで関係しているロボットは１７３ＫＢにおいて比較的貧弱です。

Info about the sample I obtained:
私が得たサンプルについてのインフォメーション：
MD5: 74600e5bc19538a3b6a0b4086f4e0053
MD5 ：　74600e5bc19538a3b6a0b4086f4e0053
Installation Location (when run): %WINDIR%\System32\mstc.exe
インストレーションの場所（走らせられるとき）：％ WINDIR%\System32\mstc.exe
WinXP Firewall: Grants itself an exception called "null", which allows inbound 8/tcp from anywhere. This was done without the user notification pop-up (it likely edited the registry entry directly).
WinXP ファイアウォール：それ自身にどこからでも内行きの８ / tcp を許す「空である」と呼ばれる例外を与えます。 これはユーザー通知ポップアップ（それは直接多分レジストリ項目をエディットしました）なしでされました。

The file distributed via the AIM link and %WINDIR%\System32\mstc.exe are identical - no other files are dropped, etc.
リンクの目的によって配布されたファイルと％ WINDIR%\System32\mstc.exe は同一です － 他のどのようなファイルも落とされるなどしません。

I infected a test computer with the binary. It tried to connect to port 8/tcp on 22 different IP addresses. (Note that these are most likely the "seeds" of the P2P network that were coded into the version of the binary that I downloaded.) Only four of the IP addresses responded that they were listening on 8/tcp.
私は２進数を持っているテストコンピュータを感染させました。 それは２２の異なった IP アドレスの上にポート８ / tcp に接続しようとしました。 （これらが最も見込みが高く私がダウンロードしたという２進のバージョンの中にコードされた P2P ネットワークの「種」であることに注意を払ってください。） IP アドレスのたった４が（彼・それ）らが８ / tcp の上に聞いていたと応えました。

My lab computer tried to contact each of the 22 IP addresses many times (I left it infected for about 15 minutes with a firewall in place that blocked all incoming packets, solicited or otherwise). Since it tried to contact each of these many times, and not any other IP addresses, I feel it is fairly safe to guess it was not randomly selecting IPs to obscure "the real C&Cs".
私のラボコンピュータは何度も２２の IP アドレスのそれぞれと接触しようとしました（私はそれをおよそ１５分間要請されたか、あるいは違っているすべての入ってくるパケットをふさいだ配置されるファイアウォールに感染しているままにしておきました）。 それが他のいかなるも IP アドレスではなく、これらの多くの回数のそれぞれと連絡を取ろうとしましたから、私はそれがランダムに不明瞭にするべき IPs 「本当の C & Cs」を選択していなかったと思うことはかなり安全であると感じます。

Anyhow, after 15 minutes of firewalling off all inbound packets altogether (even SYN/ACKs) to my infected lab computer, I lifted the incoming IP restriction. The first host my lab computer connected to on 8/tcp started a relatively short connection (10-12 packets each way), and nothing was in cleartext. In the middle of the TCP conversation, that same host connected to port 8/tcp on my host (the malware holds that port open). The connection from them to me was simply a three-way handshake, immediately followed by FIN/ACKs from them then me. It then closed my connection to it altogether, via FIN/ACKs again.
いずれにしても、１５分のまったくすべての内行きのパケットから離れてファイアウォールを使うこと（SYN / ACKs さえ）の後に私の感染しているラボコンピュータに、私は入ってくる IP 制限を撤廃しました。 私のラボコンピュータが８ / tcp の上に接続した最初のホストは（１０-１２パケットそれぞれの方法で）比較的短い接続を始動させました、そして何も cleartext にありませんでした。 TCP 会話の真ん中で、その同じホストは私のホスト（悪性ソフトはそのポートを開いたままにしておきます）の上にポート８ / tcp に接続しました。 接続は（彼・それ）らから私まで（彼・それ）ら それから私からただすぐにひれ / ACKs によって後に続かれた三者の握手でした。 それはひれ / ACKs を経由して再び、まったく、それからそれに私の接続を閉ざしました。

My host then tried several other IPs (still in the list of 22, with only four of them online), and this time, connected successfully to a different host. The connection lasted for a couple of minutes before I pulled the plug.
私のホストは（まだ２２のリストで、（彼・それ）らのたった４がオンラインであるという状態で、）それから数匹の他の IPs を裁いて、そして今回は、成功裏に異なったホストに接続しました。 私が最後通牒を渡す前に、接続は２分の間続きました。

There was more communication this time around. During the connection, the remote host connected to 8/tcp on me just like the other one did (three-way handshake, then FIN/ACK, just like before). The initial connection from my host to theirs continued afterward. One of the packets from the remote host contained a full 1460 bytes of data. (Other packets to/from 8/tcp on infected hosts thus far had contained 64 bytes of data or less.) There was no SSL/TLS negotiation evident, and again, the contents were not human readable. I haven't taken the time yet to see if it's something simple like XOR or Base64. I suspect the content was an updated list of other infected hosts.
今回の場合もっと多くのコミュニケーションがありました。 接続の間に、私の上に他の（の・もの・人）とまったく同じように８ / tcp に関係した遠いホストはそうしました（三者の握手、それからひれ / ACK が、ただ前に好みます）。 最初の接続は 私のホストから（彼・それ）らのまでその後継続しました。 遠いホストからのパケットの１つが完全な１４６０バイトのデータを含みました。 （他のパケットが８ / tcp から / まで感染しているホストの上にこれまでのところ（すでに）データの６４バイトかそれ以下を含んでいました。） 明白な SSL / TLS 交渉がありませんでした、そして再び、内容は人間が読むことができませんでした。 私はまだそれが XOR あるいは Base64 のように単純な何かであるかどうか見るのに時間をかけませんでした。 私は内容が他の感染しているホストの更新されたリストであったと思います。

While still connected to that host, my bot still tried connecting to others (not common for a traditional botnet, but expected for a P2P connection). It connected successfully to a third host. My host did to that host as the others above did to it - complete the three-way handshake, then ended it with FIN ACKs. It then connected to another host that was NOT on the initial seed list. (My theory is that my host learned of this one from another bot) After that, I turned it off, so that I could write this.
まだそのホストにつながれる間に、私のロボットはまだ（伝統的な botnet のために普通ではないが、 P2P 接続に待っていられた）他の人たちに接続しようとしました。 それは成功裏に３番目のホストに接続しました。 他の人たちが上にそれに － 三者の握手を完了した（とき・から・につれて・ように）、私のホストはそれにホストをして、それからひれ ACKs でそれを終わらせました。 それはそれから最初の種リストに載っていなかったもう１つのホストに接続しました。 （私の理論は私のホストがもう１つのロボットからこれを知ったということです）それの後に、私がこれを書くことができるように、私はそれを止めました。

Moral of the story: Prepare to watch for 8/tcp flows for a while. Unless I'm wrong, this botnet should be able to stick around for a while.
物語の教訓：しばらくの間８ / tcp 流れを見張る準備をしてください。 私が間違っていないなら、この botnet はしばらくの間近くで待つことが可能であるべきです。

[1] I am using "encrypted" in quotes because I have not identified the protocol - but it is not human-readable. I'm sorry if this sounds FUD-like, but I wanted to get the word out sometime *before* I had done hours of analysis!
［１］私がプロトコルを識別しなかったから、私はクォートで「暗号化される」を使っています － しかしそれは人間が読むことができません。 私はもしこれが FUD のように聞こえる、しかし私がワードを提出することを望んだなら、いつか * 前に * 私が（すでに）何時間もの分析をしていたことを遺憾に思います！
-------Snip-------
-------切断-------

Update 1:
最新情報１：

Earlier Sunday, Symantec has posted a write-up about this particular binary. It is located at http://www.sarc.com/avcenter/venc/data/w32.nugache.a@mm.html . Please note that they do not have any mention about the P2P traffic noted above. There is more analysis being done on malware by the various AV companies and others in our malware analysis team.
日曜日により以前に、 Symantec はこの特定の２進について批評記事を公表しました。 それは http://www.sarc.com/avcenter/venc/data/w32.nugache.a@mm.html に位置しています。 どうか（彼・それ）らが上に指摘された P2P トラフィックについて言及を持っていないことを指摘してください。 我々の悪性ソフト分析チームで種々のＡＶ会社と他の人たちのそばに悪性ソフトの上にされているもっと多くの分析があります。

I expect that this binary will be detected by most AV companies quickly (today I hope) and slow its spread tremendously. However, I also expect that this is a signal that the botnet writers are entering a new generation of development and capabilities. Those of us that are tasked with defending our various networks will need to find a new and better game plan to spot and counter these encrypted/p2p based botnets.
Ｉ　この２進が速くたいていのＡＶ会社によって検出されると思ってください（今日私は希望します）そしてものすごくその普及を遅くします. しかしながら、私は同じくこれが botnet 著者が 発達と能力の新しい世代に入っているというシグナルであると思います。 我々の種々のネットワークを弁護するという仕事を与えられる我々の人たちはこれらの暗号化された / p2p ベースの botnets を見つけて、そしてそれに対処する新しい、そしてもっと良い作戦を見いだす必要があるでしょう。

--
－
Scott Fendley
スコット Fendley
Handler on Duty
勤務中の調教師

(出展：ＳＡＮＳ）

【情報】No SMS sending Symbian bluetooth viruses

Today we have received several questions concerning our supposed warning about a new Symbian worm that spreads via Bluetooth and sends premium rate SMS messages.
今日我々はブルートゥースによって広がって、そして保険料率 SMS メッセージを送る新しいシンビアン虫についての我々のなっている警告に関するいくつかの質問を受け取りました。

We were rather puzzled about those questions however, as we haven't seen any such malware. And obviously we have not made any warnings of such, otherwise you would have seen it on our weblog.
我々がそのようなマルウェアを見なかった（とき・から・につれて・ように）、我々はしかしながらそれらの質問についてどちらかと言うと当惑しました。 そして明らかに我々はそんなものの警告をしませんでした、さもなければあなたは我々の web ログでそれを見たでしょう。

It turns out that the confusion was caused by an article on vnunet where the vnunet reporter interviewed our UK country manager who was speaking about the Redbrowser.A trojan. And apparently the reporter misunderstood a quite harmless Java trojan as a dangerous bluetooth worm that is spreading in the wild. It seems that the reporter got mixed up with Redbrowser and Commwarrior.
混乱が Redbrowser.A trojan について話していた vnunet リポーターが我々の英国の田舎っぽいマネージャーにインタビューした vnunet についての論文によって起こされたということが分かります。 そして見たところではリポーターは非常に無害な Java trojan を野生で広がっている危険な bluetooth 虫であると誤解しました。 リポーターが Redbrowser と Commwarrior で混乱したように思われます。

So to clarify things, there are only two known malwares that send SMS messages: Java/Redbrowser.A and SymbOS/Mquito.A . Both of these malwares are trojans, which means that they don't spread by themselves and need users to download and install them before they can do anything.
それでことを明確化するために、 SMS メッセージを送るたった２つの周知の malwares があります： Java/Redbrowser.A と SymbOS/Mquito.A 。 これらの malwares の両方ともは（彼・それ）らが（彼・それ）らだけで広がって、そしてユーザーがダウンロードして、そして、（彼・それ）らが何もすることができる前に、（彼・それ）らをインストールすることを必要としないことを意味する trojans です。

Redbrowser.A is a trojan that sends SMS messages to a Russian premium rate number and does not use the country code. That means that the premium rate number works only in Russia. And since the user interface of Redbrowser is in Russian, it is not a problem anywhere else other than Russian speaking countries.
Redbrowser.A はロシアの保険料率数に SMS メッセージを送って、そして田舎っぽいコードを使わない trojan です。 それは保険料率数がロシアでだけ働くことを意味します。 そして Redbrowser のユーザインタフェースがロシア語でですから、それはロシア語を話す国以外に他のどこ（で・に）も問題ではありません。

Mquito.A is a cracked version of the game Mosquitos that sends SMS to a UK based premium rate number. But the premium rate number has been discontinued, and thus causes only the cost of a normal SMS.
Mquito.A は SMS をＵＫベースの保険料率数に送るゲーム蚊のひび割れたバージョンです。 けれども保険料率数は中止されました、そしてそれでただ普通の SMS のコストだけを起こします。

Other than these two trojans, we don't know of any other case of malware on any platform that would send SMS messages. And most certainly we have not seen a bluetooth worm that would do so.
これらの２つの trojans 以外に、我々は SMS メッセージを送るであろうどんなプラットホームの上にも悪性ソフトの他のいかなるケースについても知りません。 そして最も確かに我々はそうするであろう bluetooth 虫を見ませんでした。

So, if you see any articles dated around the 25th of April that speak of F-Secure warning about a new Bluetooth worm that sends SMS messages, please disregard the article. Also, I would recommend being suspicious about any stories of F-Secure warning about new malware and there being no mention at all about the case on our weblog.
それで、もしあなたが SMS メッセージを送る新しいブルートゥース虫についてＦ - 確かな警告について話す４月２５日ごろの日付の記事を見るなら、どうか論文を無視してください。 同じく、私は新しい悪性ソフトについてのどんなＦ - 確かな警告でも物語に関して疑問を抱いていて、そして我々の web ログでケースについてまったくそこ（に・で）言及ではないことを勧めるでしょう。

Edited to add [Friday the 28th by Sean]: Our UK office and vnunet have worked together to resolve the miscommunications regarding the article linked to above. It's been revised to stress that the examples used were of trojans. We here in the Helsinki labs express our thanks to vnunet for updating the article.
エディットされて、［２８日金曜日にショーンによって］付け加えるために：我々の英国のオフィスと vnunet は上にリンクされた論文に関してミスコミュニケーションを解決するために一緒に働きました。 それは使われた例が trojans の（こと・もの）であったことを強調するために修正されました。 論文を更新することに対して、我々は vnunet するためにここ、ヘルシンキラボで我々の感謝を表現します。

（出展：F-Secure)

【情報】and little flaws in IVE

Published: 2006-04-27,
Last Updated: 2006-04-28 01:53:25 UTC by donald smith (Version: 1)

Juniper Networks released a vulnerability announcement today.
西洋ビャクシンネットワークが今日弱点発表をリリースしました。
From: http://www.juniper.net/support/security/alerts/PSN-2006-03-013.txt
差出人： http://www.juniper.net/support/security/alerts/PSN-2006-03-013.txt
"Title: IVE ActiveX client vulnerability
「タイトル： IVE ActiveX クライアント弱点
Date: 25 April 2006
Version: 1.0

Impact: Client side code execution in context of Internet Explorer
影響：インターネット・エクスプローラの文脈でのクライアントサイドのコード実行
Affected Products: IVE OS 1.x to 5.x
影響を受けたプロダクト： 5.x への IVE OS 1.x
Max Risk: High
最大限危険：高く
Recommended Actions: Upgrade the IVE software to any of the following fixed versions: 5.3r2.1, 5.2r4.1, 5.1r8, 5.0r6.1, 4.2r8.1"
推薦された行動：次の固定されているバージョンのいずれにでも IVE ソフトウェアをアップグレードしてください： 5.3r2.1 、 5.2r4.1 、 5.1r8 、 5.0r6.1 、 4.2r8.1」

It appears that an activeX control that is installed when using IVE can be remotely exploited.
IVE を使うとき、インストールされる activeX コントロールが間接的に利用され得るように思われます。
The exploit described by eeye looks fairly trivial.
eeye によって記述された偉業はかなり些細に見えます。

IVE is Instant Virtual Extranet which provides SSL VPN control with centralized reporting, monitoring and configuration management. It is basically a host security auditor and can be used as an element of their netscreen remote client. It can verify things like recent virus signatures and scans. Which is important before letting some machine on to your corporate network!
IVE は 集中させられた報告、モニタリングとコンフィギュレーションマネージメントを SSL VPN コントロールに提供する緊急のバーチャルエクストラネットです。 それは基本的にホストセキュリティー監査役であって、そして（彼・それ）らの netscreen の遠いクライアントの要素として使用されることができます。 それは最近のウイルス署名と走査のようなことを実証することができます。 どちらかは、 あなたの企業のネットワークにいずれかの機構を乗せる前に、重要です！

eeye has published the details here:
http://www.eeye.com/html/research/advisories/AD20060424.html

(出展：ＳＡＮＳ）