Best practices for Tor use, in light of released NSA slides It has been known in the security community that a tool as versatile as Tor is likely the target of intense interest from intelligence agencies. While the FBI has admitted responsibility for a Tor malware attack, the involvement of SIGINT organizations has not been confirmed.

Any doubt was removed in early October, 2013 with The Guardian's release of "Tor Stinks," an NSA presentation (vintage June 2012) outlining current and proposed strategies for exploiting the network.

Some salient points:

Fundamentally, Tor is secure
...however, de-anonymization is possible in certain circumstances
"Dumb users" will always be vulnerable (designated internally as "EPICFAIL")
NSA/GCHQ operate Tor nodes
Traffic analysis, in various forms, appears to be the tool of choice

After reviewing the literature, what changes should Tor users implement to ensure -- to the greatest degree technically feasible -- their continuing security?

As a very long time Tor user, the most surprising part of the NSA documents for me was how little progress they have made against Tor. Despite its known weaknesses, it's still the best thing we have, provided it's used properly and you make no mistakes.

Since you want security of "the greatest degree technically feasible", I'm going to assume that your threat is a well-funded government with significant visibility or control of the Internet, as it is for many Tor users (despite the warnings that Tor alone is not sufficient to protect you from such an actor).

Consider whether you truly need this level of protection. If having your activity discovered does not put your life or liberty at risk, then you probably do not need to go to all of this trouble. But if it does, then you absolutely must be vigilant if you wish to remain alive and free.

I won't repeat Tor Project's own warnings here, but I will note that they are only a beginning, and are not adequate to protect you from such threats. When it comes to advanced persistent threats such as state actors, you are almost certainly not paranoid enough.

Your Computer

To date the NSA's and FBI's primary attacks on Tor have been MITM attacks (NSA) and hidden service web server compromises and malware delivery (FBI) which either sent tracking data from the Tor user's computer, compromised it, or both. Thus you need a reasonably secure system from which you can use Tor and reduce your risk of being tracked or compromised.

Don't use Windows. Just don't. This also means don't use the Tor Browser Bundle on Windows. Vulnerabilities in the software in TBB figure prominently in both the NSA slides and FBI's recent takedown of Freedom Hosting. It has also been shown that malicious Tor exit nodes are binary patching unsigned Windows packages in order to distribute malware. Whatever operating system you use, install only signed packages obtained over a secure connection.
If you can't construct your own workstation capable of running Linux and carefully configured to run the latest available versions of Tor, a proxy such as Privoxy, and the Tor Browser, with all outgoing clearnet access firewalled, consider using Tails or Whonix instead, where most of this work is done for you. It's absolutely critical that outgoing access be firewalled so that third party applications or malware cannot accidentally or intentionally leak data about your location. If you must use something other than Tails or Whonix, then only use the Tor Browser (and only for as long as it takes to download one of the above). Other browsers can leak your actual IP address even when using Tor, through various methods which the Tor Browser disables.
If you are using persistent storage of any kind, ensure that it is encrypted. Current versions of LUKS are reasonably safe, and major Linux distributions will offer to set it up for you during their installation. TrueCrypt is not currently known to be safe. BitLocker might be safe, though you still shouldn't be running Windows. Even if you are in a country where rubber hosing is legal, such as the UK, encrypting your data protects you from a variety of other threats.
Remember that your computer must be kept up to date. Whether you use Tails or build your own workstation from scratch or with Whonix, update frequently to ensure you are protected from the latest security vulnerabilities. Ideally you should update each time you begin a session, or at least daily. Tails will notify you at startup if an update is available.
Be very reluctant to compromise on JavaScript, Flash and Java. Disable them all by default. The FBI has used tools which exploit all three in order to identify Tor users. If a site requires any of these, visit somewhere else. Enable scripting only as a last resort, only temporarily, and only to the minimum extent necessary to gain functionality of a web site that you have no alternative for.
Viciously drop cookies and local data that sites send you. Neither TBB nor Tails do this well enough for my tastes; consider using an addon such as Self-Destructing Cookies to keep your cookies to a minimum. Of zero.
Your workstation must be a laptop; it must be portable enough to be carried with you and quickly disposed of or destroyed.
Don't use Google to search the Internet. A good alternative is Startpage; this is the default search engine for TBB, Tails and Whonix. Another good option is DuckDuckGo.

Your Environment

Tor contains weaknesses which can only be mitigated through actions in the physical world. An attacker who can view both your local Internet connection, and the connection of the site you are visiting, can use statistical analysis to correlate them.

