Posts List

Bastion -- Hack the box

介绍 目标: 0.10.10.134 (Windows) Kali:10.10.16.65 In conclusion, Bastion is not a medium box. But it would be easier to solve this box with windows VM. Command VM may be a good choice. But it can be finished by kali. 总的来说,Bastion 其实并不是一个特别简单的机器。如果使用 windows 可以更方便地解决这台靶机。Command VM 对于这台靶机其实挺不错的,不过我们也可以使用 kali 来完成这个靶机。 信息枚举 Firstly, detect the open ports: 首先,探测开放端口 # Nmap 7.70 scan initiated Sun May 5 12:33:32 2019 as: nmap -sT -p- --min-rate 10000 -oN ports 10.

使用浏览器作为代理从公网攻击内网

介绍 在 Forcepoint,我们不断寻求改善我们产品所提供的防护。为此,我们经常研究不寻常或潜在新颖的攻击技术。最近的一个研究课题是从公网发起的针对 localhost 和内网的攻击。 虽然不是新的攻击,但在安全研究社区之外,恶意 JavaScript 可以攻击内网并不广为人知。在关于该主题的有限文档中,大多数资源是从 inter-protol(协议间)漏洞来描述 [1] [2],而我们的重点是 intra-protol(协议内部)的漏洞。我们发现没有一站式资源从协议内部攻击的角度去描述这种攻击,并且在白皮书中收集这些技术是为了填补关于这些攻击文档的空白,以及让被低估的攻击面受到关注。 由于浏览器默认可以访问 localhost 以及本地局域网,因此这些攻击可以绕过潜在的本地基于主机的防火墙以及企业/消费者外围防火墙。 恶意攻击者了解这些攻击,但防守者也需要被告知。除了描述攻击的技术细节之外,我们还将讨论检测和防范攻击的方法。 可疑行为:公网到局域网的连接 从恶意站点加载的 JavaScript 可以在许多情况下能够连接用户本地计算机(localhost)或其他内部主机上运行的服务。现代 Web 浏览器不能完全阻止使用受害者浏览器作为代理攻击内网。事实上,我们不仅可以让受害者浏览器在内部发送请求,而且我们还可以发现内部主机,进行有限端口扫描,进行服务指纹识别,最后我们甚至可以通过恶意 JavaScript 来攻击易受攻击的服务。 如果从公网获取的网页尝试访问未路由的 IP 地址(例如 localhost 或内部网络),则应将其视为可疑行为。通过我们的遥测技术,我们还没有发现过存在于公网上的良性网页需要连接到私有 IP 地址,我们也没有发现任何有效和合理的业务用例来做这样的事情。是否有必要允许公网上的网页连接到私有 IP 地址,而不是在某些边缘情况下,这是值得怀疑的。一个边缘情况可能是在内部网络上使用公共 IP 地址的不常见设置。(但必须允许相反的方向的情况,因为许多内部页面可能出于完全正当的原因而获取外部资源。) 这种可疑行为与攻击链的各个部分一起具有某些特征,可以用于检测目的建模。我们稍后将回到更详细的关于检测的讨论,因为如果我们先了解攻击链的技术细节,检测就更有意义了。 在进行威胁建模时,开发者通常认为本地服务永远不会接收外部输入,因此通常缺乏对这些服务的安全审核。可能通过远程托管的恶意 JavaScript 攻击易受攻击的本地服务的最新示例是 Logitech Options 应用开启易受攻击的 WebSocket 服务器 [3]。通过远程跨域 JavaScript 进行的本地攻击代表了一种被低估的攻击面。 同源策略不会阻止本地攻击吗? 实际上,同源策略(SOP)[4]在很多情况下确实可以防范这种攻击,但正如我们看到的,仍然存在攻击可能成功的情况。尽管有相关文档,通常被忽略的事实是同源策略并不会阻止浏览器发出跨域请求,它只能阻止 JavaScript 读取响应。(同源策略允许嵌入跨域资源,如图像和 JavaScript,但这是另外一方面的内容。)对于攻击某些易受攻击的服务,它可能足以能够盲目地发送恶意请求以达到攻击者的目的。 Mozilla 的文档很好地描述了同源策略的功能:允许跨域嵌入和写入,但不允许读取。允许跨域写入的事实使得可能执行以下攻击: 受害者在互联网上浏览恶意页面。页面上的 JavaScript 根据同源策略向不应与之通信的内部服务器发出异步请求(XMLHttpRequest)。 然而,浏览器将发送请求(此时服务器被利用)。 浏览器收到响应但不会将其传递给 JavaScript。 那跨域资源共享呢? 我们要展示的攻击与跨域资源共享(CORS) [5] 无关,只与同源策略相关。在本白皮书中,我们可以假设不允许跨域资源共享请求,这意味着我们拥有最严格的设置,其中同源策略“阻止”所有内容。即使面对同源策略,我们也可以进行攻击。 攻击概述 我们将看一下使用受害者的浏览器作为代理,外部站点上的 JavaScript 如何攻击运行在 localhost 或内网中的易受攻击的服务的示例。作为概述,我们将看看以下步骤:

