Which is the most recommended way to expose a file to a computer in an external network in a secure way? I have two machines in an internal network. One is a development server, which is isolated from external communications (neither through HTTP, HTTPS, SSH, etc). The last one is a production server (which already has a web server installed on it and it's handling a web application developed by another person) that is reachable from external networks through SSH and HTTP/HTTPS.

I have a routine that queries a database every day and generates an Excel report (.xlsx file) automatically. The information this report has is not critical or sensitive but is is private, anyway so I would like to keep it confidential if possible (so that no external agents could access to it).

I have the need to expose this Excel file so it can downloaded by a machine in an external network.

I have considered developing an small web application so that the external machine can connect to a fixed route through a browser (let's say ip_address/hash_salt) in order to download the new file everyday (by using an username and a password).

I ask this question in order to ask if there exists an alternative solution (maybe using SSH or SFTP or another protocol) which would allow me the to achieve the same in a secure way (I don't consider sharing a file through HTTP/HTTPS secure by itself, but I might me wrong, of course).

Is there a recommended way to achieve this file sharing? Please, let me know.

HTTPS with authentication
While HTTPS relies on the PKI infrastructure, making it potentially vulnerable to rogue CAs, it is perfectly adequate for "confidential but not highly sensitive" material. Using HTTP basic auth sends the password to the server, and when TLS is being used, it is additionally encrypted. This will provide you with a few guarantees which you will need when handling confidential information:

Is the entity requesting access allowed to access this material?
Can an authorized entity be sure the material being sent has not been tampered with on the wire?
Can an active/passive eavesdropper view the material as it is being sent to an authorized entity?

Any good form of authentication solves the first question, and TLS solves the second two. There is no need to use basic auth specifically (as it has its limitations, being rather simple and not ideal for storing sensitive user-created and potentially re-used passwords), so long as any simple authentication system is in place to ensure that only those who are supposed to download can do so.
Client certificates
Depending on how important the confidentiality of this material is, and partially on exactly how little knowledge "zero IT knowledge" is, you can also use encrypted client certificates. These are certificates generated either by you or by the client, and stored in the client's browser. It is not difficult for an end-user to set them up and use them, but it requires slightly more effort than the normal internet user is used to. It requires opening up the settings for your browser and importing the client certificate file, which will open a prompt for creating a new password to encrypt it. When they later access your site over HTTPS, their browser will ask them for the certificate password and, if it is correct, it will use the certificate to authenticate them to your website. This is by far the most secure browser-based authentication method, as the client authenticates itself to the server, and the server authenticates itself to the client.
Securing a TLS connection
If you do end up with using HTTPS, you should follow best security practices for TLS deployment:

Use a strong private key (2048 bits or larger RSA), signed by a reputable CA (e.g. LetsEncrypt).
Disable insecure cipher suites (such as those from SSLv2-3 and non-PFS modes).
Avoid using small or default moduli if using DHE, or just use ECDHE.
Pin the HTTPS state by using HSTS, ideally with HSTS preloading.
Use HPKP to pin the precise public key you use. This is safe as long as you use a backup key.
Use OSCP stapling to check for revoked certificates.
Make a tight CSP policy and other anti-XSS measures to reduce the risk of XSS attacks.
If practical and feasible, require users of the site use an up-to-date browser.
Test your site regularly with Qualys' SSL Test. Seriously. It is an amazing service.

While this is not all an absolute must, it does significantly improve the security of the whole situation closer to that of SSH, while still retaining accessibility for the technologically-handicapped. At an absolute minimum, the first four bullet points and the last bullet point should be followed.


Does a TLS client needs to support one of the named groups (curves?) supported by the server for TLS handshake to succeed? Does a TLS client needs to support one of the named groups (curves?) supported by the server for TLS handshake to succeed?

Longer version:

I'm running a web site using Windows Server 2016. The web site has thousands of users and provides a REST API which many users interact with from various environments. Some of them are running older software like Windows XP and what not.

To make the web site more secure, I'm placing a web application firewall (WAF) in front of it to detect various attacks (like SQL injection and similar).

Historically when changing TLS configuration on the server, I've had various issues with clients who can no longer connect, for example due to mismatch in cipher support, old TLS/SSL-versions and the certificate chain not beeing fully included in the server response.

I've used Qualys SSL labs to compare the TLS configuration in the WAF with that of the old Windows Server 2016. The only thing which differs is that the old server supports a curve named "x25519" while the WAF does not. The old server also supports  secp256r1, secp384r1 which is supported by the WAF.

The WAF instead support secp256r1, secp521r1, brainpoolP512r1, brainpoolP384r1, secp384r1, brainpoolP256r1, secp256k1, sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1.

What I'm trying to understand is whether I risk breaking backwards compatibility with clients if I remove the support for x25519.

For elliptical curve (EC) protocol, all that is needed is for the client and the server to support at least one common curve.  However, if the client and the server do not support at least one common curve, they can try to agree on other protocols (such as DH).

But, in your case, it looks like the WAF supports a fairly large number of curves.  Even though x25519 is not one of them, there are plenty of others supported by the WAF, many of which that are older than x25519, so I don't suspect you'll have too many clients that are unable to connect just because you no longer support x25519.


How to properly select a code audit company? How should I go about selecting a code auditing company?

The first step is to review the code as thoroughly as possible in-house.  Look at it yourself, and have colleagues do the same (provided they are competent and trustworthy to do so).

After that, you may consider showing some or all of it to external bodies that you are familiar with, like partner businesses that you cooperate with on projects - this obviously depends on the size and status of your business - a sole trader may struggle with this.

Then, selecting a code auditor will depend on circumstances.  A big part of this is dependent on whether you are looking for regulatory accreditation of any sort, like PCI-DSS - any regulator that requires code audit will usually have specific companies chosen to do this.

A good approach if you haven't had any code audited before, is to begin by having a small, low security project audited in the interests of assessing the auditor's practices and service, before giving them larger scale work.  Like choosing a tradesman, a lot comes down to establishing a working relationship, and assessing them on that.


Preserve privacy on company Wi-Fi? How can one remain anonymous on secure company Wi-Fi in which you can only login in with company issued password?

I am writing this under the assumption that the only thing you don't control is the WiFi network available to you.

Some assumptions:

1) Your company doesn't passively monitor their network - they don't care about VPN tunnels, etc. You're worried about a bored Systems Administrator judging you for browsing My Little Pony fan sites during your break. You can't stand to see the judgy look in their eyes when you run into them at the water cooler.

2) Your company doesn't care if you use their network or not.

3) Your company doesn't care what you do on your device.

4) You don't care who snoops on you, as long as it's not your employers.

These are all big assumptions, but you haven't supplied any information to the contrary. If these assumptions are wrong, some or all of this answer will not be appropriate.

You have a few options:

1) Install a VPN client and connect to a VPN service. This creates an encrypted tunnel between you and the VPN server. You company cannot monitor traffic over a VPN connection.

2) Browse over Tor. Similar to a VPN service, Tor routes your traffic in a way that prevents the local network from snooping on the content you are browsing.

3) Use your phone as a mobile hotspot. Secure this hotspot using a WPA2 passcode. Your company can't eavesdrop on (2|3|4)G connections as that data is encrypted between you and your ISP (in this case, your phone service provider).

With enough time and effort, someone can correlate your observable traffic and other traffic and figure out who you were and what you were doing, but that's not something your employer will spend time and money doing.


How can be detected connection throttling in response to portscan detection? Imagine that I have to pentest a server that implements portscan detection based on the number of packets received to different ports in a time interval.

I don't know that the server is implementing this protection, I don't want my IP to be blocked and I want to be as fast as possible without being blocked.

How can I detect that the server is implementing this protection? Can I estimate the threshold where my IP will be blocked?

Logically you cannot know at which point the server will block you until you actually reach the threshold and be blocked. This is not something that the server will advertise.

If you have a spare IP, you can increase the number of packets per second until you are blocked, at which point you know what threshold not to cross with your other IP.

Good firewalls are likely to use more complex heuristics, depending not only on the number of packets but also the target ports. Chances are that you can work out the actual firewall heuristics by burning a few IP, but you cannot guess it a priori.


Why is a CSR hashed? What are the use cases for defining something other than the default SHA1 hash in a CSR? Is it to protect the digital signature, public/private keys? What is it protecting exactly?

It's actually not a SHA1 hash in the CSR.  It's a signature of the message.

For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended algorithm if you can factor the modulus into p and q).

A certificate is simply a public key, with some meta-data (e.g., who you are, what domain the certificate applies to, who signed the certificate), plus the signature of the certificate.

In RSA you sign a message by attaching a signature to the end of the message.  You obtain the signature by first hashing the message and then doing modular exponentiation on that hash with your private exponent.  That is the signature is S = H(m)^d mod N.  Note anyone with the public key can verify the signature by calculating S^e mod N and verifying that this matches the hash of the message.  Note, if you do not have the private key you cannot construct a valid signature for the message, so this prevents tampering with the certificate.