Never use Tor from home, or near home. Never work on anything sensitive enough to require Tor from home, even if you remain offline. Computers have a funny habit of liking to be connected... This also applies to anywhere you are staying temporarily, such as a hotel. Never performing these activities at home
helps to ensure that they cannot be tied to those locations. (Note that this applies to people facing advanced persistent threats. Running Tor from home is reasonable and useful for others, especially people who aren't doing anything themselves but wish to help by running an exit node, relay or bridge.)
Limit the amount of time you spend using Tor at any single location. While these correlation attacks do take some time, they can in theory be completed in as little as a day. (And if you are already under surveillance, it can be done instantly; this is done to confirm or refute that a person under suspicion is the right person.) While the jackboots are very unlikely to show up the same day you fire up Tor at Starbucks, they might show up the next day. I recommend for the truly concerned to never use Tor more than 24 hours at any single physical location; after that, consider it burned and go elsewhere. This will help you even if the jackboots show up six months later; it's much easier to remember a regular customer than someone who showed up one day and never came back. This does mean you will have to travel farther afield, especially if you don't live in a large city, but it will help to preserve your ability to travel freely.
Avoid being electronically tracked. Pay cash for fuel for your car or for public transit. For instance, on the London Underground, use a separate Travelcard purchased with cash instead of your regular Oyster card or contactless payment. Pay cash for everything else, too; avoid using your normal credit and debit cards, even at ATMs. If you need cash when going out, use an ATM close to home that you already frequently use. If you drive, try to avoid number plate readers by avoiding major bridges, tunnels, motorways, toll roads and primary arterial roads and traveling on secondary roads. If the information is publicly available, learn where these readers are installed in your area.
When you go out to perform these activities, leave your mobile phone turned on and at home. If you need to make and receive phone calls, purchase an anonymous prepaid phone for the purpose. This is difficult in some countries, but it can be done if you are creative enough. Pay cash; never use a debit or credit card to buy the phone or top-ups. Never insert its battery or turn it on if you are within 10 miles (16 km) of your home, nor use a phone from which the battery cannot be removed. Never place a SIM card previously used in one phone into another phone, as this will irrevocably link the phones. Never give its number or even admit its existence to anyone who knows you by your real identity. This may need to include your family members.

Your Mindset

Many Tor users get caught because they made a mistake, such as using their real email address in association with their activities, or allowing a hostile adversary to reach a high level of trust. You must avoid this as much as possible, and the only way to do so is with careful mental discipline.

Think of your Tor activity as pseudonymous, and create in your mind a virtual identity to correspond with the activity. This virtual person does not know you and will never meet you, and wouldn't even like you if he knew you. He must be kept strictly mentally separated. Consider using multiple pseudonyms, but if you do, you must be extraordinarily vigilant to ensure that you do not reveal details which could correlate them.
If you must use public Internet services, create completely new accounts for this pseudonym. Never mix them; for instance do not browse Facebook with your real email address after having used Twitter with your pseudonym's email on the same computer. Wait until you get home.
By the same token, never perform actions related to your pseudonymous activity without using Tor, unless you have no other choice (e.g. to sign up for a service which blocks signup via Tor). Take extra precautions regarding your identity and location if you must do this.

Hidden Services

These have been big in the news, with the takedown of high-profile hidden services such as Silk Road and Freedom Hosting in 2013, and Silk Road 2.0 and dozens of other services in 2014.

The bad news is, hidden services are much weaker than they could or should be. The Tor Project has not been able to devote much development to hidden services due to the lack of funding and developer interest (if you're able to do so, consider contributing in one of these ways).

Further, it is suspected that the FBI is using traffic confirmation attacks to locate hidden services en masse, and an early 2014 attack on the Tor network was actually an FBI operation.

The good news is, the NSA doesn't seem to have done much with them (though the NSA slides mention a GCHQ program named ONIONBREATH which focuses on hidden services, nothing else is yet known about it).

Since hidden services must often run under someone else's physical control, they are vulnerable to being compromised via that other party. Thus it's even more important to protect the anonymity of the service, as once it is compromised in this manner, it's pretty much game over.

The advice given above is sufficient if you are merely visiting a hidden service. If you need to run a hidden service, do all of the above, and in addition do the following. Note that these tasks require an experienced system administrator who is also experienced with Tor; performing them without the relevant experience will be difficult or impossible, or may result in your arrest. The operator of both the original Silk Road and Silk Road 2.0 were developers who, like most developers, were inexperienced in IT operations.

Do not run a hidden service in a virtual machine unless you also control the physical host. Designs in which Tor and a service run in firewalled virtual machines on a firewalled physical host are OK, provided it is the physical host which you are in control of, and you are not merely leasing cloud space. It is trivial for a cloud provider to take an image of your virtual machine's RAM, which contains all of your encryption keys and many other secrets. This attack is far more difficult on a physical machine.
Another design for a Tor hidden service consists of two physical hosts, leased from two different providers though they may be in the same datacenter. On the first physical host, a single virtual machine runs with Tor. Both the host and VM are firewalled to prevent outgoing traffic other than Tor traffic and traffic to the second physical host. The second physical host will then contain a VM with the actual hidden service. Again, these will be firewalled in both directions. The connection between them should be secured with a VPN which is not known to be insecure, such as OpenVPN. If it is suspected that either of the two hosts may be compromised, the service may be immediately moved (by copying the virtual machine images) and both servers decommissioned.

Both of these designs can be implemented fairly easily with Whonix.
Hosts leased from third parties are convenient but especially vulnerable to attacks where the service provider takes a copy of the hard drives. If the server is virtual, or it is physical but uses RAID storage, this can be done without taking the server offline. Again, do not lease cloud space, and carefully monitor the hardware of the physical host. If the RAID array shows as degraded, or if the server is inexplicably down for more than a few moments, the server should be considered compromised, since there is no way to distinguish between a simple hardware failure and a compromise of this nature.
Ensure that your hosting provider offers 24x7 access to a remote console (in the hosting industry this is often called a KVM though it's usually implemented via IPMI) which can also install the operating system. Use temporary passwords/passphrases during the installation, and change them all after you have Tor up and running (see below). Use only such a tool which is accessible via a secured (https) connection, such as Dell iDRAC or HP iLO. If possible, change the SSL certificate on the iDRAC/iLO to one you generate yourself, as the default certificates and private keys are well known.

The remote console also allows you to run a fully encrypted physical host, reducing the risk of data loss through physical compromise; however, in this case the passphrase must be changed every time you reboot the system (even this does not mitigate all possible attacks, but it does buy you time).

If the system was rebooted without your knowledge or explicit intent, consider it compromised and do not attempt to decrypt it in this manner. Silk Road 2.0 apparently failed to encrypt its hard drives, and also failed to move service when it went down in May 2014, when it was taken offline by law enforcement to be copied.
Your initial setup of the hosts which will run the service must be in part over clearnet (via a Tor exit node), albeit via ssh and https; however, to reiterate, they must not be done from home or from a location you have ever visited before. As we have seen, it is not sufficient to simply use a VPN. This may cause you issues with actually signing up for the service due to fraud protection that such providers may use. How to deal with this is outside the scope of this answer, though.
Once you have Tor up and running, never connect to any of the servers or virtual machines via clearnet again. Configure hidden services which connect via ssh to each host and each of the virtual machines, and always use them. If you run multiple servers, do not allow them to talk to each other over the clearnet; have them access each other via unique Tor hidden services. If you must connect via clearnet to resolve a problem, again, do so from a location you will never visit again. Pretty much any situation which would require you to connect via clearnet indicates a possible compromise; consider abandoning it and moving service instead.
Hidden services must be moved occasionally, even if compromise is not suspected. A 2013 paper described an attack which can locate a hidden service in just a few months for around $10,000 in cloud compute charges, which is well within the budget of even some individuals. As noted earlier, a similar attack took place in early 2014 and may have been involved in the November 2014 compromise of dozens of hidden services. How often is best to physically move the hidden service is an open question; it may be anywhere from a few days to a few weeks. My best guess right now is that the sweet spot will be somewhere between 30 to 60 days. While this is an extremely inconvenient timeframe, it is much less inconvenient than a prison cell. Note that it will take approximately an hour for the Tor network to recognize the new location of a moved hidden service.

Conclusion

Anonymity is hard. Technology alone, no matter how good it is, will never be enough. It requires a clear mind and careful attention to detail, as well as real-world actions to mitigate weaknesses that cannot be addressed through technology alone. As has been so frequently mentioned, the attackers can be bumbling fools who only have sheer luck to rely on, but you only have to make one mistake to be ruined.

The guidelines I have given above are intended to make it harder, more time-consuming and more expensive for attackers to locate you or your service, and whenever possible to give you warning that you or your service may be under attack.

We call them "advanced persistent threats" because, in part, they are persistent. As the US attorney Preet Bharara said announcing the Silk Road 2.0 raid, "We don't get tired." They won't give up, and you must not.

Further reading

Chatting in Secret While We're All Being Watched
Mostly good advice from one of the journalists who communicated with Edward Snowden. The only part I can really disagree with is the possibility of using your existing operating system or smartphone for communication. As we've seen already, this cannot be done safely, and you must prepare a computer with something like Whonix or Tails.
Selected Papers in Anonymity An extensive collection of anonymity-related research, some of which has been presented here. Go through this to get a feel for just how difficult remaining anonymous really is.


Didn't understood what the purpose of the newly discovered TCP Faking attack Source: http://lgms.nl/blog-2

Hey guys,

I've been reading through the research paper but didn't understand the purpose of the attack.

What the attacker will want to exploit here ?

The idea here is to open a TCP connection with a spoofed address (i.e. the IP address seen by the server is not the real IP address of the client), thus bypassing any IP black- or white-listing. It has severe restrictions on what can be done: only one packet can be sent, and it should not depend on anything coming from the server.

Practically, it could for example be used to send a HTTP request.

Now, I don't think this is really new, IP spoofing with TCP has always been about guessing the sequence number sent by the server in the SYN-ACK packet. In the past, it was mostly done by using weaknesses in the generation of this number, here it is a simple brute force attack.

It doesn't avoid the usual difficulties faced when spoofing a connection neither, the real host using the spoofed IP still need to be unable to respond, and there is no way to see what the server sends back. It is also limited to a single packet.


Could a badUSB device actually hack your computer while it is supervised? Could a badUSB device install actual malware (disguised as the drivers) on your computer? I thought that windows and Mac required all drivers to be digitally signed though?
Obviously, a badUSB device could impersonate a keyboard and use keyboard shortcuts to do things, but wouldn't the user notice though and be able to unplug the USB device before it's too late?

Hello there genealogy!

A bad USB is able to download files hosted on a website. A very common thing for pen testers to do is to upload a file (most commonly a shell, exe or malware of some sort) to a said directory of a website that, with the help of a script that the USB will run, will make the computer download said file.

Yes, the owner of the device can actually see when the bad USB starts doing its thing and disconnect it, but that is when other skillsets enter into play, like social engineering.

Hope this helped!


Is there any way to verify that an organization operating an open-source SaaS is using an untampered-with version of the software? Some organizations have begun offering access to servers running open-source software (mail servers, chat servers), operated and maintained by those organizations, for a nominal recurring upkeep fee.

Normally, this software's source code is available on Github, or Bitbucket, or in some easily-accessible format for people who know how to set it up and don't mind the hassle of self-hosting.

But is there any way to verify that the code being run on these remote servers is what's being kept in the version control system, preferably in a trust-free way?

In my experience hardening servers against attacks, having a secure hosting setup against attackers is usually synonymous with having a black box host, with only an exposed web API.

Short answer - almost no way at all to tell. The question is equivalent to black box probing. You can put certain inputs to the box and get certain results - what exactly is the box doing between input and output? Can't tell. What other processes or devices have access to the same storage devices? Can't tell.

The "almost" is because there may be sideband attacks that let you determine some aspects of the platform. For example, sideband attacks in JavaScript allow sandboxed browser code to determine activities outside the browser (recent attack),   and perhaps carefully crafted code will reveal if the platform is responding at the speed and consistency and timing it should. But its unlikely to work well, not least because the server may be virtualized and timings may vary too rapidly for such an approach for that reason, also because too many code modifications and hardware setups have potential to not create user-detectable/remote-detectable variations to any measurable indicator.


Why are private certificates not trusted? When we go to websites that have generated certificates themselves you see this red screen that says do not go there!:

However when it is trusted by some companies it's all good. So I have a couple of questions:

Are certificates that are generated by these companies somehow better/different?
If we take to account that NSA, for example, has every private key of these issuers doesn't it make private certificates actually more secure?

Generally speaking, you are the one who should decide who you trust and who you do not trust. However, this is a tiresome process; in its infinite wisdom, Microsoft (or Mozilla or Google or...) found it fit to include a set of "default trusted roots" that are used by Internet Explorer (or Firefox or Chrome or...).

In the case of Microsoft, the process by which a given CA may enter the inner circle of "trusted by default on most Windows systems" is called the Windows Root Certificate Program. In a nutshell, Microsoft requires that the would-be root CA applies strict and specific security procedures, and has insurance, and legally guarantees that Microsoft will never be blamed (in a financial way) for any mishap. PKI is only 5% technology, and 95% procedures anyway.

If you do not want to follow the Microsoft (or Mozilla or Google or...) road, you are free to adjust your own set of trusted root CA. That's up to you. However, in any case, as long as you use Windows, you trust Microsoft, in the sense that if they want to betray you then they can easily do it, and you would be none the wiser.

If a root CA is controlled by an enemy, then that enemy can issue fake certificates, allowing it to impersonate Web sites. However, running a fake Web site is not easy if you want to do it discreetly; the client's browser will see the fake certificate, and the framing may thus become apparent. For instance, the site owner may connect to his own Web site, and notice that the certificate apparently used by the server is not the one that he configured. In fact, fake server certificates are crude and suitable for fast cons, active for a few hours; they are not a good method for continuous spying, as is the NSA official job. If the NSA wants to engage in wide-scale eavesdropping on people (and I assume they want to do that; that's what their budget is for), then a much more efficient and discreet method is to add some spying hook directly in the operating system. They just have to talk to Microsoft.


Is it possible to assign different UIDs to subkeys for the purpose of having multiple identities? Many people advocate generating new  primary keys for each identity they wish to have.  For example, creating one primary key and associated subkeys for workplace use, and a completely different primary key and associated subkeys for personal use.

But is it possible to generate one primary key, and create multiple subkeys that can each have their own unique UIDs for whatever purpose you desire?  For example, I create two subkeys (one for signing, one for encryption) for work, setting their UID's appropriately, and another two for personal use?  Is it even possible for sets of subkeys to be completely distinct from one another when they come from the same parent primary key?  Would there be a benefit to this configuration?     I've been using GnuPG for a while, and the UID aspect of keys has always confused me.

Consider a single primary key to be equivalent to one identity.

You cannot connect subkeys to user IDs. Both subkeys and user IDs are attached to the primary key, the only connection from user IDs to subkeys is through the primary key.

If you want to select different subkeys for different machines (for example at home and at work), this is easily possible for signing (simply only put one signing subkey on each machine), but again it would not be connected to a specific user ID (but to the primary key).

For encryption, there is no such way, a sender's OpenPGP implementation will usually just choose the newest key (and maybe offer a choice to select a specific key).

Use multiple cross-signed primary keys instead, if you want to separate concerns.


Modern, security-conscious, PHP book? After creating a simple login system and trying to protect it against things like SQL injection, Session Hijacking, XSS, etc, I've found that I really enjoy doing this type of thing. I'd like to pick up a book and dive into all the details regarding PHP / database security and intrusion prevention/detection tactics.

Basically, I'm wanting to learn properly from the get-go. I've found Essential PHP Security, but since it was published in 2005, I imagine they will use things like mysql_ (deprecated) and potential a non OOP structure. I've also been using this page for assistance along with the PHP documentation, but I was hoping to go more in-depth (particularly relating to security).

Can anyone suggest a book that is updated for use today (so...):

Contains information about PDO Connections
Uses prepared statements to escape variables
Uses Object Oriented Approach for structure
Involves HTML templates for separation of languages
Preventing XSS, Session Hijacking, Null Byte intrusions, Cookie stealing, etc.

If there isn't a book that really addresses these things (yet), can the concepts from Essential PHP Security (or another recommended book) still be applied for most uses today?

Thanks for the input! I'm just trying to learn properly and avoid bad habits.

EDIT: I posted this elsewhere at first and a lot of the comments I received were along the lines of "I wouldn't use PHP" or "Use jQuery". Why is PHP security not a good area of focus?

I'm not a PHP developer, so I don't have any specific recommendations, but from my experience I can give some general guidance that may be useful.

First, buy the newest PHP security specific book you can find.   As established as PHP is, and as soft as the technical book market has been for the last decade, there aren't a lot of options, but there are a few out there.   "Securing PHP Web Applications" from 2008 is the newest I've been able to find. The newer books will not only have more up to date information on PHP, but also more information on current attacks and threats.

Second, for more general PHP development education, look for a book with something like "Advanced" or "Technical" in the title, like "PHP Advanced and Object-Oriented Programming" (I have no idea if that specific book is any good.)  Beginner books (in any language or technology) are notorious for including disastrous shortcuts for the sake of simplicity, and rarely if ever worry about best practices...They're designed to show you how to get something working with the least amount of code possible, and it's almost always terrible code.   Advanced books have the luxury of being able to target readers with prior knowledge where best practices are more important than absolute simplicity, and you're far more likely to find a book that incorporates good security practices.

Third, (and this may be obvious) don't rely only on a book for your security information.  Internet resources such as the OWASP website will always be far more current and provide a greater amount of detail around current security practices and threats.


Why would someone want to block images in email? While there is the possibility that this is just to prevent people from viewing offensive images against their will, somehow I don't think that's the reason why pretty much every email client defaults to making the user white list every single email address that sends them images. This level of paranoya screams "security feature" to me.

My question is: is it? And if so, what are the possible problems? Or is it something else entirely?

Several reasons:

The more content in the email that the client loads and interprets, the greater the possibility that the email will deliver a malicious payload. The relatively recent vulnerability in JPEG 2000 rendering code comes to mind -- merely displaying a malicious image could be dangerous.
Images in email are commonly used by spammers and marketers to determine whether or not you've opened an email. This implicitly also tells them whether the email was delivered successfully and whether the destination email address was valid (useful for spammers).
Depending on your mail platform, image downloads may tell the sender the user's IP address.
Image URLs can theoretically be used to attack a network from the inside. For example:

<img src="http://192.168.0.1/apply.pl?user=admin&password=admin&action=EnableRemoteLogin">

Hopefully an attack like the above would fail, but security folks prefer to limit exposure as much as possible.


access control-intersection of subjects’ permissions In the book named "operating system security", I read this paragraph:

  "Protection domains can also be constructed from an intersection of
  the associated subjects (e.g., Windows 2000 Restricted Contexts
  [303]). The reason to use an intersection of subjects permissions is
  to restrict the protection domain to permissions shared by all, rather
  than giving the protection domain subjects extra permissions that they
  would not normally possess."

I don't understand the meaning of "intersection of subjects permissions" and how to use this property.Any idea?

The author is being vague, but may be trying to express the idea of a protection domain that is accessible by two or more persons, without creating a new permission that the persons share.

Assume it exists and has permissions (joe, rw-) (sam r--) and (bob rw-)  If we can also set the permission (~[joe|sam|bob] ---) then we have an unnamed security-domain-like-thing that only they can access.

I would
1. see if that description is consistent with the other descriptions in the chapter/section, and consider
2. writing the author and asking them (:-))


Is it secure to store my mysql password in a const std::string? I am implementing a C++ server with a mariadb backend. I have to access my database and I do so using the mariadbpp (its c++ connector). Though I can use mysql_config_editor and store the passwords in an (encrypted) .cnf file, mariadbpp's API needs a password. This is how I am using it:

mariadb::account_ref acc = mariadb::account::create("localhost", "order", "<password>", "Orders");

The database is configured to only be accessible from localhost. Is putting the password in .cpp source file okay from security perspective?

Hardcoding of secrets is never a good idea.

Use a configuration file, to read from. This way you will be able to swiftly change the password if required and prevent the password from leaking through version control or binary analysis.


WordPress Hacked - Found a suspicious "class-wp-style-table.php" I recently had all of my WordPress accounts on my server hacked. The only suspicious files I found are listed below. These were the only files edited in the last 5 days (June 3, to be specific).

Suspicious files found:

/host.txt - This file only had the wordpress installed domain name in text (e.g.: example.com)
/wp-admin/includes/class-wp-style-table.php - This is a nasty one. See sample of the code in this pastebin.

How can I detect where these files came from to prevent them from being regenerated? I searched Google, and there are 0 hits for this file name. Is this a new WP attack?

UPDATE
I found an exact replica of the malicious file in a Joomla install called "mod_googleapi.php". I think this is the source of my breach. It's a dated install of Joomla that must have some leaky extensions/plugins.

Your server was infected with a PHP backdoor trojan that goes by these names:

a-squared: Backdoor.PHP.Shell!IK
AVAST!: VBS:Malware-gen
AVG: PHP/BackDoor
BitDefender: Trojan.Php.Backdoor.APF
ClamAV: PHP.Shell-38
Dr.Web: PHP.Shell.26
F-Secure: Trojan.Php.Backdoor.APF [Aquarius]
GData: Trojan.Php.Backdoor.APF [Engine:A]
Ikarus: Backdoor.PHP.Shell
Kaspersky: Backdoor.PHP.PhpShell.dd
Microsoft: Backdoor:PHP/Shell.G
NOD32: PHP/WebShell.NAH trojan
nProtect: Trojan.Php.Backdoor.APF

It is currently detected by roughly 38% of AV scanners that VirSCAN.org tracks. The way to test your AV for this exploit is simply by opening this pastebin and trying to download it as a file. Your AV should detect it, notify you of malware under one of those names from above, and deny download. If it's not detected, simply delete the downloaded file. Your system won't be infected, unless you run it through a PHP interpreter on your web server.

I've been reading the exploit's code, and frankly, it's pretty scary stuff and one of the most complete shells I've ever seen. Here are a few things it can do:

Read, Edit, Overwrite any file the web application process it runs in will have access to.
Extract from, Compress to ZIP and TAR archives (can inject itself into existing archives)
Brute-force FTP, MySQL, PostgreSQL access using web server's own CPU
Scripted interface for easy remote C&C shell control
POST requests for everything to hide from simpler WAF and avoid detection by web server rules
Complete Database Control including SQL shorthands for most common injections
Automated password and shadow file extraction for offline password extraction/cracking
File System Access Control including rewriting access permissions on files, directories
Enable / Disable reporting services to avoid detection through log files
Self-Destruction Mechanism to perform cleanup after other backdoors are installed
Password and cookie token protected to prevent easy sandboxed inspection of its functions (albeit the protection scheme is pretty weak, see my comment to the question)
e.t.c.

Presume all your data, file system, operating system, everything infected and other backdoors installed to them. Presume all your passwords stolen, password and shadow files packed and downloaded. This is not a joke!

                               Sometimes, all you can do is...

                               It's the only way to be sure.

So what can you do? Like the image suggests, nuke it from orbit. Start from a clean slate and restore from a known good offline backup, before this exploit happened:

Format the drive and reinstall OS, any other software you'll need, keep them updated
Assume all your installation files infected / out of date and download latest versions
Rethink what software packages you really need, and how you could harden remote access
If you don't have it yet, install a SSL certificate on your web server, use encrypted access protocols on everything
Reassess firewall rules, deny traffic on all ports you won't be using, inbound and outbound
Install a good antivirus software and update its virus definitions regularly both on your server and on all clients that you'll be accessing your server from, enable heuristic scanning, regularly perform full system scan
Never access your web server remotely from an untrusted location and/or unsecured connection like public access points for administration purposes
Secure access to your CMS/panel software folders, files, URLs, password protect everything
Assume all your passwords stolen, including passwords of any users of your online services
Restore from an offline backup from before the date of the infection
Inspect all restored from backup files and database records for injections, trojans, backdoors,...
Write support code in your online services to demand password change for all your users and deny access before they do
Notify all your users their passwords might have been compromised and they ought to change their passwords for any other third-party services they might use them for too
Run each domain on your server from a separate VM and assign as limiting privileges to their processes as you can live with, lock files and database access permissions
Hire an IT security consultant to assess vulnerability of your server and services it's running, act according to consultant's recommendation
Assume I've forgotten to include something in this list, and find more information and recommendations to a similar scenario on this and other websites that you trust

Best of luck!


How to prevent ARP poisoning with hostapd and iptables? I have a raspberry pi and hostapd and iptables are running on my pi. However iptables cannot block the wifi clients from communicating with each other, thus I cannot prevent them from sending out ARP packets with iptables. It's not possible to run one AP for each client on my pi, since I have only one WLAN interface.

Is there a way to prevent ARP poisoning with those tools? If impossible, how to detect it and find out the source of the attack?

You could try to set up a layer 2 firewall via IPTables but I don't see an easy implementation. Maybe you'd like to have a look to ARPTables: https://linux.die.net/man/8/arptables

If you want to detect (not prevent!) ARP spoofing attacks you can use several tools, for example ARPWatch. This tool sends messages to syslog so you can monitor changes on your ARP table. https://linux.die.net/man/8/arpwatch

Also there is an active tool that prevents ARP spoofing attacks on different scenarios (DCHP, static, etc.) although it requires an "agent"
 in each host which may be not ideal depending on your needs:
 https://manpages.debian.org/stretch/arpon/arpon.8.en.html

In any case, and given your scenario (I assume a small home network) another quick fix may be to set up manually the ARP table of your host. For doing so you can use the command (note that after reboot changes will be lost):

arp -s [IP address] [MAC address]

By doing so, you tell your host kernel to associate an IP with a MAC and other requests that will try to overwrite this value will be ignored.
For a more elaborated way of doing this, you could do a script that adds a list of all the IP-MAC within your network that you trust and run it at boot time avoiding possible already-spoofed networks issues.

This has a limitation if you have a host that moves from network to another (Mobile phone or a laptop) unless the script detects the exact network that you're connected to and have multiple lists of trusted IP-MAC. This solution though is highly static and difficult to mantain in large/dynamic enviroments.


Is it possible to find the manufacturer of a BLE device from it's mac address? Tools like nmap are able to identify the make of a device based on it's mac address. Is there a tool or a reference to identify the make of a Bluetooth Low Energy device based on its mac address?

You can refer to this Wikipedia writeup

And yes, Hardware Manufacturer can be identified from the first 3 octet aka OUI

Sources: Wikipedia

What is an OUI then?

An OUI {Organizationally Unique Identifier} consists of a 24-bit number that uniquely identifies a vendor or manufacturer. The 24-bit numbers are purchased and assigned by the IEEE.

If you want to jump straight to searching for Manufacturers based on brands. you could google it. Here are some of the links.

1. Macvendors.com

2. macvendorlookup.com

3. coffer.com/mac_find/

4. Wireshark OUI lookup

5. macvendors.co


return-to-libc can't get the system function address I'm trying to exploit my own code, just to learn how the "return-to-libc" technique works.
I'm following a tutorial which basically says that to use this, I must find the address of the function I want to use.
To remain on classic, I choose to use the "system" function in order to obtain a shell.
My steps in order to find this address are:

run gdb with as argument the name of the executable I want to exploit. eg. "$ gdb test"
place a breakpoint in order to stop the loaded code. Let say "b main" at the gdb prompt
run the code which stops at the breakpoint "r"
get the address with "p system"

This an example of what I did:
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".<br>

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x2779b0** <system>
(gdb) q

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x1459b0** <system>

It seems that each time I start gdb I get a different address?
Can someone explain me why?
Is this a mitigation feature built in my kernel/linux made to prevent this exploit technique usage?
Later, googling around I finally found something that fits a little my scenario.
It seem to exist a feature called "Kernel address space layout randomization" which is similar in some ways to what I'm experiencing.
However, if I understand completely what this Kernel address space layout randomization is, I should experiencing this beaviour once each time I reload the kernel, instead I have this behaviour each time I start the code through gdb.
Infact, building the following simple code the experienced weird behaviour seem not be there:
#include <stdio.h>
#include <stdlib.h>

int main()
{
 printf("%p\n", (void*)system);
}

This code should output the address of the system() function.
Testing it, it produces each time the same address.
It seems this strange behaviour is some how related to the gdb, but I'm not sure....
I'm confused.

It seems I found an answer myself, at least a sort of.
Well, as I suspected, kernel developers are very far away from me.
Indeed the "Address space layout randomization" seems to produce the behaviour I observed on my system.
When I read the wikipedia article, I understood address space is structured once each time kernel starts, but testing it I verified that actually things are slightly different.
GDB has a neat feature called "disable-randomization" which is on by default.
In spite that, libc system(), and I guess any libc function, changes its address each time I start GDB.
Digging deeper I finally found that kernel feature may be disabled at kernel level through "/proc/sys/kernel/randomize_va_space".
My kernel by default was set it to the value 2.
Setting it at 0, I realized the randomization stops.
Everything seems clear now, but there's still a piece which does not fit.

Why the code I wrote to print the libc system address, when I run it
from the prompt produces any time the same address?
Is the code I wrote, that do not request the feature producing this
result?

UPDATE
if there's someone is good enough, I'd like this guy to explain me this:

$ cat /proc/sys/kernel/randomize_va_space
0
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x00843000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00dcd000)
        /lib/ld-linux.so.2 (0x0037b000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00ab7000)
        /lib/ld-linux.so.2 (0x00f14000)


