The internet makes it easy to get a lot done, but not all of it needs to be public. That’s where incognito mode comes in, letting you hide your search history from others who are using your internet-connected device. For example, imagine searching online for “ideas for a surprise birthday party.” You wouldn’t want the guest of honor to see that if they use your shared computer!  

What most people don’t realize, though, is that incognito mode or private browsing isn’t really private. If you want to have a private browsing session, it helps to understand what incognito mode does and doesn’t do. 

In this article, we’ll explain what incognito mode is, how to turn it on using different search engines and mobile devices, and why a VPN like McAfee Secure VPN might be a better option for safeguarding your privacy. 

What is incognito mode?

When you search the internet, your web browser automatically saves the history of your searches. In incognito mode, however, it deletes this information when you end the session.  

Google Chrome coined “incognito mode,” so the term is pretty popular. Other web browsers might refer to it differently. For example, Firefox calls it “private mode,” while Safari uses the term “private browsing.”  

What does incognito mode hide?

When you search the internet in private browsing mode, your browser won’t save the history of the websites once you close all of the incognito tabs. This deleted information might include: 

Browsing history, which is a list of the websites you recently visited 
Cookies, which are small files websites use to remember you and your login information 
Site data, which is information entered on a website’s forms 

What browsing history data is visible with incognito mode?

Incognito mode can be super convenient but, as we said, it’s not really private. While it’s true that anyone using your device won’t be able to view your history, your browsing can still be viewed by outside eyes, like:  

Internet service providers (ISP): The company that provides your internet service knows every site you’ve visited. If they receive a subpoena from law enforcement, they’ll have to turn over that data. 

Websites: Even if you’re in incognito mode, your ISP shares your internet protocol (IP) address with the websites you visit. The IP address is a unique number that identifies an internet-enabled device. Anyone with your IP address can determine the city, or possibly the neighborhood, where you live. The only way to conceal your IP address when browsing is to use a virtual private network like McAfee Secure VPN. 
School or company networks: If you use a network run by your school or employer, they can see your browsing history even if you’re in incognito mode. 
Websites you log into: When you’re in incognito mode and log into a website like Twitter, you won’t be anonymous. The site can also share your data with other websites. 

How to turn on incognito mode

Every major browser and mobile device has a type of private browsing. Here’s how to access incognito mode in a few different ways. 

Private browsing in Google Chrome

It’s easy to launch a search in incognito mode in Google Chrome. Just follow these steps:  

Open the Chrome browser on your device. 
Click the three vertical dots in the upper-right corner of the window. 
Select “New Incognito Window.”  
Or use a keyboard shortcut: In Windows, Linux, or Chrome, press Ctrl + Shift + N. On a Mac, press ⌘ + Shift + N. 

You’ll know you’re in Chrome’s incognito mode by the black background and spy icon on the homepage. Here, Chrome reminds you of what incognito mode will and won’t do.  

There is also a toggle to block third-party cookies. When you visit different websites while in incognito mode, websites can track your movement. They might use that data to target ads based on your search history. When you enable third-party cookie blocking, it stops sites from sharing cookies and data. 

Private browsing on your Android device

Here’s how to set it up in the Google Chrome browser for your Android (note that the Google Chrome app is the default browser for most Android phones): 

Open Chrome. 
Tap the three dots at the top-right corner of the screen. 
Tap “New incognito tab.” This will open up a new incognito window. 
Close the incognito window to end the incognito session. 

Remember, for Google Chrome’s incognito mode to do the trick, you need to close your browsing session after each use. If you leave the tab open and someone else uses your phone, they can see your activity. 

Private browsing in Mozilla Firefox

What Chrome calls “incognito mode,” Mozilla Firefox refers to as “private browsing.” There are a couple of ways to launch a private window using the steps below: 

Open Mozilla on your browser. 
Click the three horizontal lines in the top-right corner. 
Select “New Private Window.” 
Or use the keyboard shortcut Ctrl + Shift + P in Windows. On a Mac, press Command + Shift + P. 

The private browsing window has a dark-purple background and a mask icon. This homepage also describes the limitations of private browsing. 