A CSR is a certificate signing request, but essentially it is just a self-signed certificate that you create on a local machine, so you can give to a CA to sign (so the CA will never learn your private key).  So you locally construct two large primes, multiply them to find the modulus, and calculate the private exponent.  You add your meta-data about yourself to your CSR.  For good measure, you immediately sign your certificate with the private key associated with the public key contained within the certificate.

This prevents someone from altering your CSR in transit to the CA (to say change your organization details, challenge password, serial number, without changing the modulus/private exponent).

This probably isn't the most devastating attack as you still have to trust the CA to act in trustworthy manner, and there's no reason to give away your CSRs to any other third parties.  However, its straightforward to sign it, takes no additional effort, so it is commonly done.


Is it possible to detect SSL private key changes? I wonder if it would be possible to detect a change of an SSL private key? If you change the key, then I think one must issue a new certificate, but new certificates could be issued without changing the key, right?

Or is it possible to keep the certificate, and change the key? I'd assume, no.

As far as I know, e.g. when a certificate expires, one must generate a new key and with that key a certificate signing request, from which a new certificate is created.

A certificate is signed, which means that not a single bit can be changed in it without breaking the signature. Certificates are immutable. When you want to "change the key" or "change the validity dates", then you need a brand new certificate. Renewal is a business concept; at the X.509 level there is a certificate, and then there is another one, and both live independently of each other.

A certificate contains a name and a public key. The same public key may appear in several certificates; there is no technical rule that forces a new key pair generation whenever a new certificate is issued. There can be legal or business rules, though: a CA is supposed to follow its published certification policy, and that policy may mandate a new key pair for a certificate renewal.

We may note that when a CA wants to "renew" a certificate without changing the public key, then it can do it by itself: the CA already knows everything which goes into the new certificate. Thus, that kind of renewal can be done automatically without needing to talk to the certificate owner at all. Not all CA do that.

For each public key, there is a corresponding private key. The private key, formally, is the knowledge of the mathematical elements which allow to run the "private key operations" (signature generation, asymmetric decryption). Mathematically, this knowledge can be encoded in various ways. In RSA, the public key is a pair of big integers:

the modulus n
the public exponent e

The modulus is a product of two big prime integers p and q. The private key is, really, the knowledge of p and q. However, in practice, the private key is encoded as several big integers:

the modulus n
the public exponent e
p
q
the private exponent d
dp = d mod p-1
dq = d mod q-1
1/q mod p

The "private exponent" is a value d such that e·d = 1 modulo both p-1 and q-1. It so happens that there are several (actually, infinitely many) possible values for d, for a given public key (n,e). This is what others have pointed out: you can have "several" private keys for the same public key. However, I may argue that all these private keys are in fact several representations of a unique "true" private key, which is the knowledge of p and q. All these so-called private keys will compute the same things for the same inputs, and produce the same outputs. Really, there is only one private key.

(Mathematically, looking for equivalent values for dp and dq has been employed to gain some performance on some low-power architectures, namely smart cards; the trick is that making dp slightly longer can imply a performance improvement if the longer value has a lower Hamming weight.)

So I'd say that you can forget this notion of "changing the private key without changing the public key". It adds only confusion.

Finally, the public key of a SSL server is in the server's certificate, which is public and sent to the client. If the client remembers the last certificate used by a given server, then it can certainly report when that certificate is changed, and what has changed exactly. In particular whether the public key is the same as previously, or another one.

There is a Firefox add-on for that.

Note that certificates which change are a normal occurrence on the Web, not only for renewals (CA who sell certificates like it a lot when they can sell more certificates, and that's a primary driver for the short life times of existing server's certificates) but also for multi-frontends: when a server is hosted on several machines with load-balancing, each machine may have its own certificate, distinct from the certificates of other frontends.


Does a random number after the login name in the public members section of a website increase security or privacy? http://forum.example.com/users/username-3723484

vs

http://forum.example.com/users/username

where username is specific to each user, as is its salt.

My hypothesis is that it makes it harder for spammers to collect information about someone by not giving a direct answer to the question: do you know user $login ?

If I had 20 millions of email adresses that I wanted to spam, I would certainly try to establish a profile for each user, for example by trying to find his interests. With a list of forum, I would just fetch and parse one page on each forums members section, but with the salt in the URL, I would have to make a complete copy, and update it regularly. So what do you think ? Is it done to increase the cost of data collection or is it something else ?

If you're wondering why this is done in practice, it generally (to my knowledge) has nothing whatsoever to do with information security. With forum software I'm aware of, the username is actually completely superfluous from the server's point of view; the number is the member ID number, and is all the server looks at. The username is just there so that the URL is more descriptive; it's strictly optional, and can be whatever you want, but by default it makes it clearer what the URL points to. You can see an example on Stack Exchange: your user profile is https://security.stackexchange.com/users/15000/antoine-lecaille but https://security.stackexchange.com/users/15000/cpast or https://security.stackexchange.com/users/15000/not-a-real-user takes you to the exact same page.

Related question on SO: https://stackoverflow.com/questions/16064124/incidentally-se-does-the-same-thing-for-question-urls


Establishing a Reputable Pseudonym with PGP Key This has become a bit of a thought experiment for me.

Suppose someone would like to establish a pseudonym along with a corresponding PGP Key, how could other people verify the correspondence between the name and the key?

Generally, PGP keys are for real people, whose identity can be verified IRL, but that does not apply here.

My first original thought was that the pseudonym could be a name based on the key fingerprint, but then, depending on number of characters, it could be quite easy to generate a new key that also meets this requirement.

Could there be a strategy (potentially more social then technological) for someone to verify this correspondence?

Edit:

The potential purpose for a pseudonym with this requirement could be along the same lines as Satoshi Nakamoto, or a whistle blower. Wanting to constantly release documents or software that is verifiably from the owner of the pseudonym.

The challenge with pseudonymous keys isn't only about anonymity; there is the additional problem of your identity being non-unique and harder to prove. Considering your pseudonym/nickname as established (that is, you are using an existing identity, rather than making up a new identity based on a hash or something among these lines), your nickname alone is not enough in asserting your identity and reputation.

If your nickname is Sam, if your friend's nickname is Sam, and if both of you have a "trusted" pseudonymous key, then neither of you can shout at the other and tell him, "hey, you're not the real Sam!"

One solution would be to regroup all information about your online identities in some unique place (where you tell "I am Sam on StackExchange", "I own the samlanning.com domain and website", and so on), and then get several people to verify and confirm all these identities. I can think of two ways of doing that:

Join a website such as Keybase (or make/host your own), which does exactly what I described, and is based on OpenPGP. Although internal, all those "central unique identities" make a web of trust, for identities/pseudonyms. A profile looks like this (yes, even the main author of GnuPG uses this website).
Using OpenPGP (and especially GnuPG), find people who are willing to sign (certify) pseudonymous keys, comply with their personal way of verifying your pseudonymous identity, and request them to incorporate policy URLs and notation data in their certifications.

I personally do this when I certify other people's keys:

gpg --ask-cert-level \
     --cert-policy-url http://diti.me/pgp/\#policy \
     --cert-notation CD42FF00@diti.me=http://diti.me/pgp/certs/%f.notes.asc \
     --sign-key

A policy URL is an URL (here, Internet document) inside of which you describe to the world what your OpenPGP key certification policy is. The person signing your pseudonymous key should tell (in this document) that they actually certify pseudonymous keys, and how.

A key notation is arbitrary text of the form key=value. The OpenPGP specification doesn't actually specify what uses should implementations make of these, but one use for them is to put an URL as the value. But you may simply have the signer put some text like "I carefully checked Sam's pseudonymous identity" if you want.

Using my command above, you can see that, on keyservers, both policy URLs and notation data are displayed by default:

sig  sig1  CD42FF00 2014-04-07 __________ __________ []
    Policy URL: http://diti.me/pgp/#policy
    Notation data: CD42FF00@diti.me http://diti.me/pgp/certs/A31D4F81EF4EBD07B456FA04D2BB0D0165D0FD58.notes.asc

For the record, this is me signing CAcert.org's automated GPG signing key, and I'll leave here a Web Archive link to the notation data.

For as long as the notation data produced by the signer can be read, anyone can/may decide whether or not they trust your pseudonymous identity. Using these, any motivated person willing to carefully check how reputable and trustable your pseudonym is, can actually do so.

EDIT: Actually, I think I might have gone a little off-topic in point 2. Is your question only about the pseudonymous certification process, or also its auditing?


Surely I haven't won the lottery, but where's the scam? Some time ago I received the following message on my personal mobile phone number:

  YOUR MOBILE NUMBER HAS WON 780,000EURO IN THE WORLD LOTTO END OF YEAR PROMO.FOR CLAIMS EMAIL(NAME/ADDRESS/PHONE) TO:Worldlotto@mediacombb.net

A WhoIs search for mediacombb.net returns the following:

I certainly did not take part in this "World Lotto", so this being truthful is out of the question, and thus likely to be a scam.