Is WPA-PSK of IEEE 802.11 insecure if PSK is exposed? In WPA 4-Way Handshake, SNonce, ANonce, AP MAC addr and STA MAC addr are exposed to an eavesdropper Eve. But I think it is still safe unless PSK (password) is exposed to Eve.

If PSK is exposed, however, I think connection is not secure any more since Eve can acquire all parameters to derive PTK. (PTK is a function of PSK, ANonce, SNonce, AP MAC addr, and STA MAC addr)

Is my understanding is correct?

I ask this question because some shops provide free access point service in WPA-PSK mode and they expose a password. In such a case, I think using such free access points is not secure any more, even though they are operating in WPA-PSK mode.

I have no knowledge about the details of WPA implementation, but what I can tell from basic knowledge: if you expose the Pre-Shared Key, then anyone can simply log on to your network, without needing that other handshake data. And if he actually wants these, he'd do a wireshark monitoring of the logon.


Can open source software be digitally signed? I've read that installing Linux on UEFI PCs requires additional steps to disable the requirement for digitally signed bootloaders.

But I thought that open source software can be digitally signed by using the private key to sign the source code and releasing the public key, and doing the same for the compiled software?

While you can sign the software this does not mean that you can store the public key needed for signature validation in the device which should do the verification. Just releasing the public key does not make it magically available on all places which need to do the verification.