跨站请求伪造(CSRF)攻击

概述 跨站请求伪造(CSRF)攻击强迫终端用户在他们身份被认证的情况下执行对于目标应用未知的操作(恶意的)。CSRF 攻击一般针对状态更改请求,而不是数据被盗,因为攻击者无法查看对伪造请求的响应。通过社会工程的(例如通过电子邮件或聊天发送链接)方法,攻击者可以欺骗 Web 应用程序的用户执行攻击者选择的操作。如果受害者是普通用户,则成功的 CSRF 攻击可以强制用户执行状态更改请求,例如转账,更改其电子邮件地址等。如果受害者是管理帐户,CSRF 可能会危及整个 Web 应用程序。 值得注意的一点是 CSRF(跨站请求伪造)攻击经常与 XSS(跨站脚本)攻击(特别是反射性 XSS 攻击)混淆,两者虽然都是跨站,但并未有实际联系,利用方式也不尽相同。XSS 攻击通常是在合法的网络应用中注入恶意的内容为受害者提供服务。注入的内容会被浏览器执行,因此恶意脚本会执行。CSRF 的攻击通常是让目标用户在不知情的情况下执行一个操作(比如转账,表单提交),如果当前目标用户的还是已授权状态,那么这些操作就有可能会执行成功。可以这么理解,CSRF 就是利用用户合法的身份在用户不知情的情况下执行一些操作。而 XSS 则是在合法的网站注入恶意的内容,需要或者不需要用户交互即可执行恶意脚本,从而实现攻击。虽然两者并无太多相同之处,但是 XSS 漏洞会导致 CSRF 的某些防护措施失效,因此做好 XSS 的防护对于 CSRF 的防护也是很有意义的。 CSRF 的工作原理 CSRF 攻击是通过让一个已授权的用户的浏览器向应用发起一个恶意请求(用户尚不知情的情况)。只要用户的身份已被验证过且实际的请求已经通过用户的浏览器发送到目标应用,应用无法知道情况的来源是否是一个有效的交易或者这个用户是在知情的情况下点击这个链接。通过 CSRF 攻击,攻击者可以让受害者执行一些他们不知情的操作,比如,登出,购买操作,改变账户信息或者其它目标攻击应用提供的服务。 下面就是一个例子在机票供应商那里购买飞机票: POST http://TicketMeister.com/Buy_ticket.htm HTTP/1.1 Host: ticketmeister User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;) Firefox/1.4.1 Cookie: JSPSESSIONID=34JHURHD894LOP04957HR49I3JE383940123K ticketId=ATHX1138&to=PO BOX 1198 DUBLIN 2&amount=10&date=11042008 响应代表购买飞机票的 POST 请求已经成功执行: HTTP/1.0 200 OK Date: Fri, 02 May 2008 10:01:20 GMT Server: IBM_HTTP_Server Content-Type: text/xml;charset=ISO-8859-1 Content-Language: en-US X-Cache: MISS from app-proxy-2.