How will the scammers benefit from me simply sending in my name, address and phone (which they already have), all of which they most likely have if they managed to get their hands on my personal phone number?

Not quite sure if it would be wise to go ahead with providing the requested
info and update the question with further details as the case progresses.

I created a fake gmail account and emailed the address you posted.  I got back something that very much looks like it will turn into advanced fee fraud..  One of the Hallmarks I've seen is the spelling out all the dollar amounts in numerals, as well as words.  i.e.

  On behalf of the Management and Staffs of WORLD LOTTO MOBILE PROMO, We officially congratulate you as the beneficiary of the cash prize of €780,000.00 (Seven Hundred And Eighty Thousand Euros). My names are David Hoffman,

It goes on, trying to invent fake details to establish legitimacy, and continually mentioning large amounts of money in an attempt to get you hooked.

  This promotion is approved by the British/USA Gaming Board and
  licensed by the International Association of Gaming Regulators (IAGR).
  This promo is the 1st of its kind and we intend to sensitize the
  public about WORLD LOTTO MOBILE PROMO. Your Mobile Number attached to
  a reference, won you €780,000.00 (Seven Hundred And Eighty Thousand
  Euros) cash prize and your check will be issued in your name provided.

The MO is generally always the same.  Get the mark convinced they've won some large amount of money, but you juuust need this little amount of money to pay some fee associated with winning the money.

If you wanted to be certain you could likely just email back and forth with this guy, preferably from a fake email address.  Some people do this as a form of entertainment.


Domain name expiration and TLS If I purchase a domain name that has expired, do I have any assurance that the previous owner does not have a valid HTTPS certificate for the site? In other words, do CAs check domain name expiration dates when issuing a certificate to ensure the certificate does not outlast ownership of the domain? Or, alternatively, do CAs monitor domain name ownership and revoke certificates for domains that have been dropped?

Do I have any assurance that the previous owner does not have a valid
  HTTPS certificate for the site?

No, you don't.

CAs can issue certificate that are valid after the expiry date of the domain (at the time of issuance). Even if they didn't, a domain could be transferred before its expiry date.

In addition, you can't possibly control all the CAs that exist and that are trusted by potential clients. Even if there was a scheme that may monitor domain registration updates, not all CAs might be part of that scheme. You can't possibly know exactly all the CAs that your potential users may trust.

I can create my own CA and issue a certificate valid for the next 20 years for a domain that doesn't even exist yet. Of course, that's an extreme and pointless example, but if I use it as an internal CA and you happen later to register that domain, you'd have no way to know about it.

You could of course restrict your assumption to the major CAs around. However, as far as I know, they don't monitor changes to the whois database, at least for domain-validated certificates (I'm not sure if there's any provision for this situation with EV certs).


How to authenticate users? I'm in the scenario that I'm planning a detailed description on "how to securely encrypt files" without putting too much in one Q/A.

So, in a file-encryption scenario, what are the possible ways to authenticate the user?

Please note that I don't want descriptions on how to perform this on a low level, but rather have a list of high-level approaches to accomplish the above objective.
And please also note that I don't want to rely on "simple" access control checks made in software but rather have something that can be used to derive / transform the file-encryption-key (but not the description on how to do these derivations and transformations).

There are a few ways to do this.

You can come down to the following statement:

For authentication you can only use something the user knows, has or is.

As you're in a file-encryption scenario, this should rule out most points concerning "what a user is", because they involve biometrical data, which needs to have tolerances.

A password or passphrase. This is the classical way of authenticating users in this scenario, is widely deployed, well accepted and can provide high levels of security. Please note that PINs also fall into this category. From the above sentence this is "something the user knows".
A (symmetric) keyfile, this is something the user has and is usually implemented as an arbitrary file the user can select or generate and which is strongly required for the key-derivation. This is also widely implemented (most better encryption tools use this). Please note that the keyfile may rest on local memory or on a secured device (i.e. a smartcard or HSM).
An (asymmetric) key(file), this is something the user has as well. Please note the difference to the above keyfile, as this usually isn't input to the key-derivation function directly but used for asymmetric decryption on the user's CPU, smartcard or HSM.
Data stored in the OS. Usually the OS has some way to store data protected and this mechanisms can be used for authentication. Some OS offer secure key storage and some offer encryption of data using the user's credentials. (category: has (PC/OS) / know (credentials))
Cryptographic hardware (smartcards, HSMs, TPMs,...) can be used to securely seal and store keys and integrated cryptographic processors can be used to perform symmetric key transformations (using the stored key), needed for key-derivation. (category: has (hw) / know(PIN))
Custom hardware is probably the most secure way. This hardware can function as the above crypto hardware concerning usage, but authentication can be made highly different than with a standard PIN / password. For example if the hardware is highly trusted (tamper-evident / tamper-resistant) it may be possible to securely implement biometric authentication for the device unlock and hence indirectly for the key derivation (as the crypto processor only operates after valid authentication and it's not software access control but hardware access control). Biometric authentication may include but doesn't have to be restricted to voice recognition, fingerprint sensoring, face recognition, DNA testing, brain-activity recognition, iris scanning and hand scanning.


Securing user supplied files in IIS I have an Internet website running on IIS/Windows configured as follows:

The website is publicly accessible for visitors to browse.
A user can login and upload files.
The user will be able to see their files, but not another user's files.
After the files are uploaded they are stored in a directory in the website.

If someone has the full Url to the file e.g. http://website.com/files/13212132.jpg how can I prevent the file from being accessed by people other then the user who uploaded the file?

Any insights will be appreciated.

The best way is to not serve the files directly at all, but serve them via a handler.  This way you can store the files wherever you like, (which has advantages of its own, and not just security advantages) and the handler can process both  authentication and authorization checks before making the decision as to whether it should present the file to the user or not.


Is this XSS filter vulnerable So recently i was testing a web site .I searched bike in the search bar and got the following response.

So to escape all the TAGS i tried the following

bike

i got following response

Your search: bike&nbsp;&nbsp;&nbsp;&nbsp;Found 0 item(s)

next i tried the following attack vector

and this was the response

I think this site is vulnerable.It looks like i have escaped all the tags.Can anyone suggest something

UPDATE

So i tried this and it worked

<img onmouseover="alert(1)" onmouseout="normalImg(this)" border="0" src="http://d2fbmjy3x0sdua.cloudfront.net/cdn/farfuture/hSDgO-dX1na9VZajH8LUXXZbZFW0DYjcPLDuabM2-1c/mtime:1486670171/sites/default/files/styles/nas_bird_teaser_illustration/public/4995_Sib

i get a popup .But i still dont get why pages crashes when i put onerror oralert(1)

UPDATE

I have one more question ........
when i use the following payload ,i get a pop up....

but if i close SRC attribute inside double quote(which is the correct way)the page crashes

screen shot(when not enclosing SRC inside double qoutes)

and where does all these closing
 tags came from.They weren't here before when i searched simple terms like "bike"

It might be vulnerable, but we can't tell reliably without more information.

But first, you are not really escaping tags, you are closing tags.

In most situations, closing tags is not necessary, as the parser will happily ignore any possible errors. You can just inject your img payload at the beginning, and it will work (there are a few exceptions, such as textarea, title, script, etc; but b and font are fine).

Regarding the filter, we can see that everything after = is cut off. You should investigate further by supplying more input, such as a=b (to check if it is only cut off inside a tag). You could also try to encode = as %3D.

If bypassing the = problem doesn't work, you should try a payload that doesn't require it. A simple example would be <script>alert(1)</script>.


single sign on across two servers I have been wondering how and what kind of tools are needed to do single sign on in the following scenario:

1) Alice is logged in to site X hosted by server W

2) Alice navigates site Y hosted by server Z

3) Alice uses her login credentials for site X to access site Y

How does the browser share the login information from the session with W to attempt to create a session with Z?

Does Z send login credentials to W and receive a response indicating success/failure?

This is called federated authentication.  In the enterprise world, this is often accomplished with Kerberos (for non-web based systems) or SAML (for web-based systems.)

In the non-enterprise world, far and away the most popular federation framework is OAuth 2.0.  There is an extension to OAuth 2 called OpenID Connect (much different from the older OpenID Authentication protocol) that is specifically geared at authentication and profile sharing.


Why does this buffer overflow have payload &system-&exit-&BINSH I'm following a tutorial to write a simple buffer overflow. I have (basic) knowledge of assembly, and the stack. I've written a stack based buffer overflow before and understood it. The program I'm exploiting this time has NX enabled which means it's not possible to execute code from the stack or an environment variable. The author of this tutorial then suggests to declare an environment variable:

export $BINSH="/bin/sh"

and the payload fed to the buffer overflow will be the address of the 'system' in the program, followed by the address of the 'exit' in the program and finally the address of our environment variable:

payload is : &system - &exit - &BINSH

I've managed to get the exploit working but I don't understand the theory behind the payload. Unfortunately it's not explained in the tutorial (which can be found here).

