マルウェアEmotetの感染再拡大に関する注意喚起
JPCERT-AT-2022-0006 JPCERT/CC 2022-02-10（新規） 2023-03-20（更新） I. 概要JPCERT/CCでは、2021年11月後半より活動の再開が確認されているマルウェアEmotetの感染に関して相談を多数受けています。特に2022年2月の第一週よりEmotetの感染が急速に拡大していることを確認しています。Emotetに感染しメール送信に悪用される可能性のある.jpメールアドレス数は、Emotetの感染が大幅に拡大した2020年に迫る勢いとなっています。詳細は後述する「V. 観測状況」をご確認ください。感染や被害の拡大を防ぐためにも、改めて適切な対策や対処ができているかの確認や点検を推奨します。 （更新: 2023年3月8日追記） 2022年11月以降、Emotetの感染に至るメールの配布は確認されていませんでしたが、2023年3月7日より配布
Javeセキュアコーディング 並行処理編
Java セキュアコーディング 並行処理編 Fred Long Dhruv Mohindra Robert Seacord David Svoboda 2011 年 8 月（原著「Java Concurrency Guidelines」公開 2010 年 5 月） TECHNICAL REPORT CMU/SEI-2010-TR-015 ESC-TR-2010-015 CERT® Program http://www.cert.org/ 一般社団法人 JPCERT コーディネーションセンター（JPCERT/CC）訳 https://www.jpcert.or.jp Japan Computer Emergency Response Team Coordination Center : Japan Computer Emergency Response Team Coordination C
LCK08-J. 例外発生時には保持しているロックを解放する
例外が発生するとロックの解放が行われなくなり、デッドロックが発生する可能性がある。Java API [API 2006] には以下のように記載されている。 ReentrantLock は、最後にロックに成功したがまだロック解放していないスレッドにより「所有」される。ロックが別のスレッドに所有されていない場合、ロックを呼び出すスレッドが復帰してロックの取得に成功する。 つまり、解放されていないロックを他のスレッドが取得することはできないということである。例外が発生したら、プログラムは所有しているすべてのロックを解放しなければいけない。一方、メソッド同期およびブロック同期で使用されている固有ロックは、スレッドの異常終了のような例外発生時には自動的に解放される。 違反コード (チェック例外) 以下の違反コード例では、ReentrantLock を使用してリソースを保護しているが、ファイルの操作中
VNA05-J. 64ビット値の読み書きはアトミックに行う
Java言語仕様では、64ビットのlong型およびdouble型の値を、2つの32ビット値として扱うことが許されている。たとえば、64ビット値の書込み操作は、2つの独立した32ビット値の操作として実行される可能性がある。 Java言語仕様の17.7節「doubleとlongの非アトミックな扱い」には以下のように記されている。[JLS 2005] ... こうした振る舞いは実装依存である。つまり、Java仮想マシンはlong値やdouble値の書込みをアトミックな動作として実行するか、あるいは、二つの動作として実行するかを自由に決定することが許されている。プログラミング言語Javaメモリモデルでは、volatileでないlong値やdouble値への単一の書込みは、それぞれ32ビットずつの二つの書込みとして扱われる。結果的に、ある64ビット値の書込みの最初の32ビットと、他の書込みによる次の
THI00-J. Thread.run() メソッドを直接呼び出さない
スレッドの開始方法は誤解しやすい。スレッドで実行したい処理をコード上は正しく実行しているように見えても、実際には間違ったスレッドによって実行してしまっていることがある。Thread.start()メソッドを呼び出すと、Javaの実行環境は新たに開始したスレッドの上で、そのスレッドのrun()メソッドを実行する。Threadオブジェクトのrun()メソッドを直接呼び出すのは間違いである。直接呼び出した場合、run()メソッドのなかに書かれた処理は、新規に生成されたスレッドではなく、呼出し元のスレッドにより実行されてしまう。また、Threadオブジェクトが、Runnableオブジェクトから生成されるのではなく、run()メソッドをオーバーライドしていないThreadのサブクラスをインスタンス化することによって生成される場合、サブクラスのrun()メソッドはThread.run()メソッドを呼び
FUJITSU Network IPCOMの運用管理インタフェースの脆弱性に関する注意喚起
JPCERT-AT-2022-0013 JPCERT/CC 2022-05-09 I. 概要2022年5月9日、富士通株式会社はFUJITSU Network IPCOMの複数の脆弱性に関する情報を公開しました。本脆弱性を悪用されると遠隔の第三者によって任意のOSコマンドが実行されるなどの可能性があります。 富士通株式会社 IPCOM シリーズのコマンド操作端末／Webブラウザ端末とIPCOM間通信における脆弱性について https://www.fujitsu.com/jp/products/network/support/2022/ipcom-01/ 対象となる製品を利用している場合には富士通株式会社の情報を参照し、アップデートや回避策の適用を検討してください。 II. 対象対象となる製品は次のとおりです。 - IPCOM EX2シリーズ - IPCOM EXシリーズ - IPCOM V
Spring Frameworkの任意のコード実行の脆弱性（CVE-2022-22965）について
(1) 概要 2022年3月31日（現地時間）、VMwareはSpring Frameworkの任意のコード実行の脆弱性（CVE-2022-22965）に関する情報を公開しました。Spring Frameworkは、JavaのWebアプリ開発を行うためのフレームワークの1つです。本脆弱性が悪用された場合、遠隔の第三者が任意のコードを実行する可能性があります。 VMwareは、本脆弱性に関する報告を受け取った後、調査および修正対応中に脆弱性の詳細が公開されたと明らかにしています。JPCERT/CCは、本脆弱性を実証するとみられるコードや詳細を解説する記事がすでに複数公開されている状況を確認していますが、現時点では具体的な被害事例や報告は確認していません。 本脆弱性の影響を受ける環境には条件があり、今後も追加情報が公開される可能性があります。引き続き、VMwareなどからの情報に注視いただきな
IoTセキュリティチェックリスト
いわゆる IoT や IoT デバイスと呼ばれている、物理的な実体をもつ物の状態に関する情報を収集したり、収集された情報などをもとに物の状態を変える制御を行うための分散システムは近年、注目されており、今後も増加傾向が続くとされています。 そのような IoT デバイスは、常時ネットワークに接続されており、多数の同じIoTデバイスがネットワーク上に接続されているケースが多く、個々のIoTデバイスのセキュリティ管理の徹底が難しいことが多いと考えられます。また、IoT デバイスの中には、新機能の作り込みに注意を奪われるあまり、セキュリティ的な耐性に関する設計が忘れ去られているものが少なくありません。 利用者においても、IoTデバイスを使ってシステムを構築する際に、必要なセキュリティ的耐性を備えていることを確認した上で、システムを構成する製品を選定することが重要になります。不適切な製品を選べば、サイ
CSIRT マテリアル - JPCERT Coordination Center
CSIRT(シーサート: Computer Security Incident Response Team) とは、組織内の情報セキュリティ問題を専門に扱う、インシデント対応チームです。 近年の組織 (企業) の IT 利用の拡大に伴い、情報セキュリティ対策は組織にとって重要な問題となってきています。高度に複雑化し、かつインターネットを介して大容量のデータを瞬時に、しかも容易に世界中とやり取りできる IT システムの利用が一般的になったことで、単に「現場 = システム管理者」の頑張りだけで済む問題ではなくなってきています。例えば、情報システムがコンピューターウイルスに感染してしまったために、顧客の個人情報が世界中にばら撒かれてしまったといった事態を考えてみれば、情報セキュリティの問題が、もはやシステム管理者だけの問題ではなく、経営層が積極的に関与しなければならない問題であることは容易に想像
CSIRTガイド
CSIRT ガイド 一般社団法人 JPCERT コーディネーションセンター 2015 年 11 月 26 日 Japan Computer Emergency Response Team Coordination Center : Japan Computer Emergency Response Team Coordination Center DN : c=JP, st=Tokyo, l=Chiyoda-ku, email=office@jpcert.or.jp, o=Japan Computer Emergency Response Team Coordination Center, cn=Japan Computer Emergency Response Team Coordination Center : 2015.11.18 18:46:00 +09'00' はじめに 近年の組
ENV34-C. getenv() が返す文字列へのポインタを保存しない
ENV34-C. getenv() が返す文字列へのポインタを保存しない C 標準では getenv() の動作を次のように規定している。[ISO/IEC 9899:2011] getenv 関数は、一致する並び(environment list)の要素に結び付けられた文字列へのポインタを返す。このポインタが指す文字列をプログラムで変更してはならないが、引き続く getenv 関数の呼出しで書き換わることがある。 ゆえに、getenv() が返すポインタは保存すべきでない。このポインタは、2 回目以降に getenv() 関数を呼び出したときに上書きされたり、putenv() や setenv() の呼び出しによって環境変数の並びが変更された結果として無効になる可能性がある。getenv()が返すポインタを後で使用するために保存しておくと、ダングリングポインタとなったり、正しくないデータを
jpcert securecoding
プログラム開発業務に携わる全ての方々に向けて、脆弱性のない、安全なソフトウエア開発のためのセミナー、コーディングのルールやそのマテリアル、書籍に関する情報を紹介しています。 セミナー Android セキュアコーディングセミナー資料(英語版) Java セキュアコーディングセミナー資料 C/C++ セキュアコーディングセミナー資料 セキュアコーディングスタンダード CERT C セキュアコーディングスタンダード Java セキュアコーディングスタンダード CERT/Oracle 版 書籍 C/C++ セキュアコーディング C/C++ セキュアコーディング 第2版 CERT Cセキュアコーディングスタンダード Java セキュアコーディングスタンダード CERT/Oracle版 セキュアなソフトウエア開発を支援する資料 クロスサイトリクエストフォージェリ(CSRF)とその対策 Java アプ
FIO03-C. fopen() やファイル作成時の動作について勝手な想定をしない
FIO03-C. fopen() やファイル作成時の動作について勝手な想定をしない C の fopen() 関数を使用して、既存のファイルをオープンしたり新規ファイルを作成することができる。C11 バージョンの fopen() と fopen_s() では、モードフラグ x を提供している。このフラグは、オープンしようとしているファイルが存在するかどうかの判断に必要なメカニズムを提供する。このモードフラグを使用しないと、意図しないファイルへの上書きやアクセスを行う可能性がある。 違反コード (fopen()) 以下のコード例では、file_name が参照するファイルを書き込み用にオープンしている。プログラマの意図がファイルの新規作成であり、参照先のファイルがすでに存在している場合には、このコード例は違反コードである。 char *file_name; FILE *fp; /* file_
NUM00-J. 整数オーバーフローを検出あるいは防止する
Java の型において表現できる値の範囲は非対称(最小値の符号を反転させた値は、最大値より1大きい)であるため、単項マイナス演算子を最小値に適用した場合には整数オーバーフローが発生する。引数の絶対値を返すメソッド java.lang.math.abs() に int 型や long 型の最小値を与えた場合にも、整数オーバーフローが発生する。 数学的演算の結果が与えられた整数型で表現できない場合、Java のビルトイン演算子は、オーバーフローの発生を示すことなく演算結果をラップアラウンドさせる。この動作は、間違った計算結果や予期せぬ結果を招く可能性がある。たとえば、実システムにおいて、オーバーフローを適切に扱わなかったために compareTo メソッドの実装で問題となった例がある。compareTo メソッドの返り値は、ゼロであるか、符号が正負いづれかであるかにだけ意味があり、その絶対値に
ERR04-C. プログラムの適切な終了方法を選択する
ERR04-C. プログラムの適切な終了方法を選択する 範囲外エラーなど、いくつかのエラーはユーザの誤入力が原因で生じる場合がある。通常、対話型プログラムはこのようなエラーに対処するため、入力を拒否し、受け入れ可能な値の入力をユーザに促す。サーバはクライアントにエラーを示すことにより無効なユーザ入力を拒否し、同時にそれ例外のクライアントの有効な要求に対するサービスは続行する。揮発性ストレージに保存されたユーザデータの損失を防止することにより、少なくとも、メモリ残量低下(ディスクスペースの状態)などのリソースの不足に適切に対処するには、堅牢なプログラムを準備する必要がある。対話型プログラムを使用すると、ユーザはデータを代替メディアに保存でき、ネットワークサーバはスループットを落としたりサービス品質を低下させたりして対応できる。ただし、不確実な状態での実行を続行することによるリスクデータの破壊
Docker 等で使用する runc の権限昇格に関する脆弱性 (CVE-2019-5736) について
2019年2月12日 (現地時間) に Docker コンテナ 等で使用する runc に関する脆弱性 (CVE-2019-5736) が公開されました。本脆弱性を悪用して細工したコンテナをユーザが実行した場合、ホスト上の runc バイナリが意図せず上書きされます。結果として、コンテナが起動しているホスト上で root 権限でコマンドが実行できるようになります。 なお、本脆弱性の実証コードは 2019年2月12日現在公開されていませんが、報告者によると実証コードは 2019年2月18日 (現地時間) に公開予定とのことです。 本脆弱性を悪用するコンテナは次のようなケースが想定されています。 1) 攻撃者により改変されたイメージファイルを用いて作成されたコンテナ 2) 攻撃者が書き込み権限を取得している既存のコンテナ 本脆弱性は 2019年2月12日時点で runc のすべてのバージョンが
[pdf]技術メモ － 安全な Web ブラウザの使い方
JPCERT-ED-2008-0002 JPCERT/CC 技術メモ － 安全な Web ブラウザの使い方 初版：2008-11-04 (Ver. 1.0) 発行日：2008-11-04 (Ver. 1.0) 執筆者：石田 康明、戸田 洋三 本文書の掲載 URL：http://www.jpcert.or.jp/ed/2008/ed080002.pdf 本文章は Web ブラウザを利用して Web ページを閲覧する際に注意すべき事項をまとめたものです。 個々のソフトウェアの情報に関しては常に最新のドキュメントを参照して下さい。 - 2 - Copyright © 2008 JPCERT/CC All Rights Reserved. 目次 技術メモ － 安全な Web ブラウザの使い方......................................................
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java コーディングスタンダード CERT/Oracle 版
JPCERT コーディネーションセンター CSIRTマテリアル
JPCERT コーディネーションセンターJPCERT/CCについて