web-dev-qa-db-ja.com

Stuxnet S7-417ペイロードはファームウェアアップデートでしたか?

Stuxnet S7-417攻撃 について少し混乱しています。 StuxnetがPLCに対して中間者攻撃を実行し、PLCの入力イメージの値をスプーフィングしている間、バックグラウンドでさまざまなバルブを閉じ、元のロジックを実行して出力イメージに書き込んだと思います。 センサーとアクチュエーターからの入力画像と出力画像の関連付けを解除しました2 。ただし、PLCのロジックを変更しなかった場合(元のプログラムが実行され続けたため、変更されなかったと思います)、これがどのように機能するかはわかりませんが、ファームウェアの変更ではなかったと思います。 PLCのファームウェアの変更は非常に デジタル署名のために難しい であることを読みました。それでどこは実際に変更が加えられましたか?

[私は実際にPLCをいじったことがなく、PLCについて読んだだけです。そのため、これがどのように機能するかがわかりません]

2 www.langner.com/2010/11/417-attack-code-doing-the-man-in-the-middle-on-the-plc/

セクション2.3、 https://arxiv.org/pdf/1702.05241.pdf

2
Stuxnewt

Lagner によると:

感染直後、この初期のStuxnetバリアントのペイロードが完全に制御を引き継ぎます。正当な制御ロジックは、悪意のあるコードで許可されている場合にのみ実行されます。電気入力および出力信号から完全に切り離されます。攻撃コードは、攻撃がアクティブ化されていないときに、正当なコードがシグナルにアクセスできるようにします。実際、これは通常は自動的に実行されますが、感染中に無効にされたコントローラーのオペレーティングシステムの機能を複製しています。サイバーセキュリティのman-in-the-middleシナリオとして知られているシナリオでは、入力信号と出力信号は、「中央」に配置された攻撃コードによって、電気周辺機器から正当なプログラムロジックに渡されます。 [8ページ]

これは、ロジックフローがソフトウェアレベルで変更されたことを示唆しているようです。

【補足】元のラグナーの記事は移動されたようです。 PacketStormリンクは機能します。

1
schroeder

StuxnetがPLCのプログラミングソフトウェアを実行しているコンピュータを検索したと聞いたところ、プログラミングソフトウェアに「感染」して、PLC用に作成されたプログラムを変更し、PLCに挿入されたメモリカードにロードしました。 PLCのプログラムへの変更は、スピンアップして、オペレータに表示される出力を偽造することでした。

コンピュータやインターネットに接続されたことがないS7PLCと、Stuxnetの作成者はそれを知っていたに違いありません。

しかし、これは私がセキュリティミートアップで聞いたことだけです。

0
esrange