0%

vmware安装macOS虚拟机

1.在macOS物理机上能够使用vmware fusion/virtualbox或者vagrant搭建macOS虚拟机，说起来倒是很简单：用vmware fusion应该不会有什么坑，用virtualbox也有人把要踩的坑总结好了：Run macOS 10.15 Catalina (and other versions) in VirtualBox on macOS。用vagrant参考偏执的iOS逆向研究员：收集全版本的macOS iOS+越狱+内核调试这篇文章即可。比较麻烦的是如果用vmware fusion/virtualbox的话sb苹果是不提供完整系统镜像的，得自己找；用vagrant的话又因为大家都知道的原因你得有一个很稳的梯子下那十几个G的镜像文件。
2.在linux/windows物理机上因为版权的原因默认是没有合法的手段让你装macOS虚拟机的，最最最常见的方法就是用unlocker patch掉vmware workstation pro然后安装macOS，当然镜像还是得自己找。推荐使用这个branch的unlocker：https://github.com/BDisp/unlocker/releases，当前最新的版本是3.0.3。这个branch的unlocker据我测试应该是能直接用不会有什么坑。不过这里还是要注意一个问题，unlocker中的gettools.exe会去下载com.vmware.fusion.zip.tar并且下载速度很慢，我们可以先去把这个包下好，下载的地址是到http://softwareupdate.vmware.com/cds/vmw-desktop/fusion找你用的vmware workstation pro对应的版本即可。更改gettool.py的代码，把下载com.vmware.fusion.zip.tar的代码注释掉，用pyinstaller重新打包一个gettools.exe。以管理员权限运行win-install.cmd，在time.sleep(20)的时候把下载好的com.vmware.fusion.zip.tar拷贝进tools目录即可。

iOS越狱降级

./futurerestore -t xxx.shsh2 –latest-sep –latest-baseband xxxx.ipsw

1.学http://www.newosxbook.com/index.php上的三本书，建议海淘。国内那些写macOS/iOS的书我翻了几本得出的结论是都不用买。当然就这么看肯定是非常枯燥的，所以我建议有时间就翻翻，一次也不用看太多。

2.学习各种出现的macOS/iOS漏洞，主要是project zero的。

3.从推特或者关注的大牛那里获取一些他们的研究成果然后学习。

Speaking of dll hijacking, many people may think it is very useless. However, I noticed researchers disclosured some special dll hijacking scenarios that can lead to LPE and even RCE. Some times ago, I accidentally discovered vulnerability in dll loading mechanism in cisco webex teams that can lead to LPE, and as far as I know, no one has ever mentioned this kind of dll hijacking scenario before.

Cisco Webex Teams Client for Windows DLL Hijacking Vulnerability

I found cisco webex teams was installed to “C:\Users\username\AppData\Local\CiscoSpark” and I decided to take a look at current_log.txt。

It seems that several dlls were not loaded successfully the first time. This is very strange, CiscoCollabHost.exe wants to load these dlls from “dependencies”, error code 126 means “The specified module could not be found”, but “dependencies” and CiscoCollabHost.exe are in the same directory, and in “dependencies” these dlls exist. So something must be wrong…

Until I found the corresponding code in spark-windows-media.dll in IDA, and it took some time before I realized what was going on.

In AddDllDirectory documentation says that the parameter should be “An absolute path to the directory to add to the search path”. However, Microsoft did not say you cannot use relative path, nor did they say what would happen if you use it. What’s even more interesting is that if you use a relative path like L”\\dependencies” like here, in fact windows will treat it as “C:\dependencies”!

We can write code like:

Compile poc.exe, then put poc.exe into C:\example\poc.exe, if C:\dependencies\test.dll and C:\example\dependencies\test.dll both exist, poc.exe will load C:\dependencies\test.dll.

So it is very simple to exploit this vulnerability here, just put wmeclient.dll into C:\dependencies\wmeclient.dll. After the victim opens cisco webex teams and successfully logs in, this wmeclient.dll will be loaded and executed by cisco webex teams. Directly writing PE files to C:\ requires administrator rights, but creating a directory in C:\ and then writing PE files to that directory does not require administrator rights.

Consider another situation where the exe and the dll are not in the same path. If C:\abc\def\poc.exe wants to load C:\abc\lib\test.dll, can we write code like LoadLibraryW(L”.. \\lib\\test.dll”)? This will also lead to vulnerability, because windows will treat “..\\lib\\test.dll” directly as “C:\lib\test.dll”. I found such code in another renowned manufacturer’s product. I reported this to them and I am still waiting for reply. I will add more details 90 days after my report or a security bulletin available.