In case of SecureBoot the UEFI system which needs to validate the signatures is not open source. And even if it would be open source this does not mean that systems come pre-installed with the key you used for signing. In the existing implementations some vendors allow you to store your own keys for validation and others don't. This means that every user of the signed software has either to disable SecureBoot or add the key you used for signing, if this is possible at all. Since both of these option are too complex for the average user it would be much better if one could use one of the keys already known by the implementation for signing. This of course means that you need to have access to the related private key.

The current workaround in Ubuntu is to have a small shim signed by someone which has access to the needed private key (i.e. Microsoft) and then boot the rest of the system from there. See Ubuntu Wiki: SecureBoot for the technical details.


E-mail Server Security In recent news, Bitcoinica was compromised by an e-mail server infiltration. The hacker then applied social engineering, using one of the administrative e-mail accounts to reset the root credentials on the database server, subsequently hijacking the virtual bitcoins as a result.

What initiatives can an administrator apply to ensure that his e-mail server remains secure, mitigating the risk of hack attempt(s).

To be honest, this question is generally a duplicate of questions such as this and be generally answered by looking at this hardening tag.

Just to add to the great points made by DKNUCKLES.

Regarding IDS/IPS, I personally wouldn't use a HIPS/HIDS on an email server. Email servers generally work pretty hard (due to AV, content-filtering and other checks on emails flowing in and out of an organisation) and having managed email servers, HIPS/HIDS wouldn't be for me.

