文章标题

linux下的io层面留后门？我也没搞过安全，这个该怎么算啊？

假期自己写了三个简单的工具，算是一种创建后门的表层数据传递工具套吧。

---

废话少说，先介绍都有些什么。

1. socket 工具
   监听一个端口并且建立一个连接。或是主动连接一个端口。
2. 程序io重定向
   让一个程序的io和另外一个程序io交错，互相交互。
3. io十字路口
   让一个程序的标准输入输出流被重新引导，被指定程序注入输入、注入输出。

这三个工具可以这么比喻：

第一个是皮管，可以“在地面上”到处接上水管，以便传递数据；           第二个是水管，”从地下“把一个程序的内容传递到另外一个程序；          第三个是T型水管，可以从一个水管中偷取/注入水流。如果说bash+人是水厂，那程序就是住户。一般来说水都是直接入户的。如果管道被改接过，那么这些水就不是原先的那些了。

利用这些工具可以有下面几种人机交互的改造方案：

1. Human<>Program -> Human<>Vir==Program

通过加一根水管，启动Vir，让V介于人和程序中间，修改输入输出。

2. ProgramA<>People,PromgramB<>People -> PA==PB

3. Human<>Program -> Human<>Router<——->Router==Program

本来要在现场的操作，现在可以通过皮管+水管导到任何地方。顺便还把计算机的标准输入输出让出来了。（后台操作）

4. Human<>Program -> Human<>─┰─ Program

______________________________________┗─ Vir

寄生虫一样的工作方式。不过寄生的第一前提是能够针对寄生目标。另外的用法就是日志记录啦。

5. 把上面一个的┗─ Vir改为┗─ Vir==Router<——->Hacker

理论上这是一个很可怕的用法了。

6. 还有一些比如端口映射、数据转发、内网入侵什么的，咱也没干过。

还有一些个糟糕用法比如让数据流出现环。不过既然这么麻烦折腾了，那就别把它搞糟了。

最后是哭穷的。本人学生党，资源也少，也没几个钱。见到资源都不敢下。所以写了这么个无良的玩意，希望能骗到两个积分。

附上我自己实现的上面程序的地址 [http://download.csdn.net/detail/a576742110/9614725]

1. 跨平台不好做，我是没经验，只做出来了一个极其低效的跨平台socket 工具，轰轰烈烈的跨平台实验就结束了。如果你下载了那个包，应该看到的是保留了windows痕迹的不能在windows上用的代码，找到read write的替代品就可以在windwos上用了。
2. 调用exec簇的程序时，如果明确运行目标，那么用execl比较强大，如果只是从argv【】中获取的参数，那最好不过的方法就是截断这些参数，把argv中的某些指针换成NULL，然后提取一个片段作为程序入口参数就好了。
3. 管道这种东西虽然不一定有固定的方向，但是文件的读写方式是有方向的，而标准输入输出正是规定了方向的两个特殊文件。相当于每个程序的io口就是一个网口（真的非常像）。在这种情况下，重定向这种方法相当于是一根交叉网线，只能把两个程序的入口和出口连接起来，入口和入口是不能直接连接起来的。如果想要让一个程序的输入端口的数据传入另外一个程序，一定需要中转一下。要么是缓存了再发，要么是建立一个中间文件（管道也行）。
4. 这样的重定向只是修改了自己进程的fd后调用exec方式启动程序，不是真正的修改了程序的io方式，碰上专业人士是很容易能看出来了。
5. 注意程序有三个标准流，还有一个stderr需要自己处理好。
6. 十字路口是需要交通管理的。如何解决多个程序间的io方向问题需要根据具体情况分析。

我对这个情景的设计灵感来源是netcat工具。说实话，写这个sockettool之前我还不知道nc。虽然知道这种工具肯定存在，但是没个大神老师带怎么会用这种军刀级别的工呢?我确定了nc的存在以后就去找了一下nc的用法。其中一个是蜜罐系统，还有一个端口监听。这些功能引起了我的注意。经过分析，我觉的对于标准程序交互的入侵者来说，最直接的一种攻击方式是输入输出内容的追加，也可以理解为隐藏注入和输出欺骗。最常用的一种攻击方式就是替换关键数据了。不过这种方式是上面提到的第一种用法的延伸，效率也不是很高。为什么呢？

这里好好讨论一下十字路口

• 十字路口，以直线通行为主。在这里，由于原本是直路，我们强行将其改造为路口，所以从功能上来说开出来的是辅路，辅路上的车是要上主路的，否则也不要开这么一个路口。
• 为了效率，不应该设卡拦截主路上的车辆，最好是不破坏原先的车道，开新的车道来让辅路上的车上来。
• 上面一句话中的不设卡拦截除了马路本身没有设卡以外，辅路也不应该有。也就是说，在最高效情况下，辅路的车辆来源不是主路，而是其他的野路（sockettool在向你招手）。
  如果来一辆高速行驶的车，就让他先进辅路小树林，嘿嘿嘿一番再出来，那原本的高速路就变成拥堵路段了。这也是为什么替换数据效率低下（如果你搞硬件，那么嘿嘿嘿，你硬你能干）。
• 如果一定要监听数据流，可以在路口设立右拐道，这样就可以避免数据在辅路中行动时间过长产生延迟。
• 如果一定要可靠的控制每一辆车，那只能所有车辆乖乖绕行辅路。
  那大概是这样的
  
  此图是一种中间人主动攻击的演示。也是上面的实现示意图。图中Alice可以当作人，Bob是一个电脑。Alice本来说了一句话，如果设计的十字路口是严格控制数据传输的，那么就能精确的加入一个精心准备内容，完成攻击。但是这样数据传输太慢了。理论上比较快的方式是Cracker 在路口看着，等到信息传输到特定位置时自己蹦出来。可是基本就对不上了。即使能够准确的在路口排号，让自己发出的信息在特定目标后面，那也不能保证信息插入理想位置（网络数据包是以桢为单位传递的，你不能把自己的信息插入别人的包里面把？替换除外）。

说了这么多是想让你知道你的数据该从哪来到哪去。

我的程序设计结果是程序的输入流会读取注入程序A的stdout和本程序的stdin，发送到目标程序的stdin和日志文件中，输出和注入程序B的stdout被发到本程序的stdout和日志文件中。这样设计的问题是注入程序打开后会和Cross争抢标准输入流的读取权，结果自然是后启动的注入程序获胜。所以要指明注入程序的输入流，或者关闭其输入流。一种经典的用法是将Cross程序的日志文件作为sockettool的输入，把Cross程序伪装成系统应用，并打开原先的系统应用和sockettool（作为注入程序）。这样这个系统应用就被远端监控起来了，而且我也很傻X的让信息流产生了环，简直爽歪歪。