Not only the path related to load dll handled in this way by windows, functions like CreateProcess may also cause vulnerability if given a relative path. Because some products have both windows and linux versions, developers may mix the code of these two platforms. For example, if you write code like this:

Windows will add C:\ and .exe, which means put whoami.exe into C:\bin\whoami.exe and it will be executed. I found codes similar to this in cisco DCNM. They told me that this problem only exists on server 2019 and server 2019 is not an environment supported by DCNM by default, so no CVE for this:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv65124

I also reported my findings to MSRC, but MSRC said this is the default behavior. I am not surprised, if the default behavior is to let developers write vulnerable code, that’s fine.

I am sharing my discovery because I haven’t seen anyone mention these and similar vulnerabilities may exist in other products. At the same time, I want to remind developers should make sure that all your dlls are loaded correctly. I want to thank cisco PSIRT although they do not have a bug bounty program but I am still willing to report vulnerability to them. They are very professional and will give you feedback at every stage(received-confirmed-coordinate disclosure time-final public disclosure).

timeline:

2020-06-30: vulnerability found and reported to cisco PSIRT

2020-07-01: cisco PSIRT assigned PSIRT-0447917012

2020-07-10: cisco PSIRT was not able to reproduce this, more details provided

2020-07-15: cisco PSIRT confirmed this vulnerability

2020-08-05: cisco PSIRT informed that the vulnerability will be fixed in the new version released on August 27, and security bulletin will be released on September 2

2020-08-19: cisco PSIRT hoped to postpone the release of security bulletin to October 7 to ensure that all users can upgrade to the unaffected version before public disclosure

2020-10-07: cisco PSIRT released security bulletin

2020-01-06：发现爱奇艺客户端某个需要用户发生交互的场景可以导致远程代码执行，报告到爱奇艺SRC
2020-01-08：发现报告被关闭，留言反馈
2020-01-09：发送邮件到[email protected]
2020-01-09：爱奇艺SRC负责人表示审核人员看错了，让我重复提交一次
2020-01-10：重新提交了漏洞
2020-02-21：通过QQ向爱奇艺SRC运营反馈这个漏洞不应该被评为中危应该是高危，对方表示会讨论
2020-03-06：再次通过QQ向爱奇艺SRC运营询问，对方表示还没有上班
2020-04-01：再次通过QQ向爱奇艺SRC运营询问，对方表示这周之内答复
2020-04-03：和爱奇艺SRC运营讨论交流，对他们的工作提出了批评和质疑，对方补发了金币和奖励

1.市值上百亿美元的美股上市公司审核漏洞为何如此随意？一个能影响爱奇艺windows客户端至少几百万用户的高危漏洞能被审核人员看错直接忽略？我在漏洞下面留言没有回应，直到我发邮件询问。爱奇艺SRC的运营流程和审核人员工作的专业和态度为什么有这么严重的问题？

2.为什么我联系爱奇艺SRC运营详细说明了我认为为什么应该评高危而不是中危之后，仍然一直不给我答复，期间我不得不两次询问？

3.我和爱奇艺SRC运营沟通的过程中一直保持文明礼貌，克制自己的情绪，爱奇艺SRC运营为什么给我发送了一个微笑的表情？

4.为什么不给我道歉？是不是爱奇艺SRC觉得白帽子好欺负还是爱奇艺SRC觉得自己很牛逼不需要道歉又或者是爱奇艺SRC觉得自己什么也没有做错？

vim和git就不用说了，esmtp是mstp的拓展，mutt是linux下收发邮件的程序。

.muttrc

.esmtprc

.gitconfig

git status命令查看改变了哪些文件。

git diff命令查看具体修改的内容。

git add命令将要提交的文件的信息添加到索引库中。如果再运行git diff命令就看不到之前修改的文件了。运行git status命令可以看到提示信息由Changes not staged for commit变成了Changes to be committed，文件名也由红色变成了绿色。

《Malware Data Science》这本书读之前我的期望比较高，虽然我没打算深入做这个方向，但是现在太多关于病毒分析的书了，写来写去都是那些东西，有这么一本从数据科学的角度讲病毒分析的书感觉很难得。但是大致读完之后，还是有点失望。满分100分只能打个60分，个人觉得属于读不读都可以的那种。