With its Enhanced Tracking Protection, Firefox blocks third-party tracking across sites. This is a default protection on Firefox, so cookies are blocked across sites no matter which privacy setting a user chooses. 

Private browsing in Apple Safari

Apple’s Safari was the first to introduce private browsing for Apple devices in 2005. Users have a couple of ways to open a private window on a Mac or an iOS device. They include: 

Go to the File menu and select “New Private Window.” 
The keyboard shortcut is to hold down Command + Shift + N. 
On an iPhone, open Safari. Tap the “Tabs” button (the two squares on the lower right). Tap “Private.” Tap “Done.” 

Your sign that you’re in a private browser window is a dark gray search bar. Like Firefox, Safari lets you block third-party tracking (you’ll just need to adjust your settings to do so). Choose Safari on your Mac. Go to “Preferences” and click “Privacy.” Then, select “Prevent cross-site tracking.” 

Private browsing on your iPhone

For iPhones, the default browser is Safari. Here’s how to set up private browsing in Safari for your iPhone: 

Open Safari. 
Tap the tab icon at the bottom right of the screen (it looks like two overlapping squares). 
Tap “private” at the bottom-left of the screen. 
To exit private mode, tap “private” again. 

Remember to close your browser’s private tabs when you’re done surfing. This makes sure that cookies are deleted and the private session is safely hidden from your device’s history. 

Why do people use incognito mode?

Doing a private search that erases your browsing history can be useful in certain situations. Because some cookies are deleted at the end of your search, you’ll see fewer ads than in a normal search.  

If there’s something you don’t want to keep in your browser history, like shopping for a gift for a relative, an incognito search can keep your activity private.  

It’s also a good idea to use incognito mode when using a public device or a borrowed computer to protect your data.  

Incognito mode is even helpful if you want to do a search that’s not influenced by your browsing history or to see your blog or website from a fresh perspective. 

Is incognito mode safe?

The terms “private search” and “incognito mode” sound great. But while your history is erased on your device, it’s still visible to the outside world. Even when you’re in incognito mode, websites, your ISP, and your network can still see your IP address and browsing history. 

Not to mention, it won’t delete any files you download, like malicious software. While someone using your device won’t be able to see your browsing history, incognito mode won’t be able to stop hackers and identity thieves in their tracks. 

If you really want to hide your computer’s IP address and browse privately while keeping your data safe, it’s a good idea to look into a VPN service, like McAfee Secure VPN. With our smart VPN, you can browse confidently and stay anonymous from advertisers and prying eyes. You’ll also benefit from bank-grade encryption and automatic protection on unsecured networks.  

Browse online confidently

If your goal is to keep prying eyes out of your browsing history, incognito browsing might not be enough. Use a McAfee Secure VPN for worry-free browsing.  

For added security, though, upgrade to McAfee Total Protection Ultimate and enjoy antivirus protection, identity monitoring, and more! 

The post What Is Incognito Mode and How Safe Is It? appeared first on McAfee Blog.

Read More

Check out this handmade sign posted to the front door of a shuttered Jimmy John’s sandwich chain shop in Missouri last week. See if you can tell from the store owner’s message what happened.

If you guessed that someone in the Jimmy John’s store might have fallen victim to a Business Email Compromise (BEC) or “CEO fraud” scheme — wherein the scammers impersonate company executives to steal money — you’d be in good company.

In fact, that was my initial assumption when a reader in Missouri shared this photo after being turned away from his favorite local sub shop. But a conversation with the store’s owner Steve Saladin brought home the truth that some of the best solutions to fighting fraud are even more low-tech than BEC scams.

Visit any random fast-casual dining establishment and there’s a good chance you’ll see a sign somewhere from the management telling customers their next meal is free if they don’t receive a receipt with their food. While it may not be obvious, such policies are meant to deter employee theft.

You can probably guess by now that this particular Jimmy John’s franchise — in Sunset Hills, Mo. — was among those that chose not to incentivize its customers to insist upon receiving receipts. Thanks to that oversight, Saladin was forced to close the store last week and fire the husband-and-wife managers for allegedly embezzling nearly $100,000 in cash payments from customers.

