ldap服务器地址是什么今天到科技园某企业帮助解决网络设备用域帐号来认证的问题


Apache Log4j2高危JNDI注入漏洞:攻击过程

Apache Log4j2高危JNDI注入漏洞:攻击过程

2021年12月9日晚间,网上发生了一件大事,一个核弹级高危漏洞被曝光:Apache-Log4j2组件存在JNDI注入漏洞,攻击者无需特殊配置,即可利用该漏洞在目标服务器上执行任意代码。
Log4j2是一款优秀的Java日志框架,被大量用于业务系统开发,用来记录日志信息。经阿里云安全团队验证,Apache Struts2、Apache Solr、Apache Druid、Apache Flink等组件均受影响,百度、苹果等公司的产品也存在以上问题。

攻击过程如下:
攻击者在网页表单的输入框里输入注入攻击语句,在提交表单时,被服务器端的Log4j2 框架作为日志输出,但由于该库的某些解析构造漏洞,会把${jndi:ldap://网页链接} 括号中的语句作为命令执行。
攻击者的注入攻击语句经过解析会先访问LDAP服务器,是攻击者控制的地址。
服务器通过JNDI向请求。就可以在响应中添加一些恶意的可执行脚本,注入到服务器进程中,例如可执行的字节码网页链接。
最后网站服务器在本地实例化并执行这个java类,即攻击者的攻击脚本得到执行。

项目经理说

项目经理说,一个新入职的员工不能登录gitlab,提示账号不存在?
公司是用域服务器实行账号统一认证(ldap),其他员工账号可以正常登录,为啥新账号不能正常登录呢?

1、于是在cat /var/log/gitlab/gitlab-rails/application.log日志,显示认证失败;

2、再查看/etc/gitlab/gitlab.rb配置文件,也没有发现异常;

3、由于生产环境还在使用,所以不能在/etc/gitlab下面,执行gitlab-ctl reconfigure重载配置文件;

4、使用命令gitlab-rake gitlab:ldap:check,检查是否能够正常获取用户信息,发现执行成功,可以正常从域认证服务器获取到用户信息,说明gitlab到域认证服务器连接没有问题;

5、那只能是密码的问题,重置域账号密码,最后成功登录。
原来新员工改了自己的域登录密码,没有告诉项目经理,两个人沟通不够,只想到是信息部门的问题,这种思维是不要不要的。遇到问题先从自身找原因,然后再扩展到其他地方。
总之,ldap运行稳定,减少管理成本,遇到问题,可以利用以上的checklist进行排查。

问题:如果kafka服务禁止外网连接

问题:如果kafka服务禁止外网连接,那么“Apache Kafka Connect 远程代码执行漏洞”是否就不用担心?
回答:如果Kafka服务禁止外网连接,那么Apache Kafka Connect远程代码执行漏洞就不会对该服务造成风险。这是因为该漏洞需要攻击者能够访问Kafka Connect Worker并创建或修改连接器,然后设置恶意LDAP地址,从而在目标Connect服务器上实现JNDI注入攻击,最终导致执行任意代码 。如果Kafka服务禁止外网连接,则攻击者无法访问Kafka Connect Worker,因此无法利用这个漏洞进行攻击。

值得注意的是,Apache Kafka Connect远程代码执行漏洞是CVE-2023-25194,该漏洞影响Apache Kafka Connect 服务在2.3.0至3.3.2版本中,不影响Kafka server (broker) 。如果Kafka服务的版本在2.3.0以下或3.3.2以上,则不会受到此漏洞的影响。
因此,如果Kafka服务禁止外网连接,则Apache Kafka Connect远程代码执行漏洞不会对该服务造成威胁。但是,为了保证系统的安全性,建议及时更新Kafka服务和相关组件,以免受到其他漏洞的影响。

这漏洞可真大

这漏洞可真大,阿里牛人的log4j2漏洞检测跑了一下,直接调起了计算器。
漏洞流程我是这样分析理解的:

(1)我们使用log4j2在info、debug、warn、error过程中会传入打印参数。

(2)若这些参数来自于外部,例如:web提交,数据采集等,我们对外部请求的一些数据作为日志用log4j2打印或者输出成日志文件。

(3)在外部数据中若恶意加入一个jndi的ldap U地址变量进行,这个URL指向的是恶意ldap服务。

(4)当log4j2开始打印这段包含恶意URL变量,会识别出这段URL,然后进行jndi的ldap调用进行对象lookup。

(5)接受log4j2请求的恶意ldap服务会给log4j2传回一个恶意的class。
(6)log4j2获取此class仅仅是对象根,然后会根据这个根的信息再次远程请求恶意RPC服务器,获取此class根对应的恶意实现对象,并在jvm上反序列化。

(7)此对象会在反序列化成功后,会在log4j2所在的jvm运行环境执行各种内置恶意执行调用。

总之一句话,兄弟们赶紧打补丁吧,这漏洞把雨水都漏到裤衩里啦!
注意补充一下:
这是全平台漏洞,以Linux云计算的应用部署量,问题更严重,Windows只是本机测试,只要产品涉及有log4j2,一定要升级jog4j2最新版的jar包,还要自查产品的依赖包有没有把log4j2打进依赖jar内部。

一位老铁留言反馈

一位老铁留言反馈,研发同事投诉一个用户的gitlab账号,一会儿登录正常,一会无法登录,提示用户名和密码认证错误,影响提交代码。
最担心这种问题,时好时坏。
经过了解,gitlab账户信息是利用ldap从域同步而来。
这种情况做了如下排查:

1、更改该用户的域账号密码;

2、更改gitlab的账号密码;

3、结果可以登录,说明账号是没有问题的,只是同步出了问题;

4、其他账号都同步正常,说明问题不在服务器,而在该账号的本地;

5、到该账号登录的电脑上,发现在控制面板-凭据管理器里面-普通凭据下面,有该账号到gitlab的凭据,删除该凭据。

6、重新登录gitlab,成功。
问题原因找到了,是因为该用户的本地凭证需要更新,方法是先删除本地凭据,再登录。

今天到科技园某企业帮助解决网络设备用域帐号来认证的问题

今天到科技园某企业帮助解决网络设备用域帐号来认证的问题。解决这个问题主要用到的是radius协议,首先需要在企业内网部署一台radius认证服务器,然后需要在网络设备上开启radius认证,主要配置办法是配置一个radius的认证模板,然后再认证模板下添加内网部署的radius认证服务器,认证端口是1812,为了安全起见,我们需要设置在认证开始前需要通过密码来做认证。配置完认证模板后,需要在全局下调用认证模板。到此网络设备的配置就完成了。
接下来需要到认证服务器上纳管网络设备,纳管完成后需要配置认证服务器跟内网AD域服务器之间的账号同步,主要用到的知识是ladp的同步,账号同步后,认证服务器就可以调用ad服务器的账号和密码来对设备进行认证了。