I would use NIDS (most likely Snort, I'm not familiar with Suricata) and have it configured like a true Network Security Monitoring solution so I've visibility of what's going on in the network.

Additionally, I'd not only have the email server hardened as per the best practices in the links above but also have it segregated in a DMZ with outbound restrictions (i.e. connections to the Internet and back internally so that it can only talk to specific devices that it needs to (this is generally following defence-in-depth principles and layered security). Some papers from the SAN Reading Room on it - 1, 2, 3. You don't want the email server being used as a pivot point to attack more valuable elements of your infrastructure so its ability to do stuff needs to be restricted.

From a protocol perspective for downloading emails to the client, ensure that IMAP over SSL is used rather than POP, which is a clear-text protocol.

Ensure your sysadmin accesses the email server (for administration purposes) in a secure and controlled fashion.

On a a possibly unrelated note, configuring your mail server to always take certain actions (such as encrypt or block) when you see email going to a certain recipient or from a certain internal person or based on certain content can save unintended data leakage and other security issues.


Dirty and clean interface on DMZ gateways We have a webservice border gateway in DMZ which handles incoming and outgoing webservice requests in terms of authentication and security.

We have two network interfaces in place, on is called 'dirty' and is used for traffic to and from the internet. The other one is called 'clean' and is used for traffic to and from the intranet.
However, the dirty interface has still an internal IP address. There is a public IP address configured on the firewall which performs NAT to forward requests to the dirty interface.

I'm wondering now what the benefit of such an architecture is. Is there really an advantage in having a dirty and a clean interface? I could see the advantage in security if the dirty interface has directly a public IP address but in our scenario I don't get the benefit of splitting clean and dirty traffic...

Since your DMZ host is basically a firewall, the design you described does not make sense, you are completely right. This is no better than one-interface firewall (which is the weakest possible architecture).

When using a 2-interface firewall, the two interfaces have be on different networks - e.g. "internet" and the DMZ or the DMZ and the intranet.

At the same time, this confused design does not really do any harm, perhaps this is a historical archecture mishap of some kind.


Can I do a String Format Exploit for x64 systems? I was trying to replicate the experiment in Gray Hat Hacking - Third Edition, Chapter 12, about Format String Exploits, but their architecture is IA32, while mine is AMD 64bits. Therefore when I check for values in stack with commands like:

$ ./fmtstr "AAAAAAAA %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x"

Nothing showing up, that resembles its representation in memory (41414141 41414141). Why is the exploit buffer not returning actual and sequential memory data?? For more info please see his console image Help!.

If you're using the example code from the book (below), at some point you should reach the "AAAAAAAA" pattern (0x41). Note that, since you're running it on a 64-bit machine that stores elements in the stack with 8 bytes each, you should run it with $ ./fmtstr "AAAAAAAA %016x %016x %016x %016x %016x %016x %016x %016x %016x %016x %016x %016x %016x" instead, or you will miss part of each element on the stack.

#include <stdlib.h>
int main(int argc, char *argv[]){
        static int canary=0;   // stores the canary value in .data section
        char temp[2048];       // string to hold large temp string
      strcpy(temp, argv[1]);   // take argv1 input and jam into temp
      printf(temp);            // print value of temp
      printf("\n");            // print carriage return
      printf("Canary at 0x%08x = 0x%08x\n", &canary, canary); //print canary
}

You should pay attention to the quote in the book that states:

  The  fact  that  the  fourth  item  shown  (from  the  stack) was our format string depends on the nature of the format function used and the location  of  the  vulnerable  call  in  the  vulnerable  program.  To  find  this  value,  simply  use  brute force and keep increasing the number of %08x tokens until the beginning of the format string is found. For our simple example (fmtstr), the distance, called the offset, is defined as 4.

Remember that the parameter being parsed to printf isn't the string itself, but the address of the string. So it's position on the memory layout of the program in relation to the printf stack is what will define how further you'll have to search to find it.


Brute force on Hydra with non-ASCII usernames and passwords I use Hydra with the Web-Form (Http-Post-Form); and I'm trying to use a list of Usernames when some of the nicks contain a letter ñ.
For example I have the following account in my list:

Username: ñandu123
Password: asd123

The script that I run is something like this:

hydra -L usernames.txt -P passwords.txt www.xxxxx.com http-post-form "/login.php:log_user=^USER^&log_pass=^PASS^&Enter.x=0&Enter.y=0:ERROR."

Inside the usernames.txt and passwords.txt (encoded as ANSI) is already the account of "ñandu123" but the script never detects it. It works well with usernames without an special char but not when I use this letter "ñ".

I don't know how I can make the script to detect these special chars inside my list files.

If I use the word "ñandu123" directly the script works well (-l ñandu)

hydra -l ñandu123 -P passwords.txt www.xxxxx.com http-post-form "/login.php:log_user=^USER^&log_pass=^PASS^&Enter.x=0&Enter.y=0:ERROR."

But not when I use the username list.
And I cannot do this "one by one" because I have more than 200 usernames, so I need the list.

This seem linked to language environment:

You could try:

LANG=C LANGUAGE=C hydra -L usernames.txt -P passwords.txt \
  www.xxxxx.com http-post-form \
  "/login.php:log_user=^USER^&log_pass=^PASS^&Enter.x=0&Enter.y=0:ERROR."

or

recode lat1..u8 <usernames.txt >usernames.u8

or if usernames.txt is already UTF-8:

recode u8..lat1 <usernames.txt >usernames.lat1

Then again.

LANG=C LANGUAGE=C hydra -L usernames.u8 ...


Are long-lived SSL/TLS certificates acceptable for non-public resources? Our organization maintains a private certificate authority to issue SSL/TLS certificates to non-public backend services running on our cloud infrastructure. For example, Postgres and Elasticsearch servers running on a private vnet.
Currently we issue these certificates with a 2 year expiry, but the renewal process is manual and we don't have the resources to work on automating it. Given the certificates are only used within a private vnet, are there any significant risks associated with extending the expiry to 5 or 10 years?

Afaik, 1 year limit is only for CAs that participate in CAB Forum. Compliant clients differentiate public CAs and private CAs and apply different rules. That is, compliant browsers won't alert on a 2yr TLS certificate from private CA (as long as it is trusted). A quote from CAB Forum page:

You might also consider moving some certificates from public to private trust, which also helps with management – you could even issue certs with longer validity using that method.


Authenticated Sessions on a Desktop Application I want to implement a login into my C++ desktop application and I'm having a hard time finding information on managing login sessions without cookies or JWT (JSON Web Token) (more on that in a bit). I can send HTTP requests from my C++ app just fine as well as incorporate TCP sockets if needed.

Here's a typical user workflow:

Register for an account on my website.
Pay for access to a desktop application.
Download and log in to the desktop application.
Desktop application sends data (~1MB) to server API to be processed.
If the user is authenticated and has sufficient funds, processed data is returned.

Some requirements:

Session storage so users don't have to log in every time.
Close all other sessions if a log in occurs from a different IP.
Ability to log in to the website to view usage stats and edit account info.

Because of those requirements, I shouldn't use a JWT because I can't revoke or invalidate tokens without storing sessions server-side anyway. I also can't use cookies because the log in is not (always) happening in a browser.

Almost every guide or tutorial I've found online for MERN (Mongo, Express, React and NodeJS) stack authentication and session handling involves either tokens or cookies. I want to use neither.

How would I begin to implement server-side sessions management and user authentication inside a Node app when the log in can happen from a browser OR a desktop application?

Thanks for your time!

When the desktop application logs in at the server, at the server create a guid/token/authorization key and store it in the database together with the associated account. Then return the token to the desktop application. The desktop application stores the token (maybe even permanently in a file or registry). With every request it sends the token to the server. The server looks up/checks in the database the associated account (and if the token is deleted) and checks the funds and processes the request. If the session should be closed/ended mark the token deleted in the database.

You can also use the tokens in cookies for authentification.

Btw. binding sessions to an IP-address is a bad idea like mentioned many times on this site like when the user switches between mobile internet and landline internet or for many other different reasons.


Key rotation for shared secret keys - recommendation When using software that does encryption using shared secrets what are the recommended practices for changing the keys.

To be specific, this is a distributed software running in a cluster and the communication between the nodes is encrypted using a shared secret. The clustering software in this case uses the eventual consistency model and there is no designated leader.

There is an out of band mechanism for all the nodes to learn the key. I am considering an user option to designate one node to do the key change.

when using shared secrets is it a must to provide an option to do key-rotation ?
Assuming it is must, is it better to do it periodically (like once in 2 days) ? How often is too often for key rotation ?

If your shared secrets are of sufficient entropy there is no need to rotate the key to protect against brute force attacks. For example, if you're using AES-128 to encrypt the data in transit, then if you have a completely randomly generated 128 bit key this will be infeasible to ever brute force.

One area of concern could be your backup procedure. Is it guaranteed that any backups of your systems could expose the secrets to those that should not have access? For example, where are they physically stored and is logical access restricted by ACLs or encryption? This is one reason why key rotation might be useful - to prevent any old backup data that is discovered by an attacker from being used to attack the current system.

The other area of concern is your encryption algorithm isn't of high enough strength. An observer on the connection may be able to capture enough traffic to calculate the key. It would be recommended to use a strong, secure cipher though, rather than rotating keys.


How can a non-admin program cover your entire screen with a window? This year, since many students are online, College Board (the company that administers AP Exams in the US, along with the SAT) recently released its Digital Testing App. Once installed, and going through a setup, it allows you to go through a test demo to mirror the actual test conditions. However, once you do, it covers your entire screen and prevents you from ALT+TAB to another window. The "select window" UI still shows up, but if you actually try to switch, the Testing App window still remains.
This ability could make sense if the program was given administrator privileges on install (like Respondus Lockdown Browser, I believe), but the Testing App wasn't, and yet still could. This could just be a trick like just a really big window, but I'm not completely sure. Could anyone shed some light on this and how could they do this?

Fullscreen is easy: The vast majority of video games, for example, do it.  I don't know if Windows has a dedicated API call for this, but if it doesn't, it's easy to fake: Just make a screen-sized window with the "Always on Top" attribute and no window decorations.
Disabling ALT+TAB is harder, but there are a number of options: for example, the accessibility toolkit lets you intercept arbitrary keystrokes. The only key combination that no application can disable is CTRL+ALT+DELETE.


Origins of the "man-in-the-middle" analysis Who first formulated communication security in terms of the "man in the middle" attacks?

I am writing a book on the history of computing and communications.

The earliest source I have so far is:

Larsen, Gerald H. “Software: A Qualitative Assessment, or The Man in the Middle Speaks Back.” Datamation 19 (November 1973): 60-6.

After a couple minutes in Google, I find that Leslie Lamport appears to be the first to talk about MitM analysis in terms of communication security.

The work was published in 1981, but there is evidence of his thoughts on the matter as early as 1979.

First published work describing the ideas: here.


How to protect against USB malware? What measures should I take to avoid any infection through USB devices?

For example, there is a tiny virus called shortcut which hides your files and put shortcuts instead. I was wondering if there are some special measures besides the traditional ones (updated antivirus, firewall...)? Should we disable them and enable on demand or set privileges on them, what do you propose?

To avoid any infection you should remove the USB ports.

Here are some measures one might take to minimise the probability of an infection:

1.) Provide users with USB devices. Allow only those devices to be used.

