$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. Session life too long. A whole year is a lot. If the cookie is hijacked successfully, long access to the user account by the attacker is possible.
2. Missing httpOnly flag. If set to TRUE, cookies will only be accessible through the HTTP protocol. That is, cookies in this case will not be available to scripting languages ​​like JavaScript.
3. No cookie hashing.
4. Lack of setting the secure flag. The secure flag indicates that the cookie value should be transmitted from the client over a secure HTTPS connection. If set to TRUE, the cookie from the client will be sent to the server only if a secure connection is established.

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

The first question with which the questionnaire met future interns concerned the main and widely known web vulnerabilities. The only difficulty here is the need to see them in the source code in PHP. However, no one set the task of “hiding bugs”.

Here is a list of vulnerabilities that can be detected in this listing in order of frequency of their detection:

Password hashing using the MD5 algorithm was noticed even by candidates far from the web. However, there were also interesting nuances, for example, many candidates used very incorrect terms, trying to describe the problems in their own words. “Algorithm vulnerabilities”, “one-way functions”, “the existence of collisions” and other strange turns went into battle, upon closer examination, they turned out to be nothing more than a set of big words that did not reveal the essence. Of course, here we went to a meeting and did not find fault with those people who are just preparing to embark on the path to learning the wisdom of information security. To get a “set-off”, mention of the threat would be enough, that in case of compromising the database, the md5 hashes can be sorted out by an attacker in an acceptable time and passwords (or equivalent strings) can be obtained in clear text. And, of course, many mentioned the lack of salt and brute force based on the use of rainbow tables. We also perceived such comments positively, especially if the respondent explained why this is a threat.

Potential SQL injection. It’s hard to add something; when forming a call to the database, user input of login and password are directly concatenated with the request. If it is unlikely that you can manipulate the password value at this stage (a hash is taken from it), then introducing an injection into username will not be difficult for a potential attacker.

Output of unnecessary debug information leading to an XSS attack. By carefully reading the listing, one could pay attention to the echo call, which displays the generated request to the database in HTML comments on the page. Of course, such a conclusion of additional information to the page is completely optional and, most likely, simply forgotten by the developer after conducting the tests. Such additional information is very beneficial for the attacker and allows a much better understanding of how the application works. However, unfortunately, this is only half the trouble. The fact is that an attacker can manipulate the contents of the query variable, and its contents are not filtered or escaped before being displayed to the user - there is a potential XSS attack. However, its exploitation can turn out to be that still a headache due to the poorly located strtoupper function. The vector injected by the attacker will be uppercase, and if this is not a problem for HTML tags, then Javascript is very offended by such an appeal. This can be easily verified using the browser console.



Well, at least, apparently, the attacker will have to resort to the so-called “scriptless attacks” or sophisticated techniques for bypassing filtering (in this case, JSFUCK would do), so the fact of a security risk does not cancel this.

An error in the logic of the session management mechanism was the most interesting part of the task. Its discovery required not only to read the source line by line, but also to understand the logic of the whole listing. One could feel something was wrong by noticing the setting of a cookie containing the base64-encoded user id in the remember-me block. Further analysis of the logic of this mechanism leads us to the thought: “It turns out that an attacker who knows or goes through id can log into any account without entering a login and password ?!”. Yes, indeed, an attacker can, on his side, independently generate a cookie user and assign it any id value encoded by base64. Sending a request with such a cookie without username and password would trigger the do_login function and log in to someone else's account.

The mention of these 4 vulnerabilities in the candidates' response directly influenced their scores.

However, much depended on the quality of the response. Mentioning ways to rectify the situation, comments on additional factors affecting the feasibility of a particular attack, the use of the right terms and the ability to structure your thoughts, comments on additional weaknesses or potential threats - all this warmed our hearts and led to an increase in the final rating.

In the work of the auditor often have to deal with new technologies, and the ability to understand them is very important. Including this question in the questionnaire, we assumed that most of the candidates hardly heard about the technology of JWT tokens except for the name. Therefore, this question, first of all, was aimed at the ability to search and analyze information from public sources. As a result, a person who missed the issuance of Google at the request of “JWT” and “jwt vulnerability” could come to the following conclusions:

1. This token does not have a signature algorithm, so an attacker is able to modify any fields inside the token, which is not assumed by the concept of JWT tokens.

2. Fields inside the token contain the user's password in clear form; storing such information in the token is, at a minimum, a bad practice. In most cases, you can refuse such a decision and thereby increase your level of security.

3. Remembering the lack of a signature and our ability to modify the fields inside the token, it is logical to assume that changing the value of isAdmin can increase our privileges to administrator privileges.

4. Another interesting idea that few people mentioned in their answer concerns the very fact of the ability to transfer user input in the fields of a JWT token. In a normal situation, an attacker can’t influence the data in the token in any way, which means that developers can often neglect the introduction of additional checks in the code of the handlers. This begs the simple idea: but let's try to conduct classic attacks not through GET / POST parameters, but through token fields. This can give an unexpectedly good result. Such a creative approach with the correct justification of our actions was highly appreciated by us in assessing both this and other issues.