Saladin said he began to suspect something was amiss after he agreed to take over the Monday and Tuesday shifts for the couple so they could have two consecutive days off together. He said he noticed that cash receipts at the end of the nights on Mondays and Tuesdays were “substantially larger” than when he wasn’t manning the till, and that this was consistent over several weeks.

Then he had friends proceed through his restaurant’s drive-thru, to see if they received receipts for cash payments.

“One of [the managers] would take an order at the drive-thru, and when they determined the customer was going to pay with cash the other would make the customer’s change for it, but then delete the order before the system could complete it and print a receipt,” Saladin said.

Saladin said his attorneys and local law enforcement are now involved, and he estimates the former employees stole close to $100,000 in cash receipts. That was on top of the $115,000 in salaries he paid in total each year to both employees. Saladin also has to figure out a way to pay his franchisor a fee for each of the stolen transactions.

Now Saladin sees the wisdom of adding the receipt sign, and says all of his stores will soon carry a sign offering $10 in cash to any customers who report not receiving a receipt with their food.

Many business owners are reluctant to involve the authorities when they discover that a current or former employee has stolen from them. Too often, organizations victimized by employee theft shy away from reporting it because they’re worried that any resulting media coverage of the crime will do more harm than good.

But there are discrete ways to ensure embezzlers get their due. A few years back, I attended a presentation by an investigator with the criminal division of the U.S. Internal Revenue Service (IRS) who suggested that any embezzling victims seeking a discrete law enforcement response should simply contact the IRS.

The agent said the IRS is obligated to investigate all notifications it receives from employers about unreported income, but that embezzling victims often neglect to even notify the agency. That’s a shame, he said, because under U.S. federal law, anyone who willfully attempts to evade or defeat taxes can be charged with a felony, with penalties including up to $100,000 in fines, up to five years in prison, and the costs of prosecution.

Read More

New website can check for installed Chrome extensions and generate a fingerprint of a visiting user

Read More

The software engineer intended to mine the stolen data and install cryptocurrency miners on some AWS servers

Read More

BRATA now targeting a specific financial institution at a time

Read More

The MS-ISAC shares that its top 10 malware lineup for May 2022 remained consistent with the exception of Jupyter’s return.

Read More

XML External Entity (XXE) flaws present unique mitigation challenges and remain a common attack path. Learn how XXE flaws arise, why some common attack paths are so challenging to mitigate and how Tenable.io Web Application Scanning can help.

Modern applications have more and more tendencies to process data from user-supplied inputs, directly or indirectly. A side effect of this data processing opens the door for attackers to exploit XML External Entity, a complex vulnerability with many vectors.

An XXE is a web vulnerability that allows an attacker to interfere with a feature that performs XML processing. If exploited, it would allow an attacker to read files on the system and to interact with other systems with which the application itself can interact. An XXE attack can have devastating effects and is often considered critical.

Although XXE was ranked No. 4 in the 2017 OWASP Top 10 — and even had a category named after it — this vulnerability has lost some of its relevance in the intervening years as the libraries used to parse XML have become increasingly robust. The 2021 OWASP TOP 10 placed XXE at No. 5, however it is no longer a standalone category, as it was merged with the “Security Misconfiguration” category. This fusion of categories on the OWASP list reflects how an increasing reliance on third-party libraries and software to perform processing — and the lax configuration of these libraries — has become a leading cause of XXE vulnerabilities.

What is XXE?

XXE is a vulnerability that allows an attacker to abuse an application’s XML parser by sending a malicious document or by modifying a request that already contains XML.

XXE vulnerabilities are most commonly used to read files on a system. However, this vulnerability can also be exploited for Denial Of Services (DoS) or Server Side Request Forgery (SSRF) attacks.

An XXE can be used by an attacker to retrieve resources, such as configuration files containing credentials and other secrets, or to access internal services that may be sensitive. The exploitation of this vulnerability can therefore allow an attacker to pivot from XXE to SSRF.

Before understanding how to detect an XXE, it is important to understand the syntax of an XML envelope.

The XML envelope represents the payload sent. At the beginning of this envelope is the DOCTYPE which defines the set of rules and properties that the XML document must follow.

This is where an attacker can define either an internal or an external entity to be called.

An Internal Entity : If an entity is declared within a Document Type Definition (DTD) it is called an internal entity.