2.) Disable autorun for USB devices.

3.) Disallow the use of U3 devices.

4.) Allow only specially trained users with the permissions to transfer files between USB devices and your network. Those should know the procedures to minimise the probability of transferring infected files to your network (e.g. scanning the files beforehand).

5.) Allow the use of USB devices only on specific, air-gaped computers. Check files for malware before transferring them to your network.


How to forward HTTP/SOCKS proxy on same port to SOCKS server? I have socks server (TOR) and can "convert" it into HTTP/HTTPS one via Polipo or something like this. But I want to use it transparently as HTTP or SOCKS on the same port.

I have experience with this behavior from various paid reverse proxy services.

Maybe something like one more "proxy" level which will forward connection to original TOR instance (9050) or Polipo depends on protocol?

Thanks!

If you want to run any program through proxy server without setting proxy (with network api-hooking) you can use to ProxyChains .

If you want to forward your website or any protocol on specified port and accessing without proxy (Transparency) you can use to DeleGate .


Is it possible to scan a remote host in another network if I know a port that is opened? First of all, this question is not the same as is it possible to test out remote host by using nmap?, because on that question, the questioner is asking for something impossible due to NAT's nature.

My question has the same goal, but going a little further. If I know that a host has the port 12345 opened for some reason, can I perform a scan which uses port 12345 to send the packets (so the packets go to the intended host due to port-forwarding) and be able to receive which ports are opened?

I believe that you are asking if you can take advantage of traffic for targethost port 12345 being allowed in order to scan other ports on targethost aside from 12345.

The answer to that question is essentially "no".

Is the answer ever literally "yes"?  Actually, yes.

Once upon a time, it was possible to fool some packet filters and weak-brained firewalls into passing traffic.  If I recall, the method was to send a series of overlapping packet fragments.  The packet filter (often a router) would look at the first fragment and say "Ah! Port 12345!  I allow that, come on in!" and would pass subsequent packets without examination.  But what if the second packet fragment had an offset that overlapped where the destination port was defined?  The targethost, unlike the packet filter, is going to reassemble the packet before parsing it to determine what port it goes to.  If the targethost resolved the overlapping fragments by overwriting the original fragment (the port 12345 fragment) with the subsequent fragment (say, listing port 137) and boom!  Assuming the response packet can get out (again, something packet filters tend to do, modern stateful firewalls tend not to do) then it would be possible to scan arbitrary ports behind a firewall, piggybacking on a single permitted port.

Modern firewalls aren't that stupid, so it's generally not possible to do what you want to do today.

(It also used to be not-uncommon for packet filters to pass traffic by source port.  Yeah.  It makes handling things like DNS and FTP easier when you don't have an application-aware stateful firewall.  It also allows anybody who wants to to connect right through your firewall, as long as they source their packets from (say) port 53 or port 20.)


Is it possible to get all the data I send through wifi? Is it possible, that the network administrator (wpa2 wifi network) can log all the data the users send and then get password out of it?

I know it is not possible to get the password if I'm surfing with https but what if I only use http pages?

On any Wi-Fi network - encrypted or not, given today's Wi-Fi encryption protocols - any sufficiently skilled and equipped user of the network (and especially the network administrator) could easily access any data you transmit or receive via cleartext protocols.  This includes usernames and passwords as well as web pages, documents, and other data sent or obtained via http, ftp, telnet, etc.

For open networks, gathering cleartext data is as easy as sniffing the traffic in the air.  WEP security adds a slight barrier, but is still easily decipherable by even unauthenticated users.

WPA and WPA2 require a good bit more computational power for outsiders to crack, and much more time.  For these, an attacker would most likely monitor traffic for awhile and then take the data home for offline cracking.  As with just about any cryptography, brute force will always win if given enough time.  With WPA and WPA2, that just means a lot of time.

There are side-channel attacks to WPA and WPA2 though.  Currently, the Wi-Fi Protected Setup (or similar) features in most SOHO routers has a weakness that will allow an attacker to gain access to your network in fairly short time.  Once they've cracked your key through this method, they can join the network like any other user (provided you don't have other protections - most of which are trivially bypassable - in place).

For WPA and WPA2, there are known weaknesses that allow authenticated users (or attackers who have broken into the network) to sniff traffic as if it were unprotected.  At this point, the only defense you have is encryption at higher levels of the network stack (i.e.: HTTPS).  Even then, many of these higher-level protocols can be subjected to man-in-the-middle (MitM) attacks if the victim is less than vigilant in verifying their SSL certificates (or the attacker has a certificate from a compromised CA).

The only real additional threat that a malicious network administrator would pose, is that they have access to the wired side of the network also.  On the wire, traffic is not protected by the same encryption (WEP/WPA/WPA2) that applies to the wireless connection.  Anyone on the wire could then sniff your traffic as if it had been sent across an open (unprotected) network on the air.


Self Signed SSL Certificate - How to verify it correctly on the client side? For our current implementation we are using a self signed root certificate, which then is used to sign ssl certificates for our secure http connection.

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

Is it enough to store the thumbprint of the SSL certificate on the client in a secret vault and then check for compliance in the callback function during the https handshake? Cosidering that it might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)? Am I wrong or is it that a standard x.509 certificate can't guarante me that the data hasn't been tampered with?

Wouldn't it be safer to store the public key of the root certificate and use this to check the thumbprint for yourself?

Does this justify the additional overhead for each initial request?

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

In this case you cannot validate against the root CA but must trust each certificate by its own.

  ... might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)?

