blog
blog copied to clipboard
mylamour
Your internal mediocrity is the moment when you lost the faith of being excellent. Just do it.
* https://github.com/mylamour/reverse-shell * https://openode.io 最后成品在 http://reverse.us.openode.io  其他： 本来计划在netlify上搭建，后来看到监听3000,不被允许，就寻思着改成监听80，依旧不行。最后选择了Heroku和openode. 但是现在heroku绑定域名已经需要认证信用卡了，就采用了openode,唯一的问题是openode的自定义域名绑定也是有问题的。 原理很简单，拼凑shell脚本，动态传入目标主机和端口号，将这一部分作为url参数传入。这个服务早就有了。后来只是看别人用Python重写了一份拿出来，随即想造一份，一想都一毛一样，最后搭了一个玩玩。然后发现cloud9也被aws整合了，modular也被godday收了。
## 安全顾问 接触香港那边，开始了解整体的架构和技术方案。用的是`php`和`golang`， `golang`用于实现游戏的逻辑，`php`用于实现业务系统的逻辑，分别部署在一个私有机房的5台服务器上。web 服务器用的nginx，后盾数据用的mysql进行存储。服务除了各个系统服务和业务之外还有`ipfs`, `rsync`。当然这是比较中规中矩了。后来了解了下还没有负载均衡系统，等等都没有。 但是根据`轻重缓急`的原则，开始考虑。即重要又急切的肯定是要先做的。退而其次，不严重的又不着急的最后再去做。以保证公司的安全先得到基本的保障。 p> 然后了解一下买了WAF，但是没有CDN所以，所以先对设计基础架构，然后做其检测。因为时间原因，都是先从基础的来。至于办公内网的安全，运营这些肯定不是当务之急。 暂时列出来下面这些条目，同步进行。 - [x] 基础架构设计 - [ ] 安全配置与基线检查 - [ ] 业务代码安全审计 - [x] 服务加固和主机加固 (linux/windows, mysql等) - [x] 安全编码规范 -...
树莓派型号: zero w， 接了个红外摄像头，用人脸识别，然后推送到了微信。最开始打算的是`darknet`和`tiny yolo `去识别视频流。但是darknet在`zero w`只能`segmention fault`。无语。最后选择纯`python`套路 。还挺好玩的。 采用的库主要为`picamera`, `face_recognition`, `wxpy` 逻辑较为简单，实现起来也不难，问题主要在raspberry zero w 上编译dlib, 安装软件等。所以有个更好的方法是直接下载`whl`文件,`face_recognition`的官方安装方式太慢了。只编译dlib都用了一天,而且还要下载model，所以建议下载好model,然后手动安装。 ` wget https://www.piwheels.org/simple/face-recognition-models/face_recognition_models-0.3.0-py2.py3-none-any.whl` ```python #coding:utf-8 from wxpy import * from PIL import Image...
:triangular_flag_on_post:记录昨天安全设计评审的过程，当然这也是第一次进行安全评审。因此做一个总结。安全设计评审应该是SDL落地安全人员参与过程中首当其冲的地方。仅指安全人员自身的功用。如果按照`SDL`流程来讲，最前期应该是进行安全培训。我们可以看两个微软SDL官方给出的流程图。   那么在安全设计评审这一阶段，应该怎么去做。我们可以先看下唯品会的SDL中在落地安全设计这一块怎么做的。  就我自身而言。是按照以下这个流程进行的。 看着一大堆乱七八糟，自上而下的流程，但是做起来其实很快的。此处默认安全人员熟悉各种基本的开发过程中的安全规范以及一些`Checklist`(必须要了解公司开发语言对应的安全开发规范)，举例： `web`安全开发规范，`Python`安全编码规范，`Flask`安全， `Django`安全,常用的安全配置，面临哪些攻击点等等。 ps: 明确逻辑是非常重要的，可以说最为重要，如果连逻辑都不明白，谈什么设计评审。 一些比较基础的: * HTTPS Everywhere * Bcypt 存储Hash * OTP * 频率限制 * 盐不要硬编码 * secret 和 auth-token 不要硬编码 *...
合约安全入个门
不知道什么情况，老板准备做游戏？还是做博彩？不清楚。让看下合约安全，然后给大家分享一下。不好说，两天时间，还要分析下几个Dapp的合约代码。还好之前自己学习过一点。然后现学现卖，搞了一下。想说的都在PDF里了。 PDF -> [smart contract security basicly](https://github.com/mylamour/blog/files/2366085/basic.sharing.pdf) # Resources * Ethereum Safety: https://github.com/ethereum/wiki/wiki/Safety * Smart Contract Best Practices: https://consensys.github.io/smart-contract-best-practices/ * DASP top10: https://github.com/CryptoServices/dasp * Safe Solidity: http://chriseth.github.io/notes/talks/safe_solidity/ * Audit Smart...
因为参与到`SDLChina`的文档编写，恰好公司内的编程语言采用的是`Python`,故整理之。此文亦可在sdlchina官网看见。 ## python语言安全 本身要注意的有，一些危险函数,危险模块的调用，主要是系统调用。这个如果调用一定要对输入输出做好过滤，以下是代码中各种导致进行系统调用的方式。尽量避免。 - 避免各种情况导致系统调用 - 谨慎使用Eval - 数据序列化 ### type 1: keywords 1. `exec('import os ;os.system("ls")')` 2. `eval('__import__("os").system("ls")')` 3. `f'''{__import__('os').system('ls')}'''` 4. `[].__class__.__mro__[-1].__subclasses__()` 5. `_builtin__.open('/etc/passwd')` 6. `system('ls')` 7. `[].__class__.__base__.__subclasses__()[59]()._module.linecache.__dict__['o'+'s'].__dict__['sy'+'stem']('l'+'s')...
 ## 综述 * 实体 > 日志，流量，行为，文件本身 * 方法 > 黑名单，白名单,规则匹配,模糊hash校验, MLDL(CNN/SMV/Naive Bayes,图聚类), KG(知识图谱关联属性), 语法抽象树(AST) ## Webshell 检测篇 ## Malware 检测篇 ## APT 检测篇 与 通用检测框架 聚合waf数据，web日志，交换机日志，IDS日志等等，以及一些设备信息应该是可以发现APT攻击的，APT攻击不易发现甚至不能发现，不意味着我们什么都不能做，攻击手段也不一定是高的什么都做不了。如果能够布置大规模的蜜罐网络，进行伪装，并有效的收集设备信息，聚合起来通过不同手段进行检测。或许也未可知。但是由于本身我没有这方面资源，就不扯淡了。
