作为一名赛博保安,每当我们成功获取到系统的shell一定的访问权限后,首要任务之一就是迅速而准确地判断我们所处的环境。这不仅关系到接下来的渗透测试方向也决定了系统潜在攻击面。Let's go !
拿下shell的第一步就是确定自己究竟是在一台物理机上还是虚拟机中
在Linux系统中,我们可以利用
dmidecode
命令来获取硬件的详细信息,这个命令可以获取关于系统的硬件配置和制造商的信息。
# 命令
sudo dmidecode -t 1
sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
# 回显解读
## 物理机
PowerEdge R730
SYS-4028GR-TR
Dell Inc.
## 虚拟机
VMware Virtual Platform
Bochs
QEMU
virt-what
: 一个非常实用的脚本,它可以在大多数Linux发行版上运行,帮助我们确定当前环境是否为虚拟化环境。
# 命令
sudo virt-what
# 回显解读
## 在虚拟机,它可能返回 vmware,kvm,hyperv,xen 等,指示具体的虚拟化平台
kvm
xen
xen-hvm
hyperv
lxc
## 在物理机
在物理机上,这个命令可能不返回任何输出
在当前的IT环境下,云主机环境成为了越来越常见的目标。作为一名合格的保安,我们需要了解是否在云平台上,因为这会影响我们对于环境的理解和接下来可能的攻击路径。云环境通常提供了一些独有的服务和配置选项,这些都可能成为关键点。
-- 国内
# 阿里云
curl http://100.100.100.200/latest/meta-data/
# 腾讯云
curl http://metadata.tencentyun.com/meta-data/
# 华为云
curl http://169.254.169.254/openstack/latest/meta_data.json
# 京东云,跟AWS元数据地址一样,但是没有ami-id这个值
http://169.254.169.254/metadata/latest/
-- 国际
# AWS, 特点:提供AMI ID、实例类型等信息
curl http://169.254.169.254/latest/meta-data/
# Microsoft Azure云,需要在请求头中加入 Metadata:true
curl http://169.254.169.254/metadata/instance?api-version=2021-02-01 -H "Metadata:true"
# google云, 需要在请求头中加入 Metadata-Flavor: Google
curl http://metadata.google.internal/computeMetadata/v1/instance/id -H "Metadata-Flavor: Google"
在linux系统中,通过
dmidecode
命令同样可以判断我们是否身处于云主机之中
# 命令
sudo dmidecode -t 1
sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
# 回显
Alibaba Cloud ECS # 阿里云云主机
openStack Nova、Huawei Cloud # 华为云云主机
CVM # 腾讯云主机
一般物理机的根分区为/dev/sda2,而云主机的根分区为/dev/vda1
[root@unknown ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 95G 0 95G 0% /dev
tmpfs 95G 9.5M 95G 1% /dev/shm
tmpfs 95G 978M 94G 2% /run
tmpfs 95G 0 95G 0% /sys/fs/cgroup
/dev/vda1 40G 14G 25G 36% /
/dev/mapper/vg_oracle-lv_oracle 1.5T 1.3T 190G 87% /oracle
tmpfs 19G 0 19G 0% /run/user/0
# 华为云
[root@unknown ~]# cat /etc/motd
Welcome to Huawei Cloud Service
# 阿里云
[root@unknown ~]$ cat /etc/motd
Welcome to Alibaba Cloud Elastic Compute Service !
Docker环境具有特定的特征,容器通常具有较高的权限隔离和资源限制,但也可能因配置不当而暴露出安全漏洞
因为Docker使用cgroups来隔离容器的资源,显示的是系统中第一个进程,当你运行命令
cat /proc/1/cgroup
, 如果是docker环境,你通常会看到包含/docker/
或/docker-ce/
的路径。
# 命令
cat /proc/1/cgroup
# 回显
11:freezer:/docker/7b2b8b1d5c3d8baab6740ec339dxxxxxxxxxxxxxxa408b8a3989deaa4505d
10:cpu,cpuacct:/docker/7b2b8b1d5c3d8baab6740ec339d2678c28ab40f29106a408b8a3989deaa4505d
cgroups v2 环境
在cgroups v2中,路径的结构会有所简化,不再像v1那样按资源类型分组。你可以通过检查
/proc/self/cgroup
文件来看是否包含Docker容器的唯一标识符(容器ID)。
# 查看版本
cat /proc/mounts |grep cgroup
# cgroups v2 版本回显
cgroup /sys/fs/cgroup cgroup2 ro,nosuid,nodev,noexec,relatime 0 0
# 命令
cat /proc/self/cgroup
# 回显
0::/system.slice/docker-7b2b8b1d5c3d8baab6740ec339d2xxxxxxxx9106a408b8a3989deaa4505d.scope
Docker容器通常在其文件系统中具有一些特定的文件和目录,这可以作为识别的依据。
# 命令
ls -la / | grep docker
# 回显, 存在.dockerenv文件
drwxr-xr-x 1 root root 4096 Nov 21 14:01 .
drwxr-xr-x 1 root root 4096 Nov 21 14:01 ..
-rwxr-xr-x 1 root root 0 Nov 21 14:01 .dockerenv # 特征文件.dockerenv
非容器有输出,容器输出为空
# 云主机中
[root@unknown ~] fdisk -l
Disk /dev/vda: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 884D39AE-2030-4231-B486-520515A9ADD7
Device Start End Sectors Size Type
/dev/vda1 2048 4095 2048 1M BIOS boot
/dev/vda2 4096 125829086 125824991 60G Linux filesystem
# 容器
sh-4.4# fdisk -l # 没有输出
# 命令
mount | grep docker
# 回显:在Docker环境中,你可能会看到特定于Docker的挂载点,如/var/lib/docker
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/.......
检查系统中的磁盘使用情况,并过滤出与 Docker 相关的文件系统类型,如 overlay 或 aufs,这些都是 Docker 常用的存储驱动。在非 Docker 环境中,通常不会看到包含 "overlay" 或 "aufs" 的行。
# 命令
df -h | egrep '(overlay|aufs)'
# 回显
overlay 59G 15G 41G 27% /var/lib/docker/overlay2/...
# 命令,如果命令返回了容器的列表或具体信息,那么你就在Docker宿主机上,此命令在容器内部可能无法执行
curl --unix-socket /var/run/docker.sock http:/v1.24/containers/json
# 命令:如果这个文件存在,那么你很可能在一个有Docker守护进程活动的环境中,注意这只能在宿主机上检查到,不适用于容器内部。
ls /var/run/docker.sock
Kubernetes(K8s)是一个广泛使用的容器编排系统,它管理着大量的容器,识别是否在Kubernetes环境中可以帮助我们定位特定的安全措施和配置缺陷。
Kubernetes通常会为运行在其上的容器设置一些特定的环境变量,可以用来判断docker是否在k8s中
# 命令
env | grep KUBERNETES
# 回显特征,会看到 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT 等环境变量。
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
Kubernetes为每个Pod提供了自动挂载的服务账户凭据,这些凭据位于特定的文件系统路径。
ls /var/run/secrets/kubernetes.io/serviceaccount/
# 回显特征
如果该路径存在,并且包含如ca.crt, namespace, 和 token 这样的文件,这表明当前容器被配置在Kubernetes环境中。
# 如果能访问且返回相关信息,意味着你当前在一个Kubernetes环境中
curl https://kubernetes.default.svc
# 回显示例
{
"kind": "APIVersions",
"versions": [...],
"serverAddressByClientCIDRs": [...]
}
在Kubernetes节点上,可以通过检查相关的进程来判断环境。
# 命令
ps aux | grep kube
# 回显示例
root 1012 5.6 3.7 1422556 75344 ? Ssl 09:15 1:35 kubelet --kubeconfig=/var/lib/kubelet/kubeconfig ...
root 1024 0.2 1.1 18024 11200 ? Ssl 09:15 0:15 kube-proxy --config=/var/lib/kube-proxy/config.conf
Kubernetes Pod通常会挂载特定的卷,显示了Kubernetes节点上的特有挂载点
# 命令
mount | grep kube
# 回显
tmpfs on /var/lib/kubelet type tmpfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /var/lib/kubelet/pods/abc1234/volumes/kubernetes.io~secret/default-token-hjkl8 type ext4 (rw,relatime)
随着企业越来越多地采用云计算解决方案,云安全已成为网络安全领域中的重要组成部分,云环境提供了既复杂又丰富的攻击面,理解云环境的攻击面有助于咱们赛博保安更有效地发现更多潜在的安全漏洞。
云服务大量依赖于API来管理和控制资源。API的安全漏洞,如不当的认证、授权和数据加密,可以成为攻击者突破点。
关注点:
• 弱认证和授权机制:API密钥管理不善或权限过大。
• 信息泄露:API错误处理不当可能泄露关键信息。
错误的配置和管理是云环境中最常见的安全问题。自动化的部署和管理工具虽然提高了效率,但也可能由于配置错误而暴露重要资源。
关注点:
• 公开的存储桶和数据库:未正确设置访问权限的S3桶或SQL数据库。
• 错误的网络配置:错误配置的安全组和网络访问控制列表(ACLs)。
云服务通常依赖于多个下游供应商和服务。一个供应商的安全漏洞可以影响整个服务链。
关注点:
• 供应链攻击:通过第三方服务或软件供应链进行的攻击。
• 共享服务的脆弱性:共享组件的漏洞可能影响多个客户。
云安全攻防更多相关的知识点可以参考下图,官网有最新3.0版本:https://cloudsec.tencent.com/home/
欢迎关注不懂安全⬇️
如果你是一个长期主义者,欢迎加入我的知识星球,我们一起冲,一起学。每日都会更新,精细化运营,微信识别二维码付费即可加入,如不满意,72 小时内可在 App 内无条件自助退款。