サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「#文学」
sect.iij.ad.jp
先日 Akamai SIRT からも報告のあった123複数のゼロデイ脆弱性を悪用して感染を行う Mirai 亜種 InfectedSlurs の活動状況について、IIJ の観測結果を共有します。 アクターについて 今回のアクターによる攻撃活動を IIJ では昨年から継続して観測しています。今年 1月に発生した国内の河川監視カメラへの不正アクセス4も、同アクターによるボットの感染活動と見られます。10月末に悪用が確認されたゼロデイ脆弱性5もそうですが、主に日本国内でのみ利用されている機器も感染対象としているのが、このアクターの特徴の一つと言えます。 感染状況 11月から活動している検体は、感染時に機器のホスト名を “TBOT” または “PBOC” に変更するという挙動を行います。そのため比較的感染が見つけやすく、Shodan や Censys 等でこれらのホスト名を検索すると、少なくとも数
デジタルアイデンティティ難しいです。勉強のため、アイデンティティに関する世界最大規模のワークショップ IIW (Internet Identity Workshop) に参加してみることにしました。年に2回の会合で、第32回となる今回は2021年4月20日から3日間のオンライン開催です。アンカンファレンスと呼ばれるスタイルが採用されています。あらかじめプログラムが決められる通常のカンファレンスとは異なり、毎朝 Opening Circle という場でその日のプログラムを参加者たちが話し合いながら決めていくようです。 開催まで一週間を切った4月16日、IIW の事務局から開催案内メールが届きました。ワークショップでは QiqoChat という交流システムを使うようで、開催前に参加登録と動作確認をしておくようにとの指示でした。 QiqoChat への参加登録には2通りのやり方があるようです。1
かつて、技術レポート Internet Infrastructure Review (以下 IIR) で DDoS backscatter 観測状況を継続的に報告していました。最後の報告記事は2017年3月までを扱った IIR Vol.35 でしたから、それから3年近くになります。本記事では、この間の長期的な傾向の変化を紹介しようと思います。 DDoS backscatter とは DDoS における backscatter とは、送信元を偽ったパケットを受け取ったホストが、その偽装された送信元に対して返答するパケットのことです。DDoS 攻撃では送信元を偽った大量のパケットを送りつける攻撃手法があり、偽装された送信元がたまたま自分で使用している IP アドレスだった場合、その backscatter パケットを受け取ることになります。IIJ では MITF (Malware Invest
本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおいて、2019年に観測した IoT ボットの状況についてご紹介します。 主要なボットの活動状況 IIJ のハニーポットで観測される IoT ボットの活動として、Mirai, Hajime, qBot の 3種類が支配的である状況は昨年から変わっていません。Mirai と qBot はそれぞれ2016年と2015年にソースコードが公開されており、それ以降は元のコードを改変した多様な亜種が次々と出現する状況が継続しています。これらのボットの種類別に2019年の活動状況を以下に示します。なお2018年の観測状況についてはこちらの記事を参照してください。 (1) Mirai 図1 Mirai と推定される通信パケット数の推移 上のグラフは IIJ のハニーポットに到着したパケットのうち、Mirai の特徴に合致するも
2019年10月下旬に大規模な TCP SYN/ACK リフレクション攻撃を複数観測しました。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットの観測結果から、今回の DDoS 攻撃の発生状況について紹介します。 TCP SYN/ACK リフレクション攻撃 リフレクション攻撃 (リフレクター攻撃、アンプ攻撃とも呼ぶ) は、送信元アドレスを偽装した IP パケットを踏み台となる多数の機器 (リフレクター) に大量に送信することにより、その応答パケットを利用して攻撃する DDoS 攻撃手法の一つです。この場合、偽装された送信元アドレスがターゲットとなる被害者ということになります。真の発信元である攻撃者のアドレスを隠蔽するとともに、リフレクターからの応答パケットのサイズが大きくなる増幅効果を狙う攻撃です。UDP と比較すると増幅効果のあまり大きくない TCP によるリ
今月9/7から9/9にかけて、Wikipedia, Twitch, Blizzard の各サーバに対して連続して DDoS 攻撃が発生しました。この一連の攻撃は Mirai 亜種によるボットネットによって引き起こされたことが IIJ の調査によりわかりました。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットの観測結果から、この攻撃で利用されたボットネットの特徴と DDoS 攻撃の発生状況について紹介します。 DDoS 攻撃の概要 一連の攻撃は日本時間の 9/7 2:40 頃から始まり、最初に被害を受けたのは Wikipedia でした[1]Wikipedia への攻撃の状況については、ThousandEyes 社の解説記事が詳しい。Analyzing the Wikipedia DDoS Attack https://blog.thousandeyes.com
インターネット上の全アドレス空間を高速にスキャンするツールとして、Masscan と ZMap の2つが有名です。これらは研究者にも攻撃者にも幅広く利用されています。ですが、IIJ のマルウェア活動観測プロジェクト MITF のハニーポットによる観測において、両者の使われ方にはかなり違いがあることがわかりました。本記事でその内容について紹介します。 調査目的と見られるスキャンの増加 NICT サイバーセキュリティ研究所が2019年2月6日に公開した「NICTER観測レポート2018」では、2017年と比較して海外組織からの調査目的と見られるスキャンが大幅に増加したことが報告されました。このレポートでは、1日に30以上の宛先ポートに対して30万パケット以上のスキャンパケット (TCP SYN と UDP のみ) を送信するアドレスを調査目的のスキャンと判別しています。そして2018年の総パケ
IIJ のマルウェア活動観測プロジェクト MITF のハニーポットでは、送信元アドレスを偽装した 80/tcp に対する SYN/ACK リフレクション攻撃を2018年8月から継続して観測しています。2019年1月下旬からはさらに別のポートを対象とした同様の攻撃活動を観測しました。本記事でその内容について紹介します。 SYN/ACK リフレクション攻撃 80/tcp を利用した SYN/ACK リフレクション攻撃については、「wizSafe Security Signal 2018年9月 観測レポート」において詳しく報告しています。送信元アドレスを偽装した TCP の SYN パケットを多数のアドレスに同時に送信し、その応答である SYN/ACK パケットを利用して送信元アドレスに対して DDoS 攻撃を行うものです。IIJ の観測では2018年9月26日に大規模な SYN/ACK リフレ
本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおいて、2018年に観測した IoT ボットの状況についてご紹介します。またあわせて昨年末から今月にかけての最近の動向についても少し触れます。 全体サマリ 各ボットの観測状況について詳しく触れる前に、まず IoT ボット全体の動向や主要なトピックについてまとめておきます。 Mirai, qBot, Hajime の 3大ファミリーが勢力を維持多数のコードの販売、リークによる参入障壁の低下と亜種の多様化攻撃者らによる SNS の利用と DDoS 攻撃のさらなるカジュアル化Mirai 作者、Satori 作者らへの有罪判決Telnet 以外の感染手段として多様なエクスプロイトの利用DDoS 攻撃以外の目的を持ったボットの存在 我々のハニーポットでの観測において、Mirai およびその亜種、qBot およびその亜種、
IIJ のインシデントレスポンスチームのメンバーは、世界最高峰の国際カンファレンスのひとつである Black Hat USA 2018 において日本人として初めてトレーニング講師に選ばれ、”Practical Incident Response With Digital Forensics & Malware Analysis” の内容で4日間のトレーニングを提供することになりました。本トレーニングコースの実施概要はこのリンク内にありますが、このブログでは本コースのハイライトとコーススライドの一部サンプルをご提供します。 包括的かつ実践的なデジタルフォレンジクス及びインシデントレスポンス (DFIR) 標的型攻撃におけるインシデントレスポンス(事案対応)では、マルウェアやその他の攻撃ツールの特定、それらの機能や役割の特定、その事件が発生した根本原因の特定、ネットワーク内で横展開が行われたか
3月25日から世界中で 8291/tcp ポートへのスキャン急増が観測されています。これは Hajime ボットによる新たな感染活動が原因です。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおける観測状況について報告します。 (2018/4/3 追記) 3月31日から 8291/tcp だけでなく、2000/tcp への Hajime によるスキャン活動も観測しています。このポートも 8291/tcp と同じく MikroTik RouteOS が利用しているポートの一つです。スキャン後の挙動は下記に述べた 8291/tcp ポートの場合と同じです。 攻撃に利用している脆弱性 攻撃方法の詳細については複数のベンダーが報告していますので、そちらも参照してください。 Quick summary about the Port 8291 scan (360 Net
前回および前々回の記事において、2017年11月から12月にかけて、日本国内における Mirai 亜種の感染が急増したことを報告しました。その後2018年1月になって、国内からの Mirai 亜種によるスキャン通信が大幅に減少していることがわかりました。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおける2018年1月の Mirai 亜種の観測状況について報告します。 全体的な状況 図1 Mirai と推定される通信の推移 上のグラフは2018年1月に IIJ のハニーポットに到着した通信(スキャンのパケット)のうち、Mirai の特徴に合致するものを示しています[1]Mirai および Mirai のコードを流用した亜種の場合、スキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP … Continue reading。2017年12月に減
前回の記事では、2017年11月に日本国内において Mirai 亜種の感染数が急増したことを報告しました。また海外の特定の国においても国内と同様に感染数の急増が確認されました。12月に入り、海外での活動はやや沈静化したものの、日本国内からは依然として Mirai 亜種による活発なスキャン通信を観測しています。本記事では IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおける2017年12月の Mirai 亜種の観測状況について報告します。 全体的な状況 図1 Mirai と推定される通信の推移 上のグラフは2017年11月から12月の期間に IIJ のハニーポットに到着した通信(スキャンのパケット)のうち、Mirai の特徴に合致するものを示しています[1]Mirai およびその亜種の場合、スキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP アドレスが
IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおいて、11月にはいって国内からの Mirai 亜種によるスキャン通信が急増したことを確認しました。ユニークな送信元アドレス数からの推定では、国内において 4万台程度の感染規模と考えられます。本記事では最近の Mirai 亜種の活動の変化と国内での感染状況についてご紹介します。 IoT 機器に感染するボットの多くは、感染活動を行う前にまずインターネット上に存在する IoT 機器のスキャンを行います。Mirai およびその亜種の場合、スキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP アドレスが同じになるという特徴があります[1]これは Mirai 亜種の多くが昨年公開された Mirai … Continue reading。次のグラフは2017年9月から11月の期間に IIJ のハニーポットに到着した通信
2017年5月、ランサムウェア WannaCry の感染活動が世界中で観測されました。WannaCry は SMB の脆弱性を利用して感染を拡げるワーム機能を持っており、インターネット経由で爆発的に感染が拡大する要因となりましたが、幸いなことにキルスイッチ機能を持っていたため、比較的早い段階で収束しました。しかし5月末からこのキルスイッチ機能を無効にした亜種の活動が観測されはじめ、6月以降も活発な活動が継続しています。本記事では IIJ のハニーポットで観測されている最近の WannaCry 亜種の活動状況を紹介します。 WannaCry 亜種の特徴 5月に最初に活動が確認された WannaCry 2.0 と呼ばれるワーム機能をもつランサムウェアは、起動時にある特定の URL にアクセスし、成功した場合には以降の感染動作を行わないというキルスイッチの機能を有していました[1]キルスイッチと
前回の記事では、IIJ のマルウェア活動観測プロジェクト MITF のハニーポットに到達する通信の特徴から、Mirai および Hajime ファミリーの活動について紹介しました。本記事ではこれまでに知られている通信パターンに合致しない Mirai 亜種の最近の活動状況について解説します。 前回の記事でも触れたように、Mirai は感染活動を行う前にまずインターネット上に存在する IoT 機器のスキャンを行いますが、この時のスキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP アドレスは同じになります[1]Mirai については IIR Vol.33 のフォーカスリサーチ「1.4.1 Mirai Botnet の検知と対策」を参照。https://www.iij.ad.jp/company/development/report/iir/033/01_04.html。Mira
前回の記事では、Hajime ボットの活動状況について、その動作の特徴や宛先ポートによる挙動の違いについて解説しました。本記事では Hajime と Mirai およびその亜種について、IIJ のマルウェア活動観測プロジェクト MITF のハニーポットにおいて観測した通信の推移について示します。 Hajime や Mirai など主に IoT 機器に感染するボットの多くは、感染活動を行う前にまずインターネット上に存在する IoT 機器のスキャンを行います。このときの通信は、ボットの種類によってそれぞれ異なる特徴を持っていることが解析結果からわかっています。Mirai およびその亜種の場合、スキャンのパケットにおける TCP の初期シーケンス番号と宛先 IP アドレスが同じになります。一方 Hajime の場合には、TCP の初期シーケンス番号の上 16bit もしくは下 16bit の値が
Hajime は IP Camera や DVR などのいわゆる IoT 機器に主に感染するボットで、2016年10月に Rapidity Networks によって最初に報告されました。同時期に Mirai ボットによる大規模な DDoS 攻撃が観測されたため、その影に隠れていましたが、2017年に入ってから感染活動が活発に観測されるようになりました。また4月にはセキュリティベンダー各社から詳しい解説レポートが公開されています。本記事では、IIJ のマルウェア活動観測プロジェクト MITF のハニーポットで観測された Hajime の最近の活動状況について報告します。 概要 Hajime の動作の詳細については Rapidity Networks[1]Rapidity Networks, Hajime: Analysis of a decentralized internet worm
2017年4月7日15時現在、日本国内の Web サイトを経由した Rig Exploit Kit によるドライブバイダウンロード攻撃の検知数が増加しています。 IIJ Web クローラでの Rig Exploit Kit 検知件数 2017年3月下旬以降、同攻撃の検知数は比較的少数で推移していたものが変化しています。短期的な傾向で終わるのか、しばらく持続する傾向なのか予測することは困難ですが、拡大を続ける可能性も考えられるため注意が必要です。 IIJ の観測範囲では Rig Exploit Kit 自体について顕著な変更などは確認していません。攻撃には主に Adobe Flash の脆弱性を悪用し、成功した場合は Cerber や Matrix などのマルウェアがダウンロードされることを確認しています。なお、現時点で 0-day を利用する攻撃などは確認していません。 3月までは Rig
暗号アルゴリズムのうちデジタル署名などの用途で利用されているハッシュ関数のひとつ、SHA-1 のコリジョン(衝突)が報告されました。 今回見つけられた攻撃手法は SHAtterd attack と名付けられました[1]SHAttered attack https://shattered.it/ https://shattered.io/[2]Google Security Blog, Announcing the first SHA1 collision https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html。(暗号学的)ハッシュ関数は、異なるデータを異なる固定長データに圧縮することが保証されています。SHA-1 は160ビットの出力長を持つことから、2^80程度という膨大な SHA-1 計算
2016年9月頃より、日本国内の Web サイトを経由した Rig Exploit Kit による攻撃が急増しています。 IIJ Web クローラにおける Rig Exploit Kit の観測数推移 IIJ の観測範囲では、Rig Exploit Kit は主に Internet Explorer および Adobe Flash の脆弱性を悪用し、攻撃が成功した場合は Locky または Ursnif などのマルウェアがダウンロードされることを確認しています。 誘導元として観測された Web サイトは多数で、規模やコンテンツなどに共通点は確認できませんが、WordPress で運用されている Web サイトが複数見受けられます。また、誘導元の Web サイトには、2016年9月上旬から終息傾向にある Neutrino Exploit Kit や、2016年6月に終息した Angler E
先の記事にて解説したとおり、信頼できる通信路 との組み合わせにおいては、TCP のみで攻撃することは困難であるため、UDP におけるヒープ確保の阻止が焦点となります。つまり、A/AAAA の1セットの UDP レスポンスにおいて、それぞれが1024バイト、合計値が2048バイトを超過しない事が条件です。EDNS0 無効時においては、1レスポンスあたり512バイトであるため、仕様に沿っていればこれを超過しません。 多くの DNS キャッシュのソフトウェアにおいては、DNS クエリ/レスポンスのチェックや再構築をしているため、異常な構造を持つデータはフィルタされる場合が殆どです。EDNS0 無効時に512バイトを越えるデータを送りつけるような違反も同様です。 しかし、DNS の転送のみを行う DNS フォワーダにおいてはチェックが甘いため、今回の脆弱性に対する防御にはなり得ない場合もあります。
この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。本記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。 CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflow Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri
ブラウザ上で Windows のブルースクリーンを模した画面を表示し、あたかもマルウェアに起因する障害を生じているかのように見せかける詐欺サイトが国内外で確認されています。類似の詐欺は古くから存在しますが、最近確認されているものは、被害者の ISP 情報を表示するウィンドウをポップアップしたり、バナーで Microsoft ソフトウェアの専門家を名乗るなどして危機感を煽ります。このケースでは直ちに技術サポートと称する番号に電話をかけるよう促されます。メッセージが表示される段階では、あくまで HTML コンテンツとしてブルースクリーンを模しているだけであり、マルウェア感染などの障害は生じていません。ポップアップが邪魔でブラウザが閉じられない場合は、タスクマネージャーからブラウザを選択して終了する、あるいは ALT+F4 ショートカットを使うなどしてポップアップを回避することが可能です。 なお
Web ブラウザの拡張機能(プラグインなど)には、その拡張機能が組み込まれたブラウザでアクセスした先の URL を、インターネット側の第三者に送信する機能を持つものがあります。これらの拡張機能の多くは利用者の判断で、同意のもとに正当にブラウザに組み込まれたものです。しかし、この機能を利用者が属する会社などの組織の内部において使用したときには、その組織内部の Web サーバに関する情報が外部に送信されることになり、組織からの情報漏えいにあたる行為と考えることができます。IIJ では実際に数多くの企業などにおいて、このような拡張機能が導入されていることを確認し、対策を実施しています。ここに示す情報を組織のセキュリティ基準などと照らし合わせて、組織の内部においては URL を送信するような拡張機能を利用しないように対処することをお勧めします。 アクセスしたURLを外部に送信するブラウザの拡張機能
OpenSSL に Man-in-the-middle (MITM) 攻撃が可能な脆弱性 CVE-2014-0224 が発見され、日本時間2014年6月5日の夜に公開されました。そのアドバイザリでは合わせて7件の脆弱性が報告されていますが、本記事では脆弱性 CVE-2014-0224 を取り上げます。IIJ でも本脆弱性を調査した結果、MITM 攻撃が可能になるには条件があります。したがって、例えば使用している OpenSSL のバージョンや SSL/TLS 通信の利用の仕方に応じて、アップデートの緊急性を個別に検討する余地があります。 概要 本脆弱性による MITM 攻撃[1]MITM 攻撃とは、サーバとクライアントの間に攻撃者が割り込み、通信内容の盗聴や改ざんを行う攻撃です。では、サーバとクライアントの両方が OpenSSL を使っている場合に、その間にいる攻撃者が SSL/TLS ハ
本稿では日本時間2014年4月8日未明に公開された HeartBleed bug について取り上げます。 本脆弱性は OpenSSL 1.0.1 から 1.0.1f および 1.0.2beta1 において Heartbeat メッセージの処理において境界チェックの問題があり、OpenSSL が動作しているマシンのメモリ情報を取得可能な状態にあったことが公表されました[1]OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) https://www.openssl.org/news/secadv_20140407.txt。 RFC6520 で策定されている Heartbeat プロトコルは、リクエスト-レスポンス型の 2-way で完結する簡易なプロトコルで、SSL/TLS の R
本稿では HeartBleed bug による秘密鍵漏洩の可能性を考察します。 OpenSSL で利用される RSA 秘密鍵のフォーマットは PKCS#1[1]Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 http://tools.ietf.org/html/rfc3447#section-3.2 で定められています。暗号化された暗号文の復号、もしくはデジタル署名を行う際に RSA の秘密鍵による操作が行われます。SSL/TLS サーバに https でアクセスした場合には、その両方の用途で秘密鍵が用いられます。そのため HSM などの仕組みが無い場合には秘密鍵がメモリ上に展開されている可能性が高いと言えます。実際 Cloudflare Challenge[2
日本語などのマルチバイト文字を扱う環境において、IME (Input Method Editor) は切っても切り離せない機能です。最近は、この IME に常時インターネット接続を必要とする、クラウド関連の機能が実装されることが増えてきました。うまく使えば有益な機能ですが、利用における注意点などについて説明します。 クラウド機能の定義は IME 毎に異なりますが、概ね以下の様な機能を指しています。 ユーザ辞書の外部サーバへの保存(辞書同期)外部サーバからの変換候補の取得(クラウド変換) これらの機能は文字入力精度や効率の面から見ると非常に魅力的です。ですが、セキュリティの面から見た場合には注意する点があります。 ユーザ辞書の外部サーバへの保存(辞書同期) 殆どの IME はユーザの入力データを元に自動学習しており、効率的な変換が可能です。これらには自動的に学習した単語や、ユーザが自ら登録し
次のページ
このページを最初にブックマークしてみませんか?
『IIJ Security Diary – IIJ-SECT』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く