本文是[恶意软件与数据分析](http://iami.xyz/AliSEC3/)的下篇，针对此次的阿里云安全算法比赛过程的中的总结，完整PPT不放了。下面展示一下一些简单的统计分析和检测绕过。 # 统计特征 5类不同类型的恶意样本的api调用如下所示。      取基本5类都调用的api绘制，分析其差异,这个是为了，分析在5类中都出现的api的调用次数的规律。  缩放比例尺，到前一百万的调用  # 检测绕过      # Other * 集成方法真不错，n个svm bagging效果挺好的，但是训练的时间慢 * 针对特定场景进行的机器模型预测，效果还是很好的。但是通用的话，就不太现实了。效果也差 # References *...
记得之前面试默安，谈到最近在对接渗透测试服务时，云舒大大问了一个问题：寻求第三方测试前，自己为什么不先进行下渗透测试呢？ 在我看来，攻防之道可以用八个字描述(ps:以我目前的菜逼境界): 轻重缓急，大小多少。 * 渗透测试(大小多少) * 应急响应(轻重缓急) 其他工作中，也无非如此。以下，本次对接渗透测试服务中产生的思考以及应急响应产生的思考。至于哪些漏洞的发现，直接看最下面的附录部分。 1. 问题一： 渗透测试者的水平(未知的攻击能力) 经常可以发现渗透测试者的水平可谓是远近高低各不同，所以选到靠谱的渗透测试服务团队就是一个问题了，收费的话也是不一而足。但是我最不喜欢的就是被忽悠，当然任何一个人也都不喜欢被忽悠。这个忽悠不仅包括服务方，还包括老板。 2. 问题二： 预算与老板的预期(未知的支付能力) 有的老板豪放，有的缜密。有的喜欢预付款，有的喜欢白干，然后付费。那么当你遇到这种需要预付费但是心思缜密的老板，毫无疑问。Go die。 3. 问题三：公司内团队的防守能力(已知的技术能力) 不肯学习的菜逼一直都会是菜逼，笨蛋不会爆炸，一流员工招一流员工，二流员工招三流员工。防守能力，心知肚明。心里的B数很明显。 技术能力，以及互相协调的能力等等决定了防守的能力。 4. 问题四：非防守团队的员工安全意识(未知的弱点) 很不幸的是，在第二次的渗透测试过程中，对方发现有员工的github信息泄露，测试环境的账号密码，均暴露了，虽然并不能访问，但是也还是泄露了关键信息。这部分的问题出现职责也在安全这边没有培训好。 5. 问题五：程序根本上的设计问题(未知的代码能力) 代码中存在的漏洞是基础安全之外的一个重要切入点，产生的危害非常大。所以SDL的推动是必须的。这样才能从整个过程完善安全能力。 可以看到的是，整个过程中，已知的只有己方的技术能力。然后，很大程度上的在和未知的攻击对抗过程中失效。进行应急响应的时候，往往意味着，系统出现了问题。对方可能已经进入后渗透阶段了。此时应急响应的优先级应该排在首位(根据出现问题的严重情况，即出现的问题是否严重，涉及多少资产)，去进行响应。此时响应的过程中面临的问题又有: 1. 问题一：其他机器上恢复资源，访问事故机器，阻断恶意攻击...
安全意识是个长久性的东西，不信你看看[AI创业公司中面临的一些安全问题](https://telegra.ph/AI%E5%88%9B%E4%B8%9A%E5%85%AC%E5%8F%B8%E4%B8%AD%E7%9A%84%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98-08-15)，当然我们并不是AI创业公司，但这些问题，其实并不是很严重，但是却很有效的证明了，没有安全意识，没有做好内网安全的培训相关导致的一些问题。所以，我就针对这个做了个PPT。(其实是几周前的了......)最下面的附件是PPT文件（PPT中有邮箱，就先删除了）。PPT转图片用的是https://www.zamzar.com/ 的在线服务，记得office也有插件可以做这种事情的。            