Syntax:

An External Entity: If an entity is declared outside a DTD it is called an external entity (Identified by SYSTEM).

Syntax:

While an external entity represents the heart of the operation, an internal entity is still the easiest way for an attacker — or a security practitioner — to detect a possible injection.

The exploitation of an XXE is mainly made possible due to DTDs which, in some cases, are activated by default.

Java seems to be the language that has the most libraries with DTDs enabled by default. In our experience, it’s common for an attacker to detect an XXE on a Java application using an XML parser (like Javax XML Bind library). In many other languages, DTDs must be explicitly activated. Many sites are therefore vulnerable due to a default configuration or because the site owner is unaware that the library in use enables this option by default.

How to detect XXE

In the following example, we show how an attacker using the internal entity will replace the content of the variable when the server parses the document.

This technique has no impact, it simply confirms that the DTDs are activated, but it can only work in the case where the server parsing the request returns a response to the user.

The complexity of an XXE lies in the many possible, and sometimes exotic, injection points.

A page that allows a user to send a Microsoft Office document, for example, is the kind of thing that immediately alerts an attacker to the possible presence of the vulnerability.

Behind the extension ‘.docx’ or ‘.xlsx’ hides a simple zip archive containing many files in XML format.

In the above example, it would be enough for an attacker to modify the file “xl/workbook.xml” to add your XXE payload then to recompress the files in zip with the extension .xslx.

The payload would be executed during the processing of the XML file(s).

Other less logical cases can, however, be present. On a file upload, for example, it is often common for an attacker to try to exploit this feature by sending an arbitrary file allowing them to trigger Cross-Site Scripting (XSS) or upload a WebShell.

But, in the case of a photo (taken directly from a camera or a smartphone), an application could try to parse the Extensible Metadata Platform (XMP) data of the image, which is actually XML, and can therefore also contain a payload.

Three common exploits for XXE

XXE provides attackers with multiple exploitation options. Three examples of common attack paths are:

Read arbitrary files on a server

Direct output in the target application response
Via an out-of-band interaction (blind injection)

Perform a DoS
Perform a SSRF through XXE

Read arbitrary files on a server

Going back to our example above, now that an attacker has confirmed the injection, they can try to read arbitrary files on the server.

We define an external entity identified by the SYSTEM directive and the payload ‘file:///etc/passwd’, which will be executed when parsing the XML document. The end result is that the contents of the file in the payload will be returned to the user. An attacker could exploit this vulnerability in order to read configuration files that could allow them to obtain additional access in order to compromise an organization.

An alternative to this technique is to force an error in the application’s XML parser to make it display the contents of a file.

An attacker would force the third party application to load an external DTD that contains the malicious payload, which will force an error in the application by asking it for a file that does not exist.

When the error is displayed, the application will show the contents of the file requested by the attacker.

One common mitigation technique is to apply a strict network filtering to prevent outbound connections. It’s a technically complicated technique; without diving into the details in this post, suffice to say it is possible to use a DTD already present on the system. For example, using software such as Tomcat, VMWare or Nmap, it will then be possible to call it in our payload and redefine on the fly parameters inside the loaded DTD.

In this example, our vulnerable machine has Nmap installed which includes the “/usr/share/nmap/nmap.dtd” file, which can be used for the attack.

We can also use the “out-of-band” (blind) technique in order to retrieve the content of a document and send it to an external server. This is useful in cases where the attacker is not able to solicit a response or error message from a server because the request is then processed by another service which returns a generic response.

Rather than confirming the possibility of injection with an internal entity, we will directly use an external entity and try to perform an HTTP call on our remote server.

Once confirmed, we will rely on the call of an external DTD which will contain the payload to execute.

The call to this external DTD will be executed by the server and will allow it to retrieve the content of a file and to send it to the attacker’s server.

Denial of Service

Denial of service via XXE is specifically called XML Entity Expansion because this attack takes advantage of calling several entities recursively.

As recursion is a costly operation at CPU level, the more entities are called, the longer the computation time will be.

The objective of the attack is to make a large number of recursive calls in order to crash the application or the server itself.

Example :