Why do I overwrite EIP with the address to 'system' (and what does this address correspond to)?

How does putting the address to my environment variable containing /bin/sh as the third word in the payload make it execute?

PS: Linux, 32bit. intel

This is a class of attack known as return-to-libc which is a method of bypassing DEP.This works by calling existing functions in a shared library that you know is executable. In this case, the exploit calls the system() function.

Functions are passed parameters on the stack. By controlling the stack, you can control what functions are passed into the system() call. In this case, you tell system() to call whatever is in the environmental variable which you set to /bin/sh. Essentially, you are calling system(/bin/sh) which spawns a shell. Boom, exploited.


Is diskcryptor really secure? Diskcryptor is an open-source competitor to TrueCrypt for Windows. It has an edge over Truecrypt for system encryption, because it allows for more than one independently encrypted system partition, and this is exactly why I use it.

Can anyone here confirm that this program doesn't have backdoors and is as secure as Truecrypt? Is anyone aware of any security analysis of this product?

By secure I mean: lack of backdoors, proper handling of encryption, and even resistance against the evil maid attack.

You do know that Truecrypt is also free and open-source, right?

Aside from commissioning independent testing, the only assurance you are likely to get is from users/hackers discovering issues and publishing them on the web, so your first port of call should be a google search for Diskcryptor advisories

Number of advisories published can be a reasonable indicator of development quality, when considered along with usage numbers - obviously a product with large numbers of users could be expected to have more issues reported than a less popular one. Alternatively, look at the documentation on their development and testing processes - or their bugfix revisions.

Finally, you could look into the authors of each tool and see whether you can place some reliance in their work.


Why is HTTP data sent in clear text over password-protected Wifi? In my home I have a router protected with WPA2-PSK (WPA2 Personal), using the passphrase.

When I try to log in to a page over the Internet (this page does not use HTTPS to log me in), all my data is sent in clear text (since I can see the password I typed in Wireshark).

Why is that? I mean, my WiFi is protected, so all the communication should be encrypted, right?

I mean, my WiFi is protected, so all the communication should be encrypted, right?

It is, but not at the place you're reading it. Encryption happens at a certain point in the "pipeline", and decryption then must also happen at a certain point in the "pipeline" (otherwise the data are useless). You are observing the data after they have been decrypted, which would not be possible if you were using HTTPS (which instead provides end-to-end encryption, which starts at the server and ends at the browser).

If you attempted to use Wireshark to capture the contents of an HTTPS transaction, it'd be like this:

+--------+ (encrypted) +----------+ (encrypted) +--------+
| Server | ----------->| Internet |------------>| Router |
+--------+             +----------+             +--------+
                                                     |
                                                     | (encrypted)
                                  +------------------+---+
                                  | Your PC          |   |
                                  | +-----------+ (e)|   |
                                  | | Browser   |<---+   |
                                  | +-----------+    |   |
                                  | +-----------+ (e)|   |
                                  | | Wireshark |<---/   |
                                  | +-----------+        |
                                  +----------------------+

Here, your browser knows how to decrypt the data, because it "owns" the HTTPS transaction in the first place; your Wireshark instance (which, per the very purpose of end-to-end encryption, is treated just like any other snooper in this scenario) does not.

But your wireless encryption starts at the router and ends at the PC's network card, so the result for you is more like this:

+--------+ (plaintext) +----------+ (plaintext) +--------+
| Server | ----------->| Internet |------------>| Router |
+--------+             +----------+             +--------+
                                                     |
                                                     | (encrypted)
                                  +------------------+---+
                                  | Your PC          |   |
                                  | +-----------+ (p)|   |
                                  | | Browser   |<---+   |
                                  | +-----------+    |   |
                                  | +-----------+ (p)|   |
                                  | | Wireshark |<---/   |
                                  | +-----------+        |
                                  +----------------------+

Here, anything on your PC can read the data, because they were decrypted by your network card. Otherwise, what application would decrypt the data? Nothing would work.

There is almost no relationship between HTTPS and WPA2-PSK; they do completely different jobs.


ASP.Net Web API make HTTPS Mandatory Is there any programmatic way that where I can mandate the HTTPS in my ASP.Net Web API? I need to perform this for all HTTP methods in my Web API.

Can we mandate HTTPS to specific HTTP messages as well ?

Please note that I need to do this in programmatic way in my ASP.Net back end.

Unless I'm misunderstanding your question, wouldn't you be able to just create a RequireHttpsAttribute (inherit from ActionFilter) that does this, and decorate your controllers/actions with it?

Inside that, check the uri scheme of the request and disallow the request returning forbidden if it doesn't match the right scheme.


Does google use browser fingerprinting? I'm wondering whether besides collecting the typical tracking information (IP + cookies) google has already implemented browser fingerprinting? I read sometime not long ago about it being a hypothetical future method for tracking and identifying google users and would like to know if it's already in use officially?

As for what Google does officially, it is easily checked: go read Google's privacy policy which is prominently advertised. By definition, it will tell you what information Google "officially" gathers.

The implementation of browser fingerprinting is known and trivial. Most of it is just reading the headers from the HTTP request. Whether Google implemented it or not is irrelevant, since they could implement something to the same effect in a matter of a few days at most. What matters is whether they deployed such a system -- and, "officially", they did not.


Can a USB device read data from the internal HD of a PC when it's turned off? I have heard on TV (tg5) that some devices exist, that can be connected to a USB port on a PC that is turned off and get data from the hard disk.

I am wondering if (and if so how) this is possible; isn't the hard disk turned off when the PC is turned off?

How would a USB device be able to read data from the internal hard disk in the PC then?

If the computer is setup to support wake-on-peripheral and boot from USB, then it is possible for a USB device to turn on the computer and boot to its own operating system which would still have access to any non-encrypted hard drives in the computer.  Wake-on-peripheral in particular, and even boot from USB tend to not be default options though and would normally still require manually turning the computer on and altering bios settings (which would also require resetting the BIOS password if one is set, though this is normally trivial.)


How to tell what viruses are covered by your anti-virus software One of our corporate twitter accounts recently started sending out DMs to its followers.  Looking at the content of these it seems we'd become infected with Troj/Mdrop-EML.
All computers on our company network should be up to date with Symantec Anti Virus / on the latest virus definitions.

Is there a way to see if this virus is covered by Symantec (ideally is there some generic way to check this for any popular anti-virus software, so this post is useful to others)?

We'll investigate further to see if users were using the corporate account from home machines or if our anti-virus coverage has any holes which we hadn't spotted, but I thought it would be useful to know if this virus is something that protected machines would have been protected from before investigating further.

What you can do is:

set up a sandbox computer installed with your AV
infect it with the virus and see if it's detected

Or you can upload the file to https://www.virustotal.com/ and see if it's detected by symantec.


Are SIP REGISTER transactions w/ HTTP Digest subject to replay attacks? It is my understanding that the authentication during a SIP registration is done through some kind of an MD5 hashing algorithm known as HTTP Digest, and doing a tcpdump of the actual traffic I've noticed that a cnonce (client nonce) is used.

The way commonly implemented by service providers and in off-the-shelf server and client software, including softphones like Groundwire by Acrobits on iOS, CSipSimple on Android, and Bria by CounterPath on the desktop, are SIP REGISTER and related authentication transactions subject to replay attacks?  Or could they be, depending on what kind of HTTP Digest authentication is used by the client?

Otherwise, or in addition to this, what kind of other Man in the Middle attacks are possible against SIP registration credentials?

