Fortiegate 90D で HTTPS 用の証明書を入れ替える

Fortiegate 90D を学習用に買ったのですが、HTTPS通信ができないので、
オレオレ認証局で証明書を作成しました。その手順です。

Fortiegate にWebログインして システム　→　証明書の画面で
生成をクリックします。

証明書署名要求を生成するになりますので、
サブジェクト情報は、ホストIPにして、FortiegateのローカルIPを入力します。
（後で、ドメイン名でアクセスするためドメイン名に変更しました。
　DNSサーバは社内向けに構築したものを使用しています。）
その他の情報は適当に。

サブジェクトの別名もローカルIPを入れておきました。

次に認証局ですが。
私はCentOS7で
CentOS 7 で自己認証局とサーバー証明書を作成するメモ | ぶっちろぐ
を参考にして認証局を作成してありました。

Centos7上の任意のディレクトリで、sans_fortie.cnfを作成します。

subjectAltName=@subject_alt_names
[ subject_alt_names ]
DNS.1 = （ドメイン名を入れます）
IP.1 = 192.168.*.**** (Fortiegate のローカルIPアドレス）

次に
openssl ca -in server.csr -keyfile /etc/pki/CA/private/ca.key -cert /etc/pki/CA/ca.crt -out my_fortiegate.crt -config /etc/pki/tls/openssl-server.cnf -extfile sans_fortie.cnf

で作成されたmy_fortiegate.crt が完成した証明書です。これをダウンロードして

WebアクセスしたFortiegate の証明書のところで、ローカル証明書を選択してアップロードします。

Fortigateのシステム→設定で
HTTPS証明書をアップロードしたものに変更して、適用します。
これでできました。

※追記　ドメイン名でアクセスするために証明書を作り直すときに、証明書署名要求を二度使ったらエラーになりハマりました。
　　　　ご注意ください。エラーが出たら
SSL証明書の作成での failed to update database TXT_DB error number2 発生時の対処 | グーフー WordPressのためのLinuxノート

を参考にして下さい。

サブジェクトをドメイン名にして、別名にドメイン名とIPを設定したところ、
IPでもドメイン名でも無事アクセスできるようになりました。

Windows10 パスワードが違います 正しいパスワードでログインができない

今日、会社のPCにログインしようとしたら、できませんでした。
パスワードを勘違いしているのかとおもいましたが、違うようです。

別のノートPCに保存していたリモートデスクトップのパスワードも、ダメでしたので。

PIN入力　→　ダメ（合っているかわからない）
セーフモード　→　ダメ
最近のWindowsUpdate をアンインストール　→　ダメ

ここまでで、まっとうな道は途絶えたようでした。
あとは、リスクがある方法ばかり。

何とかデータをサルベージ、と考えていると。
管理ユーザを、もう一つ作ってあった。
そちらではログインできました！
そちらからフォルダをたどり、デスクトップ等にあるデータをとりあえず救出。
コピーが終了したら、今度はアカウントの変更で、パスワードを変更して・・・
ログインできました！

管理者権限雄ユーザは、複数作っておくとい良いという、教訓になりました。

コンピュータハイジャッキング を読んで

桃色テクノロジー様や、
様々な同系のサイトの情報に触れているのですが、
なかなか理解ができません。

そんな時に読むべき本の第一は
この「コンピュータハイジャッキング」です。

知りたいことが、知りたいだけ書いてあるのに、ページ数は多すぎない。

素晴らしい本でした。

※追記
アセンブラをただ勉強しても、エクスプロイトを理解するのは難しいです。
どうしてこんなやり方をしなければならないのか？この疑問に答えていただける本です。
エクスプロイトを学び、セキュリティ人材として成長するために必要な情報が載っています。

Centos7 DNS Bind named-chroot が動かない

DNSでハマりました。
→　dns の 自宅サーバCentos7 のサイトで、Centos6用のスクリプトを使用してしまいました。
これでハマりました。
BIND稼働中の　var/named/chroot/etc に　ある named.conf 　を見たところ、初期設定のままでした。
　　　※　→　var/name/chroot/etc/named.conf を削除してから、named-chroot を再起動したら治りました。

　※　CentOSで自宅サーバー構築　のサイトを参考にさせていた大いるのですが、
　　　BINDの説明のところにある、【CentOS6の場合】 のChroot化のスクリプトを実行してしまったのでした。
　　　完全に不注意でした。
　　　CetnOS7の場合は、スクリプトを実行してはいけません。
参考URL
mseeeen.msen.jp

おかげさまで、問題を特定することができました。
しかし、chroot 以下にマウントされているファイルを確認することを、
なかなか思いつかなかったのは、いただけませんね。

まだありました。systemctl status named-chroot を見たら　
「dumping master file: slaves/tmp-XXXXXXXX: open: permission denied」
と表示されています。
さてー。 /var/named/chroot/var/named/slaves のパーミッションを確認します。
なるほど。所有者がroot root になっていたので、chown named:named /var/named/chroot/var/slaves
を実行しました。
これで治りました。

ACCESSインポート時のデータ型変換の不具合に関する調査 MaxScanRows

ACCESSインポート時のデータ型変換の不具合に関する調査

　１　現象
ACCESSへ、CSVファイルからデータをインポートするときに、ある列の小数の値が、小数点以下を切り捨てられた状態で、整数としてインポートされた。テーブルの該当列のデータ型はテキストになっていた。
データのインポートは、ファイルAを最初に行った。
ACCESSのインポートウィザードを使用し、ウィザード上で新しいテーブルを自動作成して、インポート時のデータ型をテキストに指定してインポートを行った。
Aのインポートの結果は、小数点以下も保持され、問題はなかった。
ファイルBのインポートに当たっては、Aのインポート時に自動作成されたテーブルにインポートした。テーブルからAのデータを削除し、空になったテーブルにインポートウィザードを使用して、Bのデータをインポートした。データ型の指定（インポート定義）は行わなかった。該当列のデータの小数点以下が切り捨てられてインポートされた。また、インポート時のエラーは発生しなかった。
ファイルC、D、E　についても同様の作業を行い、インポートの結果は小数点以下が切り捨てられていた。

２　検証
インポート時に、データの上から～行目までのスキャンが行われ、データ型をACCESSが推測するという情報があったので、検証する。
　元のファイルをコピーし、データの上から順に、一つだけ小数の値を入れて、既存のからテーブルにインポートする。

元のファイル 小数点以下が切り捨てられる
　　　　一行目のデータを小数に変更したデータ 小数点以下が切り捨てられる
　　　　二行目のデータを小数に変更したデータ 小数の形が保持される
三行目のデータを小数に変更したデータ　　小数の形が保持される
　　　　四～二十五・・・・・・・・・・・・・ 小数の形が保持される
二十六行目のデータを小数に変更したデータ　小数点以下が切り捨てられる

結果としては、２～25行のデータに小数がない場合は、全て整数としてインポートされている。

　３　ACCESSの仕様と挙動　調査した結果を記述する
ACCESSの既定値では、インポートするファイルがテキスト（CSV）の場合、レジストリに設定されているMaxScanRowsの値を参照し、列のデータ型を推測する（詳細は後述）。
ACCESSのエンジンは、２～２５行（既定値）のデータを調べ、データ型を推測してインポートを行う。
１行目が使われないのは、ヘッダ行である可能性があるのでスキャンされないか、優先度が落とされていると推測される（推測）。
インポート定義、もしくはscheme.iniを使用しない場合は、列のデータ型は推測される。

　インポート先のテーブルの列のデータ型は、インポート元の列のデータ型と関連しない。
テーブルのデータ型と、インポートするファイルのデータ型は、比較されたり考慮されることはない。ただし、インポート不能であれば、インポート中にエラーを表示する。
　これはインポート時に、テーブルの列のデータ型は考慮されず、無関係ということである。

４　インポート時の動作のイメージ
以下にイメージを添付する。

５　対策　と　チェック
　　小数が整数にされたりしないために、データ型を推測させない必要がある。
　そのために、できることを挙げる。
対策
　　１　インポート定義、もしくはsheme.iniを使用する。
　　２　データ型を推測させないように、レジストリを変更する。
　　３　データ型推測時に、全行をスキャンするようにレジストリを変更する。
チェック
　　４　計算可能なデータであれば、元のファイル、インポート後、各々合計を出して照合する。
　　５　必要があれば、元のファイルと、インポート後のデータをすべて照合する。
　　６　データ型が推測されてしまうものだということを、頭に止めておく。

対策１，２，３については、１のインポート定義を推奨する。scheme.iniについてはここでは記述しない(外部アプリからACCESSにインポートする場合に使用する)。
２，３のレジストリの変更も可能であるが、すべてのOFFICEアプリケーションに影響が出るために、あまり推奨はしない（試してみる価値はある）。

チェック　４，５については、時間が許す範囲となる。
　特に５については、都度VBAを組む必要があるが、必要があれば対応する。

　６　レジストリの詳細
　以下のレジストリの値は全て
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\Text下にあるものをいう。
１：レジストリのMaxScanRwosの値はデフォルトで２５になっている。これを０にすることですべての行がスキャンされる。ここでスキャンされたデータの型が混じっている場合は、次の２の値を参照して動作が決定する。混じっていない場合は２５行めまでの型に確定する。

２：レジストリのImportMixedTypes の値が「Majority Type」であった場合、多数決によって決まる（実際には、少数と整数があった場合には、表現力の大きい小数になる）。この値が設定されていない場合は、Majority Type になる。

　レジストリの変更による対策を行う場合には、MaxScanRows=0、ImportMixtedTypes=Text　に変更する。
　変更後の挙動は、全行をスキャンし、データ型が混じっていればテキスト型でインポートされる。
　CSVではなくXLS等のエクセルファイルをインポートする場合は、レジストリ内のTypeGuessRows と、ImportMixedTypes の値が参照される。TypeGuessRowsがデータ型を推測するためのスキャン行数となっている。こちらの既定値は８で、デフォルトでは８行しかスキャンせずに推測されてしまう。

OFFICEのバージョン、OSの環境によってレジストリの場所は異なるが、Access Connectivity Engine　を検索することで発見できる。

２００７と２０１０以降が混在している場合は、レジストリも複数の場所にAccess Connectivity Engineがあるので注意すること。

以上がレジストリの変更による対応の詳細だが、手順、実際の挙動のチェックなどが雑然としており、あまりお勧めはしないが、一度設定がうまくいけば、スムーズに業務が運べるかもしれない。

レジストリの画面を添付しておく。

７　参考URL

調査したURLを列挙しておく

https://blog.esrij.com/2010/06/18/schemaini-301f/
https://dobon.net/vb/bbs/log3-43/26012.html
https://social.msdn.microsoft.com/Forums/ja-JP/e4c45cae-bf09-4f8b-8f28-e9ef3c5ca929/29305234501239865328653151239120316251041237512383653156533165?forum=vsgeneralja
https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_access-mso_winother-mso_2007/regedit%E3%82%A8%E3%83%87%E3%82%A3%E3%83%83/98fda91e-7343-441a-ac89-155ae4462c4d?messageId=4e05b3a2-86f7-41c6-a52e-7e0368e30700
https://support.microsoft.com/ja-jp/help/968580
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1313045738

VB.NET Office360 Excel エラー 外部参照

PCが壊れたので復旧しました。
すると、今まで動いていたVB.NET のアプリでエラー。

「インターフェイス型 'Microsoft.Office.Interop.Excel.＊＊＊＊ にキャストできません」

というのが出るが、他の環境でチェックすると出ない。

１：　エラーが出る環境はWindows10をクリーンインストールしている。
　　　また、Office360のみをインストールしている。
２: エラーが出ない環境は、Windows7からWindows10へアップデートしている。
　　　また、Office2007が最初にインストールされ、その後Office360がインストールされている。

そのような違いで、エラーが出てているようですが。

エラーの出るエクセルをよくよく調べてみると、開くときに、「このブックには更新できないリンクが １つ以上含まれています」と表示されます。
・・・他のブック内のセルを関数が参照していて、
そのブックにパスワードがかかっている。

これだ！
ということで、参照先のブックを開いてから、目的のブックを開いたらエラーが消えました。

うーん、環境によってはこのエラーが出ないということですね。
.net のアプリケーションからは外部参照しているシートもセルも使っていないので、
バージョンによってはエラーが出ないのでしょうか？

書式指定文字列 脆弱性 サイバー攻撃

ポイントは、%2$n が二つ目の引数で指定した、アドレスに書き込むというところ。

 int secert = 'secert';
printf(%100c$2$n,'a',&secert);

これは ポインタ変数 secret のアドレスに100を書き込んでいる。

それでは攻撃の場合はどうなっているかというと、

./overwrite2 $(python -c 'print "\xb4\xec\xff\xbf" + "%96C%6$n")

6番目の引数のあるはずのメモリの場所にある値を、アドレスとして解釈して書き込む。

まず、アドレスの文字列がメモリのどこかに書き込まれる。
そのアドレスは、調査の結果６番目の引数の場所である。
なので、

１：　/xb4\xec\xff\xbf がメモリのどこかに書き込まれる。そのアドレスは、調査の結果６番目の引数の場所である。
２：　%96Cで　出力した文字数は合計１００になる。
３：　%6$nで六番目の引数のメモリの値をアドレスとして解釈し、そこに１００が書き込まれる。（１：のアドレスに100が書き込まれる）