The entity “a2” recursively calls “a1” which itself calls “a0”. Through “a2” we call “a1” 15 times
The operation here is inexpensive in CPU time and is executed quickly causing no problems

Now “a6” calls “a5” which calls “a4” and so on recursively
The operation becomes expensive in CPU time and the application starts to have lag and takes time to respond

This attack is therefore very easy to automate to crash the server in a loop.

Server-Side Request Forgery

SSRF attacks have already been explained in a previous blog post, so without diving into technical details the important takeaway is that it is possible to perform an SSRF through XXE.

Instead of trying to read a file on the system, it is possible to specify the URL of an internal server in order to make the application perform a request to it.

When parsing the XML envelope, the server itself will make the request to the target server. An attacker can therefore have access to internal resources or folders that would not be available from the outside, like an internal vulnerable web application framework manager, which could lead to remote code execution (RCE).

Prevention and mitigation strategies

There are multiple best practices available to protect web applications and users in order to avoid vulnerabilities like XXE, but the safest way to prevent XXE is always to disable DTDs (External Entities) completely.

If it is not possible to disable DTDs completely, then external entities and external document type declarations must be disabled in the way that’s specific to each parser.

If this is not possible, it is necessary to put in place in-depth defense mechanisms such as:

Sanitize user-supplied inputs: In general, it is always recommended to filter user entries. If the web application can only send a request to identified and trusted applications, one possible countermeasure is to apply the allowlist approach. In the event that the applications in question are not known, input validation techniques can be added to ensure that the input string respects the expected format.

If possible, verify if the data received has the valid and expected format. When possible, validation should be done through available libraries, because regexes for complex formats are difficult to maintain and are error-prone.

Filter outgoing traffic to not allow loading of external DTDs.
Do not display application error messages to the user but rather display generic messages.

Use Tenable.io Web Application Scanning to detect XML External Entity flaws

Tenable.io Web Application Scanning helps identify XXE vulnerabilities through the classique scan & API scan feature, including the following dedicated plugins:

Plugin 98113 can detect generic XXE (Blind & Non blind) issues and helps identify commonly associated XXE vulnerabilities.
Plugins 98886, 98897 can detect various Apache SOLR XXE vulnerabilities.
Plugin 113199 can detect Jolokia is a JMX-HTTP bridge XXE vulnerability.

Get more information

Tenable.io Web App Scanning
OWASP – Server Side Request Forgery Prevention Cheat Sheet
All WAS XXE Plugins

All Icons are made by www.flaticon.com

Read More

Graham Cluley Security News is sponsored this week by the folks at SolCyber. Thanks to the great team there for their support! If the bad guys aren’t discriminating who they are attacking, how can your business settle for anything less than Fortune 500 level security? SolCyber has brought to market a new way to consume … Continue reading “How to get Fortune 500 cybersecurity without the hefty price tag”

Read More

Cyber now seen as most important component for adoption

Read More

Hartzbleed is a new side-channel attack that works against a variety of microprocressors. Deducing cryptographic keys by analyzing power consumption has long been an attack, but it’s not generally viable because measuring power consumption is often hard. This new attack measures power consumption by measuring time, making it easier to exploit.

The team discovered that dynamic voltage and frequency scaling (DVFS)—a power and thermal management feature added to every modern CPU—allows attackers to deduce the changes in power consumption by monitoring the time it takes for a server to respond to specific carefully made queries. The discovery greatly reduces what’s required. With an understanding of how the DVFS feature works, power side-channel attacks become much simpler timing attacks that can be done remotely.

The researchers have dubbed their attack Hertzbleed because it uses the insights into DVFS to expose­or bleed out­data that’s expected to remain private.

[…]

The researchers have already shown how the exploit technique they developed can be used to extract an encryption key from a server running SIKE, a cryptographic algorithm used to establish a secret key between two parties over an otherwise insecure communications channel.

The researchers said they successfully reproduced their attack on Intel CPUs from the 8th to the 11th generation of the Core microarchitecture. They also claimed that the technique would work on Intel Xeon CPUs and verified that AMD Ryzen processors are vulnerable and enabled the same SIKE attack used against Intel chips. The researchers believe chips from other manufacturers may also be affected.

Read More