The digest authentication, described in RFC 2617 (it's for HTTP but SIP uses the exact same flow) is safe against repeat attacks.The cnonce (client nonce) value and more importantly - the nonce value are what makes the message appear different every time it is transmitted.As for man in the middle - it is safe from this sort of attack but if your clients support basic authentication (plain text) they can be tricked by a man in the middle to send clear text passwords.Most clients do not allow basic authentication.Additionally, poorly written servers that do not change the nonce value or use a preconfigured set of nonce values are exposed to repeat attack, but since it's a very simple task to create a nonce - I doubt if such poorly written servers exist.The biggest cavity of digest authentication is that the server needs to be able to retrieve the unencrypted password in order to verify the response (the password is not transmitted outside the server though).


How isolated are 2 operating systems on 1 harddisk? Lets say I have 2 windows dual booting on the same harddrive (windws 7), How isolated are they?

I am thinking that there should be up to date antiviruses software on both Windows, and they should be different software so that each one can pick what the other missed.

Well, they aren't isolated at all if they can both see the hard drive.

You are correct that they both should have their own anti-virus solutions though.


How to store a private RSA key for an application? I was wondering how an application that have a private key will keep it secure?

If the private key is outside the binary, then anybody can access it, but store it in the binary doesn't make it more secure (I think). We can try to obfuscate the key but it still can be discovered!

So what is the best practice for that matter?

Expect it to be compromised.  There isn't a good way to do anything other than obfuscate a private key.  The best bet is probably to store it in the cryptographic library of the system that the software is running on.  If you're lucky it might have a TPM or HSM that can store the key securely.  What are you trying to accomplish with the private key?  That might help give better feedback on the best way to securely accomplish your goal.


Are these merchant integration instructions wrong about server-client interaction? I'm working with a payment gateway that seems to have a fundamental misunderstanding of "clients" and how to protect sensitive data.

The integration instructions are mostly about a "redirect" mode of operation, where a customer is directed to the gateway's website to enter credit card details, where they see a receipt and then get directed back to your website.

Docs:

  https://www.myvirtualmerchant.com/VirtualMerchant/download/developerGuide.pdf

Here's an example

<form
action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
.do" method="POST">
<input type="hidden" name="ssl_merchant_id"
value="my_virtualmerchant_id">
<input type="hidden" name="ssl_user_id" value="my_user_id">
<input type="hidden" name="ssl_pin" value="my_pin">
<input type="hidden" name="ssl_transaction_type" value="ccsale">
<input type="hidden" name="ssl_show_form" value="true">
<input type="hidden" name="ssl_amount" value="14.95">
<input type="submit" value="Click to Order">
</form>

This is the paragraph that has me concerned:

  All sensitive data, specifically your VirtualMerchant credentials, should be placed in server side code
  rather than placing hidden value fields on an HTML form.  This will limit the ability of malicious users
  to edit and use this data for their own fraudulent purposes.  The use of  server-side scripting allows
  custom HTML to be delivered to a client machine.  The code that generates the custom HTML is
  processed on the Web server before the HTML is sent to the user's machine over the Internet.  This is in
  contrast to client-side scripting where the HTML is modified, typically by java-script in the client's
  machine after the HTML and java are sent from the Web server.  The primary strength of using serverside scripting with VirtualMerchant integration is the ability to hide the sensitive processing credentials
  from the browser.

That sounds great — not exposing my account ID to the client.

However I don't think that what they are suggesting takes care of it. I can only see two ways to hide the details entirely from the client:

Have the server act as the client and the browser is never directed to the payment gateway's website

They offer this mode, but most of the documents refer to the HTML/client-side form mode instead.
Use a signed token of some sort — which they don't support.

This paragraph, however, seems to claim something about using "server-side scripting" to deliver "custom HTML", and therefore hide the details?  I just don't see any way - even if the redirect took place via a Location header, that data would still be exposed to the browser and anyone with malicious intent could easily get it.

Can somebody please help me understand why this sounds so wrong to me?

At a glance, it looks like the instructions in the developers' guide are not so much wrong as simply misleading.  As you note, pretty much all the examples do show the sensitive ssl_merchant_id, ssl_user_id and ssl_pin fields embedded as hidden form fields in HTML code sent to the customer.  However, if you work your way all the way to chapter 9, "Transaction Security", you'll find the following paragraph under "Best Practice Tips" (boldface original, italics mine):

  "Server Side Code – Your users can read HTML source code from your Web pages when they are downloaded to their Web browser. Although our simple examples in the document show this as a method for passing data to VirtualMerchant, we do not recommend this for your production
  website. All sensitive merchant data, including transaction amounts and your VirtualMerchant
  credentials, should be placed in server side code, rather than in hidden value fields on an HTML form. This will reduce the ability of malicious users to exploit client browser vulnerability to edit and use this data for their own fraudulent purposes. If you are not knowledgeable enough to implement this on your own, there are quite a few shopping cart providers that inherently provide this service and are compatible with VirtualMerchant."

So, basically, it's a case of "do as I say, not as I (show you how to) do".

That said, it does seem to me that, if you follow all the other security recommendations carefully, passing the merchant/user ID and PIN to the customer may not be as bad as it might seem.  Done right, having those values should only give the customer access to a limited user account that only allows them to make payments to you — but that's what you're allowing them to do anyway, so it should be no big deal.

Of course, that only holds if you really can (and do) make the user account used for the form so limited that it's safe to hand out to customers.  Without further study, I can't really tell whether that's possible or not.


Legal to Request Internal Network Information? Is it legal to access information inside a private network such as a computer's  name, IP address, MAC address, etc? I was told yesterday that a certain program used may be trying to get the name and ID of the PC's in private home networks to verify account security. I was always lead to believe that a reason for internal and external IPs was to hide the network from the outside. I don't really believe they are doing it because it feels like more trouble than the service really would go through. Not entirely sure though. Don't really like the idea of them harvesting information they don't really need when my network is controlling what goes where.

Are they information security auditors? These will most of the time run a network mapping tool such as nmap to check on the security of the internal network. A general scan by the IT security team is acceptable as long as it does not interfere with normal network operations. This is however for companies. For home networks that's a whole different story, but then the ISP will already have this information. Who is really doing the scan here?


Do LAMP log files sometimes contain sensitive information? I will have a LAMP web server with CentOS and cPanel. With this setup, is it possible for any server log files, whether regular or error logs, to contain sensitive information in them, such as passwords or url variables (GET data)?What I'm trying to avoid is having sensitive information stored in a plain text log file.If the server does do this, how do I stop this? Is it a good idea to do so for security?

Yes, it's possible it may contain sensitive information. A lot depends on what you consider 'sensitive'. That the IP address 123.123.123.123 access www.hotpron.xxx at 7pm on Sunday contains no user identifiable information but might be extremely sensitive to someone.

The normal logging provided by Apache will only record

GET variables
any cookies you explicitly include in the log format

It will also record usernames used for authentication by the webserver (rather than the code itself) via the mod_auth add ons. Again this is configurable.

And the error log will contain anything your application chooses to write to it.

It's possible to get it to log POST variables as well using (e.g.) mod_security - but this is more involved.

Generally most people would consider it very bad practice to pass authentication tokens (usernames, passwords, session identifiers) via GET variables.


TLS_RSA type ciphersuite and PFS Today while I'm reading about the RSA factoring challenge. I thought to myself that if whoever depends on RSA-512 (By using TLS_RSA_xxxx) to secure their TLS connection years ago, the info they wish to protect will not be secured anymore today. Therefore, if someone manage to crack it in the future, I think the same goes for RSA-1024 or 2048.

So let's assume if we want to secure our TLS protected data like forever, is PFS the way to go?

PFS is about resistance to key-compromise, not about growing computational power.

If you're afraid of faster conventional computers, use sufficient key-sizes. e.g. a 4096 bit RSA key or a 256 to 512 bit ECC key. At least for the 512 bit ECC key case, we can safely say that conventional computers getting faster is no threat.

Unfortunately large RSA keys become pretty slow, so at high security levels ECC is preferable.

For SSL the easiest way to get ECC for confidentiality is using the forward secure ECDHE suites. But that those suites offer both PFS and higher security levels is merely coincidental, the security level in bits and PFS are not directly related.

=> Go with ECDHE suites where available. They offer both PFS and higher security levels with decent performance.

For long term security, I'd worry more about quantum computers, which kill both ECC and RSA using Shor's algorithm and about mathematical advances which might break either of them, or both.


What is the point of secure email gateways? We run Exchange 2010.  Our edge servers run "passive opportunistic TLS" for 99% of the domains we communicate with.  For a handful of domains, we have forced TLS on both our end and the other domain's end.

We're in the process of deploying a secure email gateway appliance.  It will basically park your email message on the HTTPS-secured appliance and send a link to the recipient to create a username/password and log into the appliance to retrieve the message.

For outbound email, what does this give us that TLS doesn't?  Am I missing something here?

If gives you the assurance that the email, and the sensitive data it contains, never transits over an unencrypted channel, with a side-benefit of allows you to audit access.

Generally with SMTP, you don't know what happens after it leaves the edge of your network to the edge of the next.  It could be insecurely transferred from one MTA to the next, it could be transferred insecurely to the client via cleartext POP3 or webmail...This is all out of your control, and unfortunately none of these scenarios are uncommon.  The gateway allows you some level of assurance that the sensitive data is not directly exposed on the network.

It isn't foolproof.  Of course the emails letting the end-user know that they need to create an account on the gateway, and subsequent confirmation emails are just as exposed and can potentially be exploited, but that requires an active attacker and protects the sensitive data from being passively sniffed.


Is it possible to verify if a website is vulnerable to SQLi by viewing its source code? I've heard the eval() function is vulnerable to SQLi.

Can I check for vulnerabilities by simply viewing the website source code?

The typical SQL injection attack can occur when the SQL command string is concatenated to include a user entry:

$sql = "SELECT * FROM users WHERE user_name = '".$user_name."'";

A malicious user could enter a user name like

  my name'; DROP TABLE users; --

Guess what happens!

Better use prepared statements and parameterized queries.


An OS that does not trust its RAM? I wonder if it is possible to write a kernel that would keep all of its RAM encrypted, storing the key in the CPU cache, so that the machine would be resistant to cold-boot attacks?

Data in L1 cache will not remain in L1 cache only; the hardware will copy it to main RAM transparently and almost immediately. At least so operate modern CPU. If you want to keep sensitive data out of RAM, then you must keep it in registers only. Context switches will be a problem, also, since they automatically flush registers to a designated RAM space.

While it is theoretically possible to operate only in registers and do encryption and decryption in the CPU only, it will be hard to do correctly (random-access encryption with updates is difficult to design without weaknesses) and it will be very expensive (you would more or less have to implement a virtual machine, where each opcode entails some decryption, so expect a slowdown of a factor 50 at least).

The TRESOR project appears to be much more limited in scope; it does not want to protect generic data from leaking to RAM, only encryption keys. Which, in my opinion, misses the point. You encrypt data because that data is sensitive and should be kept confidential. The encryption key is a high-value target because it concentrates secrecy, but certainly not the only target.


Disable a specific services in Windows 7 I am using a Windows 7 and I want to Disable some Services,
How can I do this?

For my machine only?
For some machines inside the Active Directory I can control?
For all machines inside the Active Directory I can control?

Some of the services I would like to disable are:

Microsoft Lync
snare

If it's a computer (or group of computers) managed by Active Directory you can do this with Group Policy.

The settings is under Computer Configuration > Policies > Windows Settings > Security Settings > System Services.

If it's just on one computer you can just disable the service (Start > Run > Services.mmc) and change the Startup Type to Disabled.


Is there a way to lock down a network? If supposing I discover that my network is being attacked by some hacker or is being compromised in any way and I am able to detect it. So, is there any software-oriented way of 'locking-down' the network?

Basically, that means that there would be NO traffic at all in the whole network. A solution like yanking the model cable is not appreciated. Could it be somehow done in a more subtle way? blocking an IP address would not be the best because the person on the other end could spoof it or more certainly, could just get himself assigned another IP address by using other devices.

  Could it be also done in a way as to only block traffic from that specific person so that legitimate traffic is not hindered? Maybe to identify him without something being easily changeable like IP or MAC address?

I have a Mi model 2 router but it doesn't support shutting down traffic or itself (except, I guess a reboot). So I want a solution that could be done from a computer itself with no other hardware...

Blocking the whole network is easy: you flood the whole network with high volume packets so that nothing else can communicate.

If you got very clever, you could script something to log into your home router's web interface and shut down the network or reboot it.

For a targeted approach:

As a matter of networking, one node cannot block another node. You would need a central control node, like a switch, to block communication from a node to make sure that the node was blocked and you did not also affect all the other nodes.

At the switch level, you can block the port, not the IP or MAC, that is the source of the unwanted traffic. This is a very common approach. This function is not available on home equipment.

Using your home router's web interface, you might be able to figure out the port, and use whatever functions are available on the router to block the node. But that's quite the sophisticated level of browser automation.


Does a valid code signing certificate mean that an installer has not been tampered with in transit? Several dominant software vendors distribute updates over HTTP or over HTTPS with bad certificates.  In general, it doesn't seem like I can expect to rely on a secure channel to ensure that an installer is not tampered with in transit.

It looks like all of the installers have valid signatures.  This is a typical screen when I check the properties of an installer file:

The operative part of the dialog box is "This digital signature is OK." What is not clear is what portion of the file the signature is attesting to.  You would expect this to be all of the file, but I haven't found a statement from Microsoft confirming that.  I also vaguely recall a tweet rumoring that only parts of a file are attested to by a code signing signature.

What parts of a file are checked by windows when checking whether a code signing signature is "OK"?
Are there known third-party attacks that use correctly-signed installers from a trusted second party as a vector?

The signature is of a hash of the portion of the executable before the code signing block. Best practice is to have both the installer and the application signed.

You can study some details by looking at this:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463180.aspx

EDIT:  OK, now that I'm off the mobile device and on a real keyboard, I can elaborate.

As noted in the document to which I referred you, the hash that gets signed is generated as to the entire executable file except for two excluded portions (a) the total file checksum; and (b) the certificate tables.   These cannot be incorporated into the hashing because of the chicken or egg problem (e.g., these fields are dependent on the content of the attribute certificate table, and thus their values are not fixed until the certificates/signatures are prepared and appended).

As for the attack surface/scenarios, we see once again why it is so important to have good crypto primitives, and ALSO to use best practices.  I suppose that in theory an attacker could create a malicious version of a software application, and then roll it into an installer and include some carefully calculated data to generate a hash collision with an existing real MD5 certificate from the application vendor, attaching that existing certificate/signature to the compromised executable.   If you only checked the installer you might get fooled.   This is why MD5 cannot be trusted for this sort of application anymore. It is also why, in addition to checking the installer, you should check the application program itself.

Windows 7 accepted MD5 hashes for code signing, whereas Windows 8 and up requires SHA1 or better.  (For what it's worth, I dug around my program files and old installers just now and only found one from 2008 or so that used MD5 for the signature hash. 2nd edit:  I take that back, I also found a relatively recent version of Winzip using MD5).


Looking for virus under Linux if I am looking for a virus/spyware under linux, where should I have to look for to find it ?

I suspect to be the target of very skilled hackers.
5 or 6 years ago I found a spyware on my linux box, it was lkm masked as ppp_deflate module with md5 hash hijacked. I mean with the same md5 hash of the original ppp_deflate.
So my question is not "please advice me some kind of antirootkit tool" neither "Please give me some kind of malware for linux". I tryied different kinds of antirootkit tools but all had not worked.
And my question is:
I suspect I have a spyware on my linux box, where should I look for find this spyware ?
kernel ? lkm ? libc ? binary ? initrd ? gnome limited process ?
Then it's a kind of forensic question..
thanks

Viruses and spyware are rare on Linux.  You can try Clam Antivirus, but generally speaking it is not worth the time.  Generally speaking, it is better to spend your time hardening your Linux desktop and hardening your Linux servers, rather than worrying about anti-virus scanners.  Anti-virus scanners are primarily a Windows thing.

Why do you ask?


Estimate the number of host computers on the private network by port scanning If we have a private network connected to the Internet with NAT, how can an attacker estimate the number of host computers in network using port scanning?
For both possible modes, the attacker inside and outside the private network.

From outside the a NAT network no direct port scanning of the internal network is possible. This is because packets from outside will only be forwarded to the internal network if there is some connection established from inside which matches the packet. See also Scan a computer behind NAT.
Scanning from inside is mostly trivial though: just enumerate all possible hosts in the local network and try the reaction to common ports. If there is some kind of response (i.e. SYN+ACK, RST, ...) then there is likely computer with this IP address.
And while direct scanning from outside is not possible, an outside attacker might actually be able to scan from inside. All what is needed for this is to lure somebody inside the internal network to a site controlled the attacker and then use the browser as the vehicle to scan the internal network. This is possible because the browser on an internal system has at the same time access to the internet and also internal network. See for example Exposing Intranets with reliable Browser-based Port scanning for more details.
Apart from active discovery there are also ways to passively detect the number of (active) devices behind a NAT. See for example Detecting NAT Devices using sFlow and other research.


Is there a PRNG in Java with a period of at least 256 bits? From what I can tell, Sun JRE/JDK's are limited to only providing 128-bit strong cryptography without downloading an unlimited strength jurisdiction policy files. My question is, if I install theses files, is there a PRNG with sufficient degrees of freedom to generate 256-bit numbers built into the JRE/JDK?

Java's cryptographic layer is pluggable: you can configure extra providers and even set them as "default".

For java.util.SecureRandom, the default implementation (called "SHA1PRNG") that is shipped with Sun/Oracle JVM uses SHA-1 and a 160-bit internal seed obtained from the operating system (see this analysis). For all intents and purpose, its security level is "about 160 bits", which is more than enough.

If you really made enemies among some major deities that have access to sufficient divine computing power to break 128-bit keys (and who also, for some reason, prefer not to strike you with lightning, as is customary), then you will need another PRNG provider. I don't know of any ready-to-use JCE provider that includes a PRNG algorithm that would fit your 256-bit criterion, but such things may exist nonetheless, or could be implemented with relatively little effort.


Known characters in passwords? I generate passwords for everything that requires security using the following method:

ksoviero@ksoviero-Latitude-E7440:~$ head -c 16 /dev/urandom | base64
gorv/cp+lSiwiEfKck2dVg==

256^16 combinations is more than enough security (for me at least), and would take 2e21 years for even the most powerful computer to brute force (at 5 billion attempts per second, which is impossible).

However, notice the last two characters?  Those are always there due to the format base64 takes and the fact that I'm using 16 bytes.

Is there a reason to include or not include the two '=' symbols?  The argument to include them would be that they add additional symbols and length to the password.  However, if you assume that the attacker knows that I generate passwords using this method (and for security, you have to assume that they know everything sans that actual password), then the two '=' symbols are already known, and therefore add no additional security.  However, can they hurt?

Base64-encoding processes input bytes by groups of 3; each group yields 4 characters. The '=' signs are padding so that the string length is always a multiple of 4; since the '=' signs are not part of the core Base64 alphabet (letters, digits, '+' and '/'), the decoder knows that these signs are padding and don't encode actual bytes. That way, input sequences of n bytes, where n is not a multiple of 3, can be unambiguously encoded and decoded back.

Entropy-wise, the '=' signs do not harm and do not help. You can leave them or remove them as you wish, it would not change anything for security.

(If they hurt, then this means that the password hashing function used in the system is extremely poor and weak, and that would be a problem which should be fixed -- not by removing the '=' signs, but by using a good password hashing function instead.)


How are anonymous cipher suites exploited I was testing a new proxy server today with SSL Labs and found that I had somehow included some anonymous cipher suites.

After resolving the problem I decided to find out what problems this could cause and how/why this was exploitable. To my surprise (considering the report and rating cap from SSL Labs) I was unable to find out much more then its possible to perform a MiTM, where weak ciphers are used.

Obviously I'm not looking for a how to, rather an explanation as to why it is exploitable and what would/could happen if these cipher suites had been left in place? Or is the answer it allows for a MiTM to take place?

While anonymous cipher suites feel bad when configured at the server side like in your case they are only a real problem if the client offers such cipher suites. Only in this case a man in the middle attacker could trick the client to connect to the attacker because the client can be forced to not authenticate its peer. Once this is done it actually does not matter which cipher is used between attacker and server and if the attacker checks for the correct server or not, i.e. there is no need for the server supporting anonymous ciphers for the attack to succeed.


X-Webkit-CSP Security header in the browser What is the X-Webkit-CSP Security header in the browser ? What kind of attacks that we can mitigate from this ?

This is a deprecated HTTP header and it is being replaced by the
Content Security Policy header.  This will prevent prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.

All the X-* policy headers are non standard headers and following headers are also deprecated and replaced by the CSP.

X-Frame-Options

X-XSS-Protection

X-Content-Security-Policy

Ref : https://content-security-policy.com/

https://developers.google.com/web/fundamentals/security/csp/


Will resetting IP stop DDoS? My router has been DDoS'd multiple times (although not taken offline), would resetting the IP stop the attack?

No, it won't stop the DDoS. The DDoS will continue on the host it is targeted at currently. Back to the target in a moment.

Guessing you actually mean will "would resetting the IP stop the attack [on me]," then the answer is possibly. First, this will be highly dependent on your ISPs infrastructure.

By resetting your IP, you could mean that you are resetting the IP interface or it could be that it involves sending a DHCP release/renew as part of the process. Either way, if your device doesn't send a DHCP release, any DHCP server will simply hand back the same IP address as there is still a valid lease for your CPE device.

Even if it does send a DHCP release (i.e. releasing the lease), there is a good chance you will receive the same IP address. Many implementations of DHCP will use the same IP address the CPE device had a lease for previously if it hasn't been leased out to another client.

Either way, you have a good chance of getting the same IP address from your ISP and will remain "under attack." Getting back to the targeting I mentioned earlier, DDoS attacks may be launched against a hostname or a range of IP addresses rather than a single IP address.

So even if you have a new IP address, if you are using a dynamic DNS service and the attack is targeted at your hostname, then you are still the target of the attack. Or if the target is an IP range and your new IP is still within the range, then you will still be a target of the attack. It may take time for the attack to ramp back up, but you will likely experience the issue again soon.

So, what should you do?

Contact your ISP. They may be able to take action to stop the attack without any further involvement by you and this could help others as well. It may even be possible that this is the only way you can stop the attack. Even if you are going to try other options, start this process as it may take the most time.
Give the "IP reset" (whatever that means) a shot, maybe it will help. If it doesn't, you aren't any worse off.
You could try powering off your CPE device for a period of time (10+ minutes but longer is better - maybe power off before going to sleep and back on in morning). This won't help with many forms of DDoS, but it may help with a few if your CPE device isn't online. You may also increase your chances of getting a new IP address from your ISP when you power it back on.
Change the ISP side MAC address of the device requesting the IP address if possible. This will often result in a different IP.
Change your ISP. If your ISP can't stop it and the target is the IP address or range of IP addresses, this may be your only option.


VPN protection against DNS poisoning on AP Does a VPN protect against a malicious DNS configuration on the Access Point?

By my understanding it should, since traffic to the final destination should be encrypted and encapsulated inside packets then sent to the VPN server.
The AP with the corrupted DNS cache might either let the traffic pass because the destination is not interesting, or reroute it, but in this case it should still cause no harm because it is encrypted and only the VPN server can handle it.

I've tried to google this but found no answers and I can't set up a test right now.

This depends entirely on how the VPN is configured. Some VPNs will push their configuration (including DHCP options and the routing table) to your computer, changing your default routes to send all traffic, including DNS, over the VPN. If this is done, then your access point will not be queried for domain resolution and a malicious or compromised access point will be bypassed. To tell if this is actually done, you will need to supply more information, such as your current routing tables and the VPN client configuration file. If you are configuring your own VPN, see the above-linked how-to for instructions on pushing the server configuration (including DNS) to the client.


Can advertisements read cookies of the website it is on? I know many ads can store third-party cookies, but what about reading cookies? If so, what stops them from reading the session id to perform session hijacking?

Any script included into a page can read all cookies for which the httpOnly attribute is not set. Access restrictions for scripts are not determined based on the domain the script was loaded from but only in which page it is loaded into. This means all scripts loaded into a page have the same access and control over this page, no matter what the origin of the script was. Regarding cookies this means that you need to protect any sensitive cookies like session ids with httpOnly if you have included third party scripts which are outside of your control and trust into your page.

But including such scripts into a page working with sensitive data is a bad idea anyway, since such scripts can not only read cookies (unless httpOnly) but also extract information from forms (like login credentials) or change the client side application logic. See also Should I be worried of tracking domains on a banking website?.

Note that these statements apply only to third party script which is directly included into the main page. If the script is instead only inside a third party iframe inside the main page it can neither read cookies on the main page nor access or modify the DOM on it.


Tracing a text message Good afternoon,
Is there anyway to trace a text message? As far as the real phone number that the text is being sent from? Or the location of where the text is being sent from?

I've been getting harassing text messages from someone and when I try to call the phone number back I am getting an automated voice mail (does not seem to be legit) I contacted my cell phone provider but they are unable to give me that information.

Unfortunately no, there's no way for an end user to trace that information. Your cell phone provider should at least be able to trace it back to the SMSC that it was sent from, however they are unlikely to do so without some sort of police request or court order.

If you are being threatened or genuinely harassed then get the police involved, they have the power to compel the phone company to research that. It's their job to deal with these types of things after all. If it's an annoyance you can almost certainly just set up a block of that number on your phone.


How many combinations does a specific password policy allow? Recently I was arguing about password policies. Assume you have a policy which requires 10 characters and additionally at least one letter, one number and one special character. My companion was arguing that this policy is weaker than one that requires at least 10 characters. While this is computationally true, we couldn't agree how many combinations the first policy allows. How many combinations does the first policy have and is it really much less than the second policy?

Your companion is right that the least restrictive policy has a higher potential entropy, as it can encode a larger amount of information. This being said, the entropy of a set of data depends on the probability distribution of each datum appearing in the dataset. Therefore, the quality of a password policy should not be measured in terms of how much information can be encoded, but in terms of how much it prevents different users from using similar passwords.

Simply throwing in mandatory numbers does very little for that purpose, and a site that randomly assigns 7-character long passwords composed of numbers, symbols and letters would probably achieve a higher overall entropy. It's impossible to give an authoritative answer as to whether there is a significant difference of quality between the two proposed policies because:

they both require higher amounts of user memory than most passwords observed in the wild require, meaning neither is likely to have significantly higher amounts of weak password reuse
none of these models is common enough for any public/leaked password dataset to be available for reasoning about probability distributions
there is no generative model of human password choices that could explain how actual humans would make passwords on these sites¹

  ¹ some might claim they have such a model - given the superficiality
  of state of the art research on human password choices, this is very
  unlikely. The latest research only addresses behaviours with regard to
  a unique credential, with populations that are unrealistically
  motivated in authenticating to studied services (because of how
  password behaviour experiments are constructed). Current research is
  also strongly culturally biased towards US/UK individuals as
  demonstrated by Li et al.
  2014.
  Until these limitations are addressed and much more data is
  collected

If you want to understand how to estimate the strength of an individual password the current method to apply would be to implement Bonneau's password strength metrics.


Implications of leaving admin UI accessible to non-admin users I am developing a system to be used internally within a company, but possibly also externally at some point in the future. From the standpoint of the system's initial users - staff, the program is open source, as they have access to the repository where code is stored. They don't have access to server configuration, databases and such.

The system is web based and there are several classes of users, each with their limitations regarding what they can see and do. I'm not going to discuss the exact authentication and authorization mechanisms in use, as I think that would be beyond the scope of the question. Let's assume one is unable to trick the server into doing something he or she is not allowed to do or see (in terms of content, like articles).

However, there is currently just one set of HTML, JavaScript and CSS resources downloaded by all users, regardless of their access rights. I have decided not to have separate versions of all files in order to reduce necessary work.

With little fiddling with cookies you can enable the admin interface as it is included in site resources anyhow. You can see what it looks like and you can see what it could do. Meanwhile, you cannot actually do anything with it, as the server would know you are not a privileged user and decline to satisfy any requests you make, that you wouldn't normally be able to do.

I can't find any issue from usability standpoint as only "hackers" would run into a glitched admin interface and no regular users.

I am looking for negative implications from security standpoint.

My questions are:

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?
Is having such functionality exposed a really bad practice I should immediately address?
If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

It may be easier to exploit vulnerabilities such as CSRF or missing access control if an attacker has access to the client-side code and thus to the requests that may be performed.

It may also be easier to find vulnerabilities such as XSS. Vulnerabilities such as XSS may now also target lower-privileged users as well as higher-privileged users, as both have access to the UI.

  Is having such functionality exposed a really bad practice I should immediately address?

Not really. If it's not needed, I wouldn't expose it though, because of the reasons outlined above.

  If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

If it's open source, it's not even security by obscurity, and hiding it isn't strictly necessary (although still not a bad idea, especially because of the possibility to exploit XSS vulnerabilities).


Stripping / appending characters from user password before hashing to conceal it forever? I had this idea to permanently conceal user password by requiring minimum length then stripping certain characters. For example if the user password is secret123, the system will strip it down to ecrt12, add random characters to it like ecrt12!@#$%^&* before hashing, adding salt, etc, then storing to DB.

Granting all common practices were also used like:

unique salt per user
system pepper
bcrypt/scrypt or whatever latest best crypto algo available

To summarize in code:

$hash = hash($modifiedpassword.$uniquesalt.$systempepper) // iterated to 1000s.

In the event an attacker manages to reverse all hashes, the best info they could ever recover is ecrt12!@#$%^&* and not the original secret123. Even if they hack the system code, they will never know what characters were stripped.

My question now is as security experts, would you recommend this practice of stripping/appending the original user password?

How would you guarantee that the "same" random characters are used every time the same user enters their password? You can only guarantee that if you write them down (or otherwise deterministically generate them), so "!@#$%^&*" in your "password" is actually just another part of the salt.

This leaves you in a situation where you've converted the user's password from "secret123" to the regular expression "^.ecret12.$", which reduces the password's effective complexity from 9 characters to 7 characters. An attacker who tries "pecret129" will be allowed in.

To answer the question directly and to borrow a quote from ewanm89 below: no. I don't recommend doing that.


Which would be the best "keyfile" for KeepassXC and/or Veracrypt? I am a Mac user. I opened a keyfile generated by Veracrypt and one generated by KeepassXC. The texts in both of them were quite short. Which keyfile is best (i.e., most random and harder to break through): one generated by Veracrypt or one by KeepassXC?
OR: Is it best to create my own keyfile?: I can open a photo with TextEdit, copy and paste the gibberish that shows up in an empty TextEdit file, save and use that as my keyfile. Is that be better?

I also wonder if it is best to use another type of file (a .jpeg photo, maybe) as a keyfile. My thinking is: files generated by Veracrypt and KeepassXC may stand out (assuming someone broke through my device and started looking).

Would anyone recommend embedding a file in a picture (steganography) and use it as a keyfile instead?   How can I do the embedding in Mac? I am familiar with Terminal.
Thank you in advance.

to be honest, there is no Best one.
Its all about keeping the file safe, and keeping access to it.
I recommend using a flash-drive with a few (strategically dispersed) copies.
as for the entropy of the file it self, size beats all. but does cost more memory to decrypt. the algorithm that uses the key-file will hash-up the source data anyway so do not worry to much about the entropy of the file itself. just do not make it predictable what file it is, and ensure you can not just lode said file.
and a file is only 1 Factor for decrypting, you are better to add another (something you know or something you are).
the key file represents something you have (together with the database/encrypted file itself)


How to forbid one directory only in TOMOYO (2.5)? (For example) I want to restrict write access to /home/backup from anybody, except a particular backup script. (To protect from accidental deletion.) For this, I suppose, it is enough to have two domains: <kernel> and </usr/bin/backup-script>. And I need to enable for <kernel> access to everything except write access to /home/backup. How to do that exception? I don't see exclusion rules in TOMOYO policy specification, and the general ideology of TOMOYO is only granting access, not forbidding.

Acutally no need to exclude kernel.
You can tell though files /home/backup/\*{\*}\* may only be changed if domain "<kernel> /usr/bin/backup-script" does access.

relevant links from Tomoyo Guide:

http://tomoyo.sourceforge.jp/2.5/policy-specification/exception-policy-syntax.html.en#path_group
Chapter 5-8


Coverage of OSCP training Is there any part related to penetration that OSCP/OSCE fail to cover in their training programs?

How much will I be exposed to penetration techniques after completing OSCP/OSCE?

They are very highly regarded and for very good reason, however, you're still going to have to continue to learn and evolve as a penetration tester. You'll be exposed to vulnerability detection, penetration testing and exploit writing with Offensive Security exams, however, you are still more likely to see a company looking for CISSP, CEH and/or GIAC certifications in their job descriptions. How much you're exposed to penetration testing afterwards depends on you I guess.
I don't believe they cover wireless or in-depth web app stuff and I'm unsure how much of the targets is Linux-based because I've only ever heard of Windows targets (I suspect there is a good amount of Linux, it's just not talked about).
I believe there's still a lot of stuff related to Windows XP vulnerabilities though I don't know what the percentage. I know there's now Windows 7 and W2K8 stuff, however, it's only natural that there'll be XP testing because it's still very popular and it's got to be a real pain keeping the course content (after all the principles are normally the same regardless of the target).
The real benefit of doing those courses, afaik, is that you not only learn how to compromise a device and hide your tracks, but you also learn how write exploits, look at shellcode and perform reverse-engineering, which means you'll understand better what's going on.
SANS have some excellent courses on penetration testing also (disclaimer: I've done a few of them) but they're somewhat more expensive. There's plenty of other discussions on this forum regarding SANS training so I'll let you search for that yourself.
You should view OCSE/OCSP as only a start.....


Windows Servers in DMZ - managed via AD or standalone? From a security point of view, does it make sense to connect the Windows servers that are running within the DMZ and should be reachable from the Web to the AD (running within the core network)? Or rather manage them by a DMZ AD or just standalone?

In my understanding it is a security risk to leave ports open towards the core network, but there may be a demand for an adequate solution when it comes to managing large scale environments? Are there any other approaches out there like e.g. placing them on AWS/Azure and managing through a Cloud AD separated from the network?

Your reasoning is exactly right.

Your DMZ servers being joined to your internal domain is a risk that should be avoided. Usually a separated Active Directory domain for your DMZ, or running each server standalone is the best option.

A small environment might be fine with standalone, but beyond a dozen or so servers, or with a larger team of staff, a separate domain might be easier to manage. You might have a trust existing between your DMZ domain, and internal domain, but it should be managed with care.

You'll always have a need to connect parts of your DMZ to your internal network (proxy servers for example), but it should always be on a strictly as-needed basis. Plus, if your DMZ does become compromised, and someone can steal the credentials of a DMZ Administrator, they won't automatically have access to your internal domain.


What's the best way to send and receive lots of login credentials? I'm currently a web developer for a company with lots of different remote clients. There are lots of usernames and passwords that I need to know so that I can do my job. When I first started, I was able to obtain a good chuck of credentials by reading them off my boss's computer. I stored them on my computer, in 1Password. However, as time went on, it became more convenient for my boss to email the credentials I didn't have, sometimes over https, sometimes not. Also, sometimes the clients themselves need to send me their login credentials, for example, so that I can access their hosting account.

It seems like I get new credentials fairly frequently. Some of the clients I work with aren't too computer savvy, few are. Are there any somewhat simple ways to improve security in this system? I doubt that most of my clients would know how to encrypt their credentials with their private keys. I've been working for this company for about 6 months now and already I've had to help a client clean up his site because it got hacked. Though, to be fair, I'm not sure how often our clients get hacked.

Is there something I can do to improve this system or are we just doomed?

First, you can't e-mail over HTTPS.  HTTPS is a web site protocol, not an e-mail protocol.  Encrypted e-mail exchanges require the mail servers to communicate using TLS or SSL.  The best way to exchange credentials, if you absolutely have to do it, is to encrypt them with a secure, long password or better yet, a pre-shared key or using a secure key that is shared using asymmetric cryptography to prevent the key from being accessible to someone reading the e-mail.

Secure FTP is also another viable option if you have a secure FTP site that can be used.  Again, high security passwords should be used.

SFTP is probably the simplest since you can install a fairly simple client to let them upload it with.  Most e-mail encryption setups are going to be overly complicated for an average user unfortunately.

The ultimate easiest way would be to use some kind of HTTPS website that would allow them to submit the credentials and protect them with a random key that would be encrypted with a public key that only allows the credential key to be decrypted after the credentials are removed from the web connected machine.