最新のデータベースには、あらゆる種類のデータが保存されています。些細なものから非常に敏感なものまで。私たちがよく行くレストラン、地図の場所、身分証明書（社会保障番号、住所、医療記録、銀行情報など）、およびその間のすべてのものは、データベースのどこかに保存されている可能性があります。データがそれほど価値があるのも不思議ではありません。
データベース技術は驚異的なペースで進歩しています。革新、進歩、完全性、および機能強化は、インテリジェントで献身的なエンジニア、開発者、およびそれらのベンダーをサポートする堅牢なコミュニティの努力の直接の結果として、最前線にあります。
しかし、コインには別の側面があります。残念ながら、このデータ駆動型の世界では、マルウェア、ウイルス、エクスプロイトの形で、かつてないほど大規模に共存しています。
データは、運用のその側の関係者にとっても貴重です。しかし、さまざまな理由で。それらのいずれも、権力、恐喝、金銭的利益とアクセス、制御、楽しみ、いたずら、悪意、盗難、復讐などである可能性がありますが、これらに限定されません。リストは無限です。
残念ながら、私たちはセキュリティの考え方で運営する必要があります。この考え方がなければ、システムはこれらのタイプの攻撃に対して脆弱なままになります。 PostgreSQLは、他の形式のソフトウェアと同様に、侵害、誤用、盗難、不正アクセス/制御の影響を受けやすくなっています。
では、PostgreSQLのインストールに対するリスクの数を軽減するためにどのような対策を講じることができますか？
既知の脅威が何であるかについての認識を促進することは、他のどの脅威よりも開始するのに適した場所であると強く感じています。知識は力であり、私たちは自由に利用できるすべてのものを使用する必要があります。さらに、これらのPostgreSQLインスタンスのセキュリティを強化し、そこに存在するデータを保護するために、私たちが気付いていないことをどのように監視できますか？
私は最近、PostgreSQL環境を対象に、既知のセキュリティの「懸念」と「脅威」を検索しました。私の検索には、2018年の第1四半期内の最近のレポート、記事、ブログ投稿が含まれていました。その特定の時間枠に加えて、洗練されていないものの、今日でも実行可能な脅威である、よく知られた長年の懸念（つまり、SQLインジェクション）を調査しました。または「最近発見された」として振り回された '。
写真撮影会
データベース攻撃の詳細[パートIII]：スカーレットヨハンソンの写真が私のPostgresデータベースにMoneroのマイニングを開始させた理由
この巧妙なマルウェア攻撃の言葉は、私の客観的な検索結果から最も多くの「ヒット」を返しました。
いくつかのすばらしいブログ投稿の1つと、そのコンテンツの概要をご覧ください。このセクションの最後に追加のブログ投稿も含めたので、必ずそれらにアクセスして、この侵入の詳細を確認してください。
観察
Impervaからの情報によると、ハニーポットデータベース（StickyDB）がPostgreSQLサーバーの1つでマルウェア攻撃を発見したとのことです。ハニーポットネットは、Impervaがシステムに名前を付けているように、攻撃者をだましてデータベースを攻撃させるように設計されているため、攻撃者（Imperva）はそれについて学習し、より安全になります。この特定の例では、ペイロードは、スカーレット・ヨハンソンの写真に埋め込まれた、Moneroを暗号化するマルウェアです。
ペイロードは、lo_export関数を使用して実行時にディスクにダンプされます。しかし、明らかに、これは、lo_exportがpg_procのエントリであるのに対し、通常は直接呼び出し（lo_export）であるために発生します。
非常に明確にするために、ここのブログ投稿から直接興味深い詳細（引用記事を参照）
これで、攻撃者は1つの単純な関数fun6440002537を使用してローカルシステムコマンドを実行できるようになります。このSQL関数は、C言語関数「sys_eval」を呼び出すためのラッパーです。これは「tmp406001440」（sqlmapprojectに基づくバイナリ）の小さなエクスポート関数であり、基本的にSQLクライアントからシェルコマンドを呼び出すためのプロキシとして機能します。
>では、攻撃の次のステップは何でしょうか？いくつかの偵察。そのため、lshw -c videoを実行してGPUの詳細を取得することから始め、CPUの詳細を取得するために/ proc / cpuinfoを続けました（図3-4）。これは最初は奇妙に感じますが、最終目標がお気に入りの暗号通貨をさらにマイニングすることである場合、それは完全に理にかなっていますよね？
データベースアクセスとリモートでコードを実行する機能の組み合わせにより、すべて「レーダーの下を飛んでいる間」 監視ソリューションの中で、侵入者はスカーレット・ヨハンソンの写真を介してペイロードをダウンロードします。
（注：写真はホストされている場所から削除されました。言及についてはリンク記事を参照してください。）
レポートによると、ペイロードはバイナリ形式です。そのバイナリコードは、アップロード中に実際の写真を渡すために写真に追加され、表示可能な写真を可能にしました。
ダウンロードしたファイルのアクセス許可のためにwget、ddを利用し、chmodを実行するSQLについては、投稿の図6を参照してください。そのダウンロードされたファイルは、Moneroの実際のマイニングを担当する別の実行可能ファイルを作成します。もちろん、このような悪質な作業をすべて行った後は、ハウスキーピングとクリーンアップが必要です。
図7は、実行中のSQLを示しています。
Impervaは、クロージングセクションで潜在的な違反領域のリストを監視することをお勧めします：
- lo_exportへの直接PostgreSQL呼び出し、またはpg_procのエントリを介した間接呼び出しに注意してください。
- C言語のバイナリを呼び出すPostgreSQL関数に注意してください。
- ファイアウォールを使用して、データベースからインターネットへの発信ネットワークトラフィックをブロックします。
- データベースにパブリックIPアドレスが割り当てられていないことを確認してください。そうである場合は、それと対話するホスト（アプリケーションサーバーまたはDBAが所有するクライアント）のみにアクセスを制限します。
Impervaは、攻撃者が脆弱なPostgreSQLサーバーを見つける可能性がある方法の詳細とともに、さまざまなウイルス対策テストも実行しました。簡潔にするためにここには含めませんでしたが、調査結果の詳細については記事を参照してください。
推奨読書
- Impervaには、パート3（ここで説明する記事）に付随する2つの先行記事があります。これらは、先ほど説明したようにPostgreSQLをあまりターゲットにしていませんが、非常に有益な読み物です。
- パート1
- パート2
- ScarlettJohanssonPostgreSQLマルウェア攻撃
- ハッカーは、ScarlettJohannsson画像にCoinminerが隠されたPostgreSQLDBを標的にします
- エクスプロイトに関するハッカーニューススレッド。
CVEの詳細、レポート、および脆弱性
ベンダーごとに最新のセキュリティ脅威を投稿しているこのサイトにアクセスし、2018年の第1四半期に4つの脆弱性を発見しました。PostgreSQLのセキュリティ情報ページにもそれらがリストされているので、そのリソースを参照してください。
それらのほとんどすべてが対処されていますが、それらについて知らなかったかもしれない読者に気づきをもたらすために、これらをこの投稿に含めることが重要だと感じました。それらすべてから学ぶことができると思います。特に、発見された脆弱性のさまざまな方法で。
それらは公開された日付の順に以下にリストされています：
私。 CVE-2018-1052公開日2018-02-09：更新日2018年3月10日
概要：
テーブルのパーティション分割におけるメモリ開示の脆弱性は、10.2より前のPostgreSQL 10.xで発見され、認証された攻撃者がパーティション化されたテーブルへの専用の挿入を介してサーバーメモリの任意のバイトを読み取ることができます。
この脆弱性は、ここで確認されたPostgreSQL10.2のリリースで修正されました。修正された古い9.xバージョンも記載されているので、そのリンクにアクセスして特定のバージョンを確認してください。
II。 CVE-2018-1053公開日2018-02-09：更新日2018年3月15日
概要：
9.3.21より前のPostgreSQL9.3.x、9.4.16より前の9.4.x、9.5.11より前の9.5.x、9.6.7より前の9.6.x、および10.2より前の10.xでは、pg_upgradeは出力を含むファイルを現在の作業ディレクトリに作成します。ユーザーがpg_upgradeを呼び出したときに有効だったumaskの下の`pg_dumpall-g`であり、他の一時ファイルに通常使用される0077の下ではありません。これにより、認証された攻撃者が1つのファイルを読み取ったり変更したりできる可能性があります。このファイルには、暗号化されたデータベースパスワードまたは暗号化されていないデータベースパスワードが含まれている可能性があります。ディレクトリモードが攻撃者が現在の作業ディレクトリを検索するのをブロックする場合、または一般的なumaskが攻撃者がファイルを開くのをブロックする場合、攻撃は実行不可能です。
以前のCVE-2018-1052と同様に、PostgreSQL10.2は脆弱性のこの部分を修正しました：
「pg_upgrade」で作成されたすべての一時ファイルが誰でも読み取れないことを確認してください
古いバージョンのPostgreSQLの多くは、この脆弱性の影響を受けます。リストされているすべてのバージョンについては、必ず提供されているリンクにアクセスしてください。
III。 CVE-2017-14798公開日2018-03-01：更新日2018年3月26日
概要：
PostgreSQL initスクリプトの競合状態は、攻撃者がPostgreSQLアカウントにアクセスして、権限をrootにエスカレートするために使用される可能性があります。
リンクページでPostgreSQLバージョン10について言及されている場所は見つかりませんでしたが、古いバージョンが多数記載されているため、古いバージョンを実行している場合は、そのリンクにアクセスしてください。
Suse Linux Enterprise Serverのユーザーは、この脆弱性がバージョン9.4のinitスクリプトで修正された2つのリンクされた記事に興味があるかもしれません。
IV。 CVE-2018-1058公開日2018-03-02：更新日2018年3月22日
概要：
PostgreSQLがユーザーに他のユーザーのクエリの動作を変更することを許可する方法に欠陥が見つかりました。ユーザーアカウントを持つ攻撃者は、この欠陥を利用して、データベース内のスーパーユーザーの権限でコードを実行する可能性があります。バージョン9.3から10が影響を受けます。
このアップデートリリースでは、すべてのユーザーがアクセスする必要のある興味深いリンクされたドキュメントでこの脆弱性について言及しています。
この記事は、A Guide to CVE-2018-1058：Protect Your Search Pathというタイトルのコミュニティからの素晴らしいガイドを提供します。このガイドには、脆弱性、リスク、およびそれに対抗するためのベストプラクティスに関する膨大な量の情報が含まれています。
要約するために最善を尽くしますが、あなた自身の利益、理解、および理解のためにガイドにアクセスしてください。
概要：
PostgreSQLバージョン7.3の登場により、スキーマがエコシステムに導入されました。この機能拡張により、ユーザーは別々の名前名でオブジェクトを作成できます。デフォルトでは、ユーザーがデータベースを作成すると、PostgreSQLはすべての新しいオブジェクトが作成されるパブリックスキーマも作成します。データベースに接続できるユーザーは、そのデータベースのパブリックスキーマにオブジェクトを作成することもできます。
ガイドから直接このセクションは非常に重要です（引用記事を参照）：
スキーマを使用すると、ユーザーはオブジェクトに名前空間を付けることができるため、同じ名前のオブジェクトを同じデータベース内の異なるスキーマに存在させることができます。異なるスキーマに同じ名前のオブジェクトがあり、特定のスキーマ/オブジェクトのペアが指定されていない場合（つまり、schema.object）、PostgreSQLはsearch_path設定に基づいて使用するオブジェクトを決定します。 search_path設定は、オブジェクトを検索するときにスキーマが検索される順序を指定します。 search_pathのデフォルト値は$user、publicです。ここで、$ userは、接続されているユーザーの名前を指します（これは、SELECT SESSION_USER;を実行することで判別できます）。
もう1つの重要なポイントはここにあります：
CVE-2018-1058で説明されている問題は、デフォルトの「パブリック」スキーマと、PostgreSQLがsearch_path設定をどのように使用するかを中心にしています。異なるスキーマで同じ名前のオブジェクトを作成する機能と、PostgreSQLがスキーマ内のオブジェクトを検索する方法を組み合わせることで、ユーザーが他のユーザーのクエリの動作を変更する機会が得られます。
以下は、この脆弱性のリスクを軽減するために規定されているように、ガイドがこれらのプラクティスの適用を推奨する概要リストです。
- ユーザーがパブリックスキーマに新しいオブジェクトを作成することを許可しない
- データベースユーザーのデフォルトのsearch_pathを設定します
- PostgreSQL構成ファイル（postgresql.conf）でデフォルトのsearch_pathを設定します
SQLインジェクション
'セキュリティをテーマにした 'SQLブログの投稿または記事は、SQLインジェクションについて言及せずにそれ自体にラベルを付けることはできません。この攻撃方法は想像の域を超えたものではありませんが、ブロック上の新しい子供 '、それを含める必要があります。
SQLインジェクションは常に脅威であり、Webアプリケーションの分野ではおそらくさらに脅威です。 PostgreSQLを含むすべてのSQLデータベースは潜在的に脆弱です。
SQLインジェクション（SQLiとも呼ばれます）に関する深い知識ベースはありませんが、簡単な要約、PostgreSQLサーバーにどのように影響する可能性があるか、そして最終的には獲物に落ちるリスクを減らす方法を提供するために最善を尽くしますそれに。
このセクションの最後にあるリンクを参照してください。これらのリンクには、私が十分に伝えることができない分野の豊富な情報、説明、および例が含まれています。
残念ながら、いくつかのタイプのSQLインジェクションが存在し、それらはすべて、データベースで実行するためにクエリに不快なSQLを挿入するという共通の目標を共有しています。おそらく、開発者が本来意図も設計もしていません。
不衛生なユーザー入力、不十分に設計された、または存在しないタイプチェック（別名検証）、およびエスケープされていないユーザー入力はすべて、攻撃者になる可能性のあるドアを大きく開いたままにする可能性があります。多くのWebプログラミングAPIは、SQLiに対するある程度の保護を提供します。たとえば、ORM（Object Relational Mapper）、パラメーター化されたクエリ、型チェックなどです。ただし、実装することにより、あらゆる努力を払い、SQLインジェクションの主要なシナリオを減らすのは開発者の責任です。自由に使えるそれらの迂回とメカニズム。
OWASPSQLインジェクション防止チートシートからのSQLインジェクションのリスクを減らすための注目すべき提案があります。実際の使用例の詳細については、必ずアクセスしてください（引用記事を参照）。
一次防御：
- オプション1：プリペアドステートメントの使用（パラメーター化されたクエリを使用）
- オプション2：ストアドプロシージャの使用
- オプション3：ホワイトリスト入力の検証
- オプション4：ユーザーが入力したすべての入力をエスケープする
追加の防御：
- また：最小特権の強制
- また、二次防御としてホワイトリスト入力検証を実行する
推奨読書：
さらなる研究と認識のために、たくさんの情報を含む追加の記事を含めました：
- SQLインジェクションとは何ですか？この古くて良いものは、Webアプリケーションを傷つける可能性があります
- SQLインジェクション（ウィキペディア）
- SQLインジェクション（CLOUDFLARE）
- SQLインジェクション（w3schools.com）
- SQLインジェクション防止に関するチートシート
- SQLインジェクションのテスト
- SQLインジェクションの脆弱性とその防止方法
- SQLインジェクションに関するチートシート
Postgresの役割の権限
「私たちは私たち自身の最悪の敵です」ということわざがあります。 。"
PostgreSQL環境内での作業に間違いなく適用できます。怠慢、誤解、または勤勉さの欠如は、意図的に開始されたものと同じくらい、攻撃や不正使用の機会です。
おそらくそれ以上に、問題のある当事者が利用するためのより簡単なアクセス、ルート、およびチャネルを不注意に許可してしまいます。
時々再評価または再評価が必要な分野について言及します。
不当または無関係な役割の特権。
- スーパーユーザー
- クリートロール
- CREATEDB
- 許可
この特権の融合は間違いなく一見の価値があります。 SUPERUSERとCREATROLEは非常に強力なコマンドであり、アナリストや開発者よりもDBAの手に渡ったほうがよいと思いませんか？
ロールには本当にCREATEDB属性が必要ですか？ GRANTはどうですか？その属性は、悪用される可能性があります。
環境でこれらの属性の役割を許可する前に、すべてのオプションを慎重に検討してください。
戦略、ベストプラクティス、強化
以下は、検索結果の「1年前」（この記事の執筆時点）に戻ってきた便利なブログ投稿、記事、チェックリスト、およびガイドのリストです。それらは重要な順序でリストされておらず、それぞれが注目に値する提案を提供します。
- まれな攻撃ベクトルからPostgresサーバーを保護する簡単な方法：ScarlettJohanssonの不正な写真
- PostgreSQLデータベースの保護を支援する
- 頭を悩ませないでください...セキュリティを確保するためにPostgreSQLデータベースを強化してください
- PostgreSQLデータベースを保護する方法-10のヒント
- 外部攻撃からPostgreSQLを保護する
- PostgreSQLの権限とセキュリティ-パブリックスキーマのロックダウン
結論
このブログでは、世界中のPostgreSQL管理者に関係するセキュリティの問題について説明しました。これらの問題には、すべてのセキュリティインシデントの聖杯であるSQLインジェクション、処理の基本的なアプローチのスリップアップが含まれます。インフラストラクチャ全体の権限を適切に強化できないなどのデータを安全に保護します。また、見落とされる可能性のあるあまり知られていないセキュリティの問題もあります。データのセキュリティに関しては、Impervaなどの信頼できる関係者からアドバイスを受けて適用することが重要です。これにより、基本的な攻撃と0日（まだ行われていないエクスプロイト）の両方から身を守る方法が提供されます。評判の良いアドバイスは、データベースとインフラストラクチャ全体にとって良い未来を意味するためです。
実行する必要のあるセキュリティ対策は、防御したい脆弱性に大きく依存することに注意してください。ただし、一般的に、SQLインジェクションを防御するために必要なすべての防御策を知っており、適切に使用します。特権、および脆弱性に関連するリスクレベルを常に削減しようとすることが重要です。 PostgreSQLのセキュリティスペースで何が起こっているかを常に最新の状態に保つことで、私たちも不思議に思うでしょう。攻撃者が何を求めているかを知っている場合にのみ、サーバー（およびその結果としてデータ）を十分に防御できます。
PostgreSQLインストールのセキュリティまたはパフォーマンスの姿勢を改善するためのより多くのベストプラクティスを探している場合は、ClusterControlを参照してください。ツールは世界中の一流のデータベース専門家によって開発されているため、データベースをすぐに歌わせることができます。この製品には30日間の無料試用版も付属しているため、ClusterControlがビジネスに提供できるすべての機能をお見逃しなく、今すぐ試してみてください。
PostgreSQLデータベースインスタンスを保護する方法の詳細については、Severeninesブログを参照してアドバイスを求めてください。PostgreSQLのセキュリティ監査を自動化する方法を学ぶことは、確かに正しい方向への一歩となるでしょう。 Twitter、LinkedInでフォローし、RSSフィードを購読して最新情報を入手してください。次回、お会いしましょう。