Many candidates in their answers arranged a brief retelling of how the JWT token is structured, and where it is used, it was interesting for us to read, and yet, first of all, we evaluated the aspects of the answer regarding security.

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

Let us consider, in order, what are the main problems that are visible on the given queries:

1) Indeed, since the user’s numerical identifier “10012” is observed in the request, the first step is to check whether it is possible to change the password for another user? Can it be enough to specify someone else's id ?
Vulnerabilities of the IDOR class are fairly easy to exploit and often have high criticality.

2) The request to change the password occurs by the POST method, the CSRF token is not observed, and the content type is “text / plain”. There is the possibility of faking such a request.

Consequently, in order to change the victim’s password, it is enough for the attacker to convince them to just visit the “malicious” link.

3) In the response headers, the server reveals the version of the software used . This can be called a vulnerability at a stretch, but it’s better to hide such banners - attackers can easily find the well-known 1-day exploits on them, plus the value of the software used greatly simplifies the planning of further attacks.

4) We would be very pleased to see the sentence “What will happen if we change the data format from JSON to XML ?”

The fact is that modern frameworks are smart, omnivorous and can process data in different formats. And when parsing XML, a dangerous XXE vulnerability is often allowed. With its help, the intruder can "go" to the internal network, can read configuration files from the server, and occasionally execute RCE.

5) I also wanted to see a remark like “Why is the knowledge of the old not checked when changing the password?”

As for “Option # 2”, there is a “trap” in it - CORS headers are used here, and the Content-Type of the request is already set to “application / json”.

The mistake that the vast majority of candidates made is the answer of the form "-That's the asterisk in Allow-Origin, which means you can send requests from any site!"

No you can not. Firstly, the Allow-Credentials: True header is missing, which means that the browser should execute the request “with cookies”, so that the request would be anonymous, without a session. And secondly, even if such a header were present, the browser would still forbid sending cookies - just because of the "asterisk". Their combination is forbidden, and the browser is ignored.

The objective of the question was to determine the trainee's familiarity with modern (and not so) techniques for conducting MitM attacks. Let's look at potential scenarios based on an existing traffic dump:

1) ARP spoofing
ARP-spoofing is the oldest and easiest way to implement MitM attacks. It consists in sending a gratuitous ARP request to host A.

The IP address of host B is the IP address, and our MAC address is the MAC address. Such a request allows you to modify the ARP table on host A, forcing it to send requests to our device when trying to access host B. Host B is usually the default gateway.

Recommended Tools: bettercap, arpspoof

2) LLMNR, NBNS spoofing
Link-Local Multicast Name Resolution and NetBIOS Name Service are the protocols used to resolve hostnames on the local network. Unlike the DNS protocol, there is no dedicated server that stores all the information; instead, the request is broadcast to all hosts on the network, if the hostname in the request matches the hostname of the device, it will send a response.

As was correctly noted in the answer, the attacker can respond to such requests by sending his IP address in the response, which will lead to the fact that in the future the victim will contact the attacker’s device, instead of the device whose hostname appeared in the request. In addition, an attacker can request NTLM authentication from the victim, which causes the victim device to send an NTLM hash, which can be further used for brute force.

Recommended Tools: Responder

3) WPAD spoofing
WPAD spoofing can be attributed to a special case of LLMNR and NBNS spoofing. Web Proxy Auto Discovery protocol is used to automatically configure an HTTP proxy server.

The device sends an LLMNR / NBNS request with the wpad hostname, receives the corresponding IP address and tries to access the wpad.dat file via HTTP, which stores information about the proxy settings.

As a result, the attacker can perform LLMNR / NBNS spoofing and provide the victim with his wpad.dat file, as a result, all HTTP and HTTPS traffic will go through the attacker.

Recommended Tools: Responder, mitm6

4) Router Advertisement
As you can see from the dump, there are devices with IPv6 enabled on the network. While on the network, you can try sending messages to the victim IPv6 Router Advertisement in order to change the default gateway or DNS server.

Router Advertisement (RA) messages are part of the Stateless Address Autoconfiguration (SLAAC) mechanism, which is required to automatically obtain IPv6 addresses on a network, without using a DHCPv6 server, or in conjunction with it. This is achieved by periodically sending multicast RA messages to the router, which contain the default gateway address, network prefix, DNS server address, domain prefix.

Recommended Tools: raw-packet

5) DHCP spoofing
Also, in a dump, DHCP Discover requests from the same device are repeated at some intervals. We can conclude that there is no DHCP server in this network and respond to the next Discover request by specifying the victim as a default gateway to the device.

Recommended Tools: Yersinia

6) HSRP spoofing
In addition, HSRP packets can be seen in the dump. Hot Standby Router Protocol can increase the availability of routers that act as the default gateway. IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . But! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

Example 1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

Example 2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

Remarks

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

Why is that

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

Example

How it works. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . But this is not so.

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . But. , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

Summary

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)