The thumbprint or fingerprint of a certificate or public key is a cryptographic hash over the certificate containing the public key or the public key alone. Since the secret private key must match the public key in the certificate and an attacker has hopefully no access to this private key (wouldn't be private anymore then) it is practically impossible for an attacker to create a certificate with the same fingerprint AND have the private key for this.

Since ownership of the private key of the certificate is checked during the TLS handshake this means it is sufficient to check the servers certificate against a stored fingerprint - provided that this fingerprint was created using a secure hash like SHA-256 and not an insecure one like MD5. But of course the application could also store the full expected certificate or public key and compare it.

  Does this justify the additional overhead for each initial request?

I don't think that there is any noticeable difference between comparing the fingerprint or comparing the full certificate. If there is any difference at all then comparing the full certificate is probably the fastest since there is no need to create the fingerprint from the certificate in order to compare it.


Should a startup use a VPN? I see many big companies using VPNs to secure traffic between their empoyees' computers and their servers or just between different servers.

At what point does that become necessary for a smaller-scale company?

I guess the best answer should be to do an in-depth threats and risks analysis, but is this something many startups (or SMEs) set up?

Also, how often do companies set up VPNs between servers in the same datacenter? For example, we have several dedicated servers at OVH, with some services speaking cleartext (Redis for example), what is the risk of interception?

A VPN allows two different entities separated by out of control network elements to be seen as members on a single controlled network (definition of Virtual Private Network). So:

if all your servers are on same LAN inside your own building, then you do not need a VPN between them
if employees only use ssh to connect to a server, then you do not need a VPN for that access (ssh already offers an end to end security)
if you have different servers in a datacenter, and you have no control whether other servers share the same network, then a VPN to isolate you servers exchanges would make sense.
if you need to use various protocols between your employees's computers and your servers, and the exchanges and not limited to your LAN, then again a VPN would make sense


Securing HTTPS between two local applications on same system I would like to know how to securely setup HTTPS between two applications running on the same workstation in a production environment please:

A local server application (C#)
A web frontend which accesses the local server through a browser (packaged as an app using Electron and talking to the local server over HTTPS)

The user enters a username and password into the web frontend that forwards the details over HTTPS to the local server. In this instance, the server is acting as a proxy for an online API that provides the actual authentication.
The apps will both be run by users who are not a local admin on the workstation. Note that the local admin is trusted.
My current plan is to:

Generate a self-signed certificate and key store for HTTPS.
During installation of the app, which will be run as an admin, install the self-signed certificate in the OS trusted certs store.
Bundle the keystore in the local server application, which will serve HTTPS content using it. I wasn't planning to password protect the keystore as that seems security by obscurity since the application will need to contain the password to use it.

I specifically want to protect the usernames & passwords entered when users log in, as well as preventing any snooping of traffic during a session by other users.
Regarding username & password: I do have the option of authenticating directly with the online API from the frontend app and only passing an auth token to the local service. I'm not sure whether that is necessary.
The admin user is trusted so I believe a MITM attack using a tool like Fiddler would not be possible since you'd need to have admin rights to install the root cert it requires. However, given the unencrypted keystore would be available to all workstation users, would that allow them to snoop on the connection?
Also, one potential weakness is that all users will have physical access to the system, so I guess could elevate their privileges somehow (e.g. as mentioned in https://security.stackexchange.com/a/82673/249586). I'm not sure how I would mitigate against that if that is possible.
Is this design secure enough to use to send username and password to the proxy? Are they any improvements/changes I should make to the design to make it secure? (I'm not able to use sockets as suggested by other SO answers).
Thank you!

There is no point in using HTTPS here.
Since the server and client are both on the same system, communications will occur over the loopback interface, which means the traffic will never leave the machine. To intercept the traffic on the machine itself, the attacker would need administrator privileges. If someone has admin privileges, its already game over.


Risks associated with compiling open source projects After reading this question about if it's safer to download and compile the source for an open source project or download and run the installer, I thought of another possible vulnerability: is it conceivable a compiler could be designed to leave a back door (or other malware) inside a file it outputs? In other words could the compiler used to compile the source code be compromised? The only way such a thing could be caught would be to dissasemble a compiled executable and compare the code with the original. This would be very difficult.

Also you would need a preexisting compiler to compile an open source compiler. Is it even theoretically possible to have a system that is all open source software and the computer owner (or a group of trusted people) has reviewed the code for the programs used?

Yes, the compiler, as any other program that executes code on your computer, can be used to add malicious instructions in a program, before or also after compiling it (e.g. ELF header and sections manipulation).


Can't find cause of malware in Wordpress site - adding html files with redirects I'm helping a non-profit and they have had malware on their WordPress site. I installed Sucuri and it quickly finds some strangely named HTML files in the base directory. I removed those files. Because of the malware found, the non-profit was blacklisted on 3 different spam sites (mxlookup search). I had updated all of their plugins, WordPress software, themes. I had removed unused themes and removed other users. They finally got off of the blacklists, but then today Sucuri found another malware file.
The file is always in the base wordpress directory and named with random characters (e.g., QPez2ejsEdss.html) and the contents is this:
<meta http-equiv="refresh" content="0;http://SOME_STRANGE_WEBSITE/">

Where SOME_STRANGE_WEBSITE is clearly a bad website.
What tools can I use to find the dropper of the malware?

Is it a Windows server or Linux ?
Did you run an AV scan to see if the server is not infected ?
What's the open ports situation ?
Since it's a web server , do see any strange open ports besides ports 80,443
Temporary solution
You could run a script to scan wordpress directory and delete malicious files while logging it
#!/bin/bash

now=$(date)

while :
do

  counter=$(grep -rnw '/var/www/wordpress/' -e 'SOME_STRANGE_WEBSITE' | wc -l)
  if [ $counter -gt 0 ]
    then
      echo "Found $counter malicious files on scan runned at $now" >> /home/no_root_user/log.txt
      ADD YOU LINE TO DELETE THE FILE EVENTUALLY HERE
    fi

  sleep 5
done


nmap scanning - What is the difference between -sP and -sn? On the Nmap home page in my language, I can see -sP scan, but on the English version of the site, I can't see it. But I see -sn that looks very similar, I want to understand what's the difference.

There is no difference.  To quote man nmap:

In previous releases of Nmap, -sn was known as -sP.


Cross Site Scripting href=/\evil I've seen

<base href=/\evil>

and

 <base href=//0>

as a vector to use XSS. Could someone make an example using these vectors and explain me if "/\" is the same as http:// or has some special meaning?

Thanks.

// is just the start of a protocol-relative URL. From this site, //google.com would take you to https://google.com. From a plain old http site, //google.com would take you to http://google.com (which would likely bounce you to the https site, but that's not tangential).

The  tag itself will set your relative URL interpretation to another domain. so with that above base tag in effect,  Login on your site would not take you to your login page, it would take you to http://google.com/login. While google is benign, you can see the potential problem.

In terms of your exact question, I'm not sure what the point of either example you provide is, as-shown, other than just to break your site's links. A malicious use would have to list another destination in the base tag. to be of use.


Will a DDOS attack prevent outbound traffic? Imagine a scenario where there is a DDOS attack against a target - clients would be unable to connect to the target, but I would like to know if the target could initiate a connection to the outside, and then have the response get through due to it being of a higher priority (since it was a requested connection vs an anonymous request)?

edit: for this scenario assume that the (single) pipe is filled, while the server/firewall is dealing with the flood just fine

alternatively, if there is an existing connection, say a site-to-site VPN tunnel, would it be impacted? (again, assuming only the pipe is filled, while the equipment can handle it)

Answer (like a lot of answers in info sec): It depends.

If the DDoS attack is swamping the network infrastructure, it may be difficult for an outbound packet to make it through (even with higher priority) because the network switches and appliances might be too busy to process it. On top of this, if it is a TCP connection then it'll need the reply packets to return too before the connection can be established.

If there is another network interface with a route to the outside, then there may be more of a chance for the outbound connection to be established via this other route. This of course depends on how the server itself is holding up against the DDoS attack.


Authentication without sending password over network I was reading this question about ssh authentication and there's a good discussion about authentication schemes. First, there's the answer that yes, ssh sends the full password to the server (but inside the encrypted tunnel). Second, there's talk about alternatives.

They talk a lot about the idea of sending the hash of the password instead of the password itself, but I haven't found anyone mention the following scheme:

The server sends a nonce to the client.
The client encrypts the nonce with a key derived from the password.
The client sends the result back to the server.
The server encrypts the nonce with the same key and compares its result to what the client sent.

This fulfills the objective of having a password-based authentication scheme where the password is never sent to the server during authentication, not even as a hash. (It does have to be sent once, when setting up the account.)

My questions are:
a) does this work?
b) does anyone do this?
c) is this any better than sending a hash?

I include the last question because I realized that having seen the nonce and its encrypted result, you could brute-force the password just like you could brute-force the hash. Is this the Achilles heel of this scheme?

You are basically describing Digest access authentication. Only that it is not "encrypts the nonce with a key derived from the password" but that the nonce is hashed together with a value derived from the password. The basic idea of not sending the password but instead a response based on some server challenge and the password is the same though. The weakness is also the same: the server needs to know the password or some equivalent and thus cannot store it securely.


Persisting and comparing NMAP scans Does anyone have any good recommendations on a good tool for persisting NMAP scans to database?

It may be a tool for persisting or simply a java library for easy parsing of the nmap xml scan result into a good object structure.

It would be very nice if the tool could also compare scans to easily check for differences between one time and another.

Any recommendations? I'm currently writing my own, but why invent the wheel if it's already been done before.

UPDATE: The tool has to be able to take NMAP XML, and must not rely on using the scans itself.

I've now written my own nmap scan parser. Unfortunately the tools listed in the answers, and the tools Ive tried have not been what I've needed. I also been using some nmap script output aswell which needs to be stored in a way to allow easy aggregating of data. I found that writing my own script was easy enough to deal with my situation.

Thank you for answers!

UPDATE: Source code can be found here . Anyone wanting to participate can send me their email, and I'll add you.


Whats the difference between MAC vs hash What is the difference between the two algorithms?
One difference that I know of, is that MAC is keyed and hash is not.

A cryptographic hash function is a completely public, deterministic hash function which everybody can compute over arbitrary inputs. It takes as input a sequence of bits (any sequence of bits; some hash functions are formally limited to inputs of, say, less 264 bits, aka "2 millions of terabytes") and outputs values in a rather small space, typically a sequence of bits with a fixed size (e.g. always 160 bits with the standard hash function SHA-1). Good cryptographic hash functions respect some conditions which boil down to, informally, that they mix input data so thoroughly that we cannot figure it out afterwards.

A message authentication code is an algorithm which takes as input a message and a secret key and produces a fixed-sized output which can be later on verified to match the message; the verification also requires the same secret key. Contrary to hash functions where everything is known and attackers are fighting against mathematics, MAC make sense in models where there are entities with knowledge of a secret. What we expect from a good MAC is unforgeability: it should be infeasible to compute a pair message+MAC value which successfully verifies with a given key K without knowing K exactly and in its entirety.

Hash functions and MAC are thus distinct kind of algorithms with distinct properties and used in really distinct situations.

Some MAC algorithms (but certainly not all of them) can be thought of as "hash functions with a key" but this is a restrictive view. HMAC is a well-known MAC construction, which itself builds on an underlying hash function in a smart way. Indeed, security properties and models for hash functions and MAC are sufficiently distinct from each other that slapping a hash function and a key together does not necessarily yield a secure MAC, even if the hash function is secure (see the length extension attack which illustrates that point).

To some extent, we can state that a MAC algorithm which can operate securely without an IV must exhibit some hash-like properties (that's the reason I like HMAC: without an IV, it is much harder to get it wrong when implementing it). However, the Devil is in the details.


Biometrics for screen locks vs encryption I've always argued that, while biometrics can be a step in the right direction for basic passwords/hashing setups like computer or phone lock screens, especially when combined with multi-factor authentification, I have yet to see any value in the technology as far as encryption goes. Thus, my question is twofold:

Can a file be symmetrically encrypted using something like a fingerprint? If not, does it just have to do with a lack of available data points, or is there some other explanation?
Could something like multi-factor authentication exist for symmetrical encryption, such as requiring data from both a password and fingerprint?

Can a file be symmetrically encrypted using something like a fingerprint? If not, does it just have to do with a lack of available data points, or is there some other explanation?

You could scan a fingerprint, and use that file as a key. It's a terrible idea however. A fingerprint is relatively easy to obtain, and nearly impossible to change. A brute force attack on this type of key is probably quite effective too.

  Could something like multi-factor authentication exist for symmetrical encryption, such as requiring data from both a password and fingerprint?

Two-factor authentication relies on two things. One is something you know (the password), the other is something you have or something you are (in pratice, that means biometric data). In a sense, this would make a second part of the key.

Biometric data, due to the fact that it can't be changed, is a poor part of a key.

Something you have could work - the recipient of the encrypted message could be given a black box that contains part of the key. Or you could use a device that uses a challenge-response protocol.
The difficulty is that the recipient must be given this black box ahead of time. If the amount of data you want to communicate is limited, you might be better off giving them a one-time pad.
But it is an option - I know of at least one bank that issues a device that, when presented with the bank pass and proper PIN code, allows the user to get in a challenge-response protocol to prove their identity for a transaction. A similar mechanism could be used for releasing part of a symmetric encryption key.
Whether or not that is efficient is an open question, as that part of the key itself would need to be communicated via a secure channel.


How to predict C rand()? Is there a practical way to predict previous/next C rand() output if i have some of the values? How many values do i need? Do they need to be consequent? If it depends on compiler - for which implementations is it possible and how?

It depends on the rand() implementation... the standard (POSIX / Single Unix) gives a sample implementation but any system is free to have something better.

You can see the sample code there. If that exact code is used, then the internal state is a 32-bit integer, and it suffices to get two successive 16-bit output values to recompute the internal state. Actually, any 32 bits of output are sufficient, with the generic reconstruction algorithm known as "brute force": it won't take long, for a computer, to try all possible 32-bit internal states until one is found, which matches the observed output. It is possible to recompute the state waaaaaaaaay faster by doing some linear algebra, but since brute force works well, why bother ?

In usual Linux systems, rand() is an alias for random() which is much better, but still not "good", as far as randomness goes. The srandom() function still initializes the internal state with a 32-bit seed, which is amenable to brute force. You just lose the linear algebra shortcuts; or, at least, things require a bit more mathematics. random() is not a cryptographically secure PRNG and its internal state can be rebuilt by observing some output bits. The simplest method is still brute force, and it works well.

(Also, if the application did not bother to call srandom(), then the initial seed is always 1, so brute force will work very well.)


How can hackers find buffer overflow without source code? I am a student in networking, we learn cybersecurity, but we don't learn buffer overflow vulnerabilities in depth, I understand how it works, but I don't understand how an hacker can detect this vulnerability. Is that very difficult or can be done easily with some techniques ?

There are a number of ways. Probably the most common ones, though are fuzzing and reverse engineering.
Fuzzing is a form of automated security testing where a program that consumes untrusted input (such as a file parser, driver that accepts IOCTLs from less-privileged code, network server, or network client that connects to untrusted servers) is repeatedly subjected to algorithmically-generated inputs. There are several variants of fuzzing, such as mutational fuzzing (where valid inputs are mutated randomly before testing) and generational fuzzing (where the fuzzer is given a description of the expected data format and then generates inputs that approximate, though do not necessarily follow, that format). Fuzzing can also be anywhere from completely random changes to fully deterministic for a given data specification, though most fuzzers are somewhere in between (they use some logic to determine interesting locations within the input, and interesting values to change them to, but the actual details are randomized). This randomness means that fuzzing usually can't exhaustively test a program, but it's a highly effective way to find vulnerabilities nonetheless.
The program being fuzzed is run under a debugger that will detect when, where, and why it crashes (or exhibits other undesirable behavior, such as becoming unresponsive or using exorbitant memory). Even without debug symbols (much less source code), it is usually possible to determine what kind of exception the program encountered, which security researchers can use to estimate the likelihood of exploitability (for example, an NX violation where the process tries to execute a non-executable address, or a write access violation / segmentation fault where the program tries to write to a read-only or unmapped address, are both likely to be exploitable). In every case of a crash or other indication that the program failed to handle the input, the fuzzer logs the crash dump, type of failure, and specific input that caused the issue. However, it's highly unlikely that a fuzzing input will be a useful attack by itself (except possibly to crash the program for denial-of-service), so weaponizing the vulnerability (Exploit Development)usually takes more work.
Reverse Engineering is the process of figuring out the details of something's design, without the actual designs. In the context of software specifically, it often involves disassembling binary code into human-readable assembly language, and possibly "decompiling" to produce a higher-level programming language that is easier to understand and navigate. Neither disassembly nor decompilation can reliably generate the original source code. For example, things like comments are inevitably lost, many languages do not maintain data type info in their compiled form, optimizations can rearrange code and collapse constants and so on in ways that are harder for humans to read, and there are simply multiple ways to express some programming concepts (for and while loops are logically interchangeable even though they look a bit different). However, there exist tools that do a decent job with most programs, and some people are skilled at reading the output of such tools much the way they would read actual human-written source code. (Also, some languages are extremely easy to decompile, although those languages usually include built-in protections against buffer overflows in particular.)
Exploit development without source code usually requires some amount of very focused reverse engineering, where the vulnerable code is examined in detail to determine what input will have the desired result. This is often a somewhat interactive process, involving running the program many times under a debugger, single-stepping through the vulnerable code to see exactly what the registers and memory layout look like, and then altering the input to make the vulnerable program do the desired thing (typically loading a "shellcode" or similar, to enable executing an arbitrary program). This process is the same regardless of whether the vulnerability was found via fuzzing, reverse engineering of the whole binary, or something else.


How do IP addresses leak information about whether they are a home client or not? Websites such as hackforums.net, amongst others, are able to detect if you're using a proxy or VPN just by looking at your IP address and block you if you are doing so.

I have never experienced any false positives either.

How does your IP address leak this information?

Even if one can do this effectively, is it a good thing to do?

How does your IP address leak this information?

It doesn't.
IP addresses are not random things but different companies own different parts of the address range. Thus the usage of specific IP address does not change a lot, which also includes the range of IP addresses used for end users in DSL, cable or mobile networks or the IP addresses of VPN exits or public proxies.

There are several public services you can use to query the status of a specific IP. See for instance Dial-Up/Cable/ADSL IP Addresses at dns-rbl.com. Similar lists exist for known public proxies, VPN endpoints, Tor exit nodes...

  Even if one can do this effectively, is it a good thing to do?

It is heavily used in fighting spam, i.e. end users are often denied to send mail to the mail servers of a specific domain directly, but must instead use the mail server of the mail provider with authentication. Since lots of spam traditionally was sent from botnets consisting of owned end user PC this blocking effectively reduced spam and thus is a good thing.

The same is with public proxies , VPN or Tor. While they have their use in providing (limited) anonymity for honest users they are often misused to circumvent access restrictions or to let an attacker or troll hide its identity when harming other users or companies. Preventing this misuse is in the interest of most and blacklisting these IP is a useful way, even though there is collateral damage against the honest users.


Most widespread use of PGP after 20 years Phil Zimmerman released PGP (Pretty Good Privacy) on June 5, 1991.  As we examine the legacy of that far-sighted and brave act 20 years later, what are the most widespread and helpful uses of PGP signatures, and of PGP encryption?

See also:

Why I Wrote PGP - Phil Zimmerman

PGP signatures are used to sign software packages in some Linux distributions, including Debian and Ubuntu. This is quite widespread, although most Linux users are never aware of it.

PGP encryption, for what is was meant initially (i.e. emails), is commonly used in commercial situations, where some parties wish to exchange work documents. PGP keys are thus exchanged directly, not using the certificates (keys signed by other people) and the "web of trust". I often do it with customers. PGP benefits from very good integration and simple usage in many mailer softwares. PGP signatures are also used there, as an integrity check (but not in their "non-repudiation" role).

To sum up, the one feature of PGP which is almost never used is the web of trust.