How do I securely deal with SSL certificate validation failure when the client date is incorrect? I have an application that runs in mobile devices and connects to my server via HTTPS.

At times the connection fail because the device has a date set in the past (before the 'valid from' date on my certificate).

I can change the application code running on the mobile devices and also can change things on server side, how do I fix that?

I'm investigating 2 possibilities:

Pick the current date from the server response and change the client application to use that to validate the certificate ( I know the date is available at least from the "Date" http header). Can I / should I interfere in the validation process like that?
Try to buy a certificate valid since 1/1/1970 (which is the date some of the mobile clients assume) and up to 1 year from now. Do you see potential issues in that?

Any other options to go around this?

Using the date from the server itself is self-defeating: a fake server could send a fake date.

Actually there is in SSL itself a field for the date: the first four bytes of the client_random and server_random fields contain the current date and time, as known by the client and the server, respectively. This implies the following:

A passive attacker, eavesdropping on the line, can detect clients whose clock is amiss.
An active attacker, running a fake server, can know the client's date and time, down to a precision of 1 second.

The attack scenario here is an attacker who has stolen an server's private key. The certificate has been revoked; however, the attacker also obtained CA certificates and CRL which "proved" the certificate to be valid at various previous dates. The attacker, in position to do MitM, then runs a fake server and emulates the Internet at that time, in particular sending back to the client the past CRL bearing the date that the client believes to be current.

An out of date client may make connections fail in case their current date is too far in the past, or too far in the future. The normal recovery for that case is to complain to the user, so that he sets the date and time properly. On a pure theoretical basis, there cannot be any other method which always works against MitM attackers: such an attacker can, as I said, "emulate" an old version of the Internet (as a whole), thus preventing the device from obtaining the true current date or even noticing that its clock is not set properly.

You could try to obtain a time stamp from some Time Stamp Authority; however, this implies validating the TSA certificate, or, more accurately, assuming that the TSA private key has never been stolen. So, in practice, it is possible to make a reasonably strong guess of the current date and time in a way which attackers will find difficult to fool. But that's expensive (extra connections to TSA) and depends on these external TSA, who might not be free and/or might not agree with getting so many time stamp requests from your deployed devices.

Edit: if you do revocation checks with OCSP, and the client insists on including a nonce in the request, then you get (somehow) the same property as with the TSA -- with the same caveats: you still have to assume that some entity's key has not been stolen (TSA, OCSP responder, CA...), and you still need to do extra connections.


Firewall UDP Packet Source Port 53 Ruleset Bypass I have a question regarding recent PCI DSS scan performed on our network.

On some of the Windows 2008 servers (physical and VM), there is a risk found "Firewall UDP Packet Source Port 53 Ruleset Bypass".

Windows firewall profiles are kept off due to application team requests, hence I am wondering if we create a rule to block inbound UDP 53, will that work?

How can we remediate this risk in such case? Please advise.

It sounds like any UDP packet is allowed to your servers if the source port is UDP53. You'll need a rule which monitors session state, likely a firewall (hardward or host based), so this traffic is only allowed if your servers already sent an outgoing request to the DNS server on UDP53.


Secure Linux Desktop I'm looking for hints about secure linux desktops. Securing servers is no problem. Most recent Software Updates, run only the services required etc. But what about desktops? I'm thinking about details like Noscript for Firefox. ASLR, PIE and similar are enabled in Ubuntu https://wiki.ubuntu.com/Security/Features by default. What should I change additionally? Are there any distributions focusing security?

I recommend the following steps, in rough order of priority:

Enable automatic updates. This is the best way to ensure you are always running the best, patched version of all software.
Turn on a firewall. A simple policy often suffices for desktops: roughly speaking, allow all outgoing connections, block all incoming connections.  This is a lot easier than tracking down all services that might be listening and disabling them; simply blocking all incoming connections by defaults closes the exposure.
Enable automatic backups. Set up a backup system to automatically and routinely backup your system, without your involvement.  This is one of the best ways to ensure you can recover from a compromise.  Security is more than just prevention; it is also about enabling rapid and reliable recovery from compromise.
Use HTTPS Everywhere. Install HTTPS Everywhere (or ForceHTTPS, or equivalent) into your browser, to ensure you use HTTPS (SSL/TLS) on every site that supports it.
Use SSH. For all remote logins, use SSH.  Create a private keypair.  Protect your private key with a password.  Put your public key in the authorized_keys files of all accounts you want to be able to log into remotely.  Avoid all unencrypted traffic (e.g., telnet, FTP, IMAP, POP); use encrypted variants instead.
Encrypt email traffic.  If you use a mail client with POP or IMAP, configure it to use SSL/TLS protection (e.g., imaps instead of imap), so that the connection with the mail provider is encrypted.  Most good email providers will offer an option for connecting via SSL or TLS.
Use an email service that scans your email.  Use a good email provider with a good reputation for blocking spam in incoming email.  Good spam-blocking software often will also block many email-based scams, phishing attacks, and worms.
Optional: Consider full-disk encryption.  If you have a laptop, you might want to enable full-disk encryption, to protect against data breach if the laptop should be lost.  Truecrypt and PGP's product have a good reputation.  If you use Linux, most Linux distributions will enable you to set up full disk encryption when you install the Linux OS.
Optional: Enable SELinux. Turn on SELinux, if you use a distribution that supports it.
Optional: Harden your browser.  You might consider modifying your browser settings to protect yourself.  e.g., consider disabling third-party cookies.  Consider installing AdBlock Plus.
Optional: Log out, when you're not present. Whenever you leave your computer unattended, you might want to log out (or engage a password-protected screensaver).


Why does node.js scrypt function use HMAC this way? According to the documentation, the scrypt hash function works like so:

  The hash function does the following:

  Adds random salt.
  Creates a HMAC to protect against active attack.
  Uses the scrypt key derivation function to derive a hash for a key.

  Hash Format

  All hashes start with the word "scrypt". Next comes the scrypt
  parameters used in the key derivation function, followed by random
  salt. Finally, a 256 bit HMAC of previous content is appended, with
  the key for the HMAC being produced by the scrypt key derivation
  function. The result is a 768 bit (96 byte) output:

  bytes 0-5: The word "scrypt"
  bytes 6-15: Scrypt parameters N, r, and p
  bytes 16-47: 32 bits of random salt
  bytes 48-63: A 16 bit checksum
  bytes 64-95: A 32 bit HMAC of bytes 0 to 63 using a key produced by the scrypt key derivation function.

  Bytes 0 to 63 are left in plaintext. This is necessary as these bytes
  contain metadata needed for verifying the hash. This information not
  being encrypted does not mean that security is weakened. What is
  essential in terms of security is hash integrity (meaning that no part
  of the hashed output can be changed) and that the original password
  cannot be determined from the hashed output (this is why you are using
  scrypt - because it does this in a good way). Bytes 64 to 95 is where
  all this happens.

My question is why does it use the scrypt hash as a key for the HMAC algorithm rather than just returning the scrypt hash directly? What extra protection does this give? It mentions "active attacks" but doesn't give details.

I created the Node Scrypt module.

HMAC adds additional security. Using it also lends the scheme to be used as a header in an encrypted file format (like it is done in tarsnap) and not just in an authentication server's database. Also, Colin Percival (who created scrypt) uses this scheme to verify (I actually just copied it from him).

To explain why HMAC is used, lets have a quick recap. When encrypting something using the scrypt key derivation function, a 96 byte result is produced with the following break down:

 bytes 0-5: The word "scrypt"
 byte 6: 0
 byte 7: logN
 bytes 8-11: r
 bytes 12-15: p
 bytes 16-47: salt (which is 32 bytes)
 bytes 48-63: A 16 byte SHA256 checksum (hash) of the contents of bytes 0 to 47
 bytes 64-95: A 32 byte HMAC hash of bytes 0 to 63 with the key being the scrypt cryptographic hash

It is vital that bytes 0 to 47 be in plaintext (not altered or encrypted in any way). To ensure this, there is a 16 byte SHA256 checksum. Now while SHA can be used quite effectively as a checksum (specially in this case), it cannot guard against an active attack, meaning that someone has got hold of the payload, substituted their own values. For example, I could get hold of the payload, calculate my own logN, r and p as well as my own checksum and then pass that off as the original.

To guard against this happening, the final 32 bytes is HMAC. HMAC is used to ensure message integrity (i.e. guards against anyone actively changing a payload) and is a workhorse of the cryptographic arsenal (read: it is safe and secure to use). HMAC requires a key, and we use the scrypt hash as the key.

If the final 32 bytes were just a scrypt hash, then nothing would stop an active attacker from being able to compromise everything and substitute their own scrypt hash. The HMAC protects against. It not only serves as a means to verify the scrypt hash, but it also checks the integrity of the entire scheme.

BTW: People may be wondering why the checksum (bytes 48 to 63) is required. Well, if you think about it, we need to calculate the scrypt hash so it can be used as a key for the HMAC. So the checksum adds an additional level of checking: If it does not pan out, then the verification immediately returns false without going any further.


Is Common Criteria (CC) a suitable standard to certify web applications I never came across a web application that has been certified according to Common Critera. As far as I know there isn't even a protection profile available for web applications.

What is the reason for this? Is Common Criteria not suitable for web applications? What are the main problems?

No.  In practice, the Common Criteria is not a great tool for assuring or evaluating the security of a web application.  There are a number of reasons:

There's plenty of knowledge about how to evaluate the security of a web application.  There are companies who will do that for you (e.g., Whitehat Security, Cigital, and many other companies).  We don't need no stinkin' standards.
Common Criteria a clumsy, heavyweight tool.  Based upon experience in other industries, it would not be a good match for the rapid innovation and agility in web applications.
Common Criteria evaluations are expensive and they often aren't as effective as one might like, so they're probably not an efficient way to evaluate the security of your web application.
My sense is that Common Criteria evaluations often lean too heavily towards a bureaucratic exercises in ticking off checkboxes.  Also, Common Criteria evaluators suffer from a conflict of interest (they are paid by the folks they are evaluating, which tends to lead to a least-common denominator syndrome where evaluators tend to be a bit lax).  As a result, I've seen highly insecure products certified under the Common Criteria.
Common Criteria evaluations are time-consuming, so it's not unusual for a product to be almost obsolete by the time it is certified.
As far as I know, there is no "protection profile" for web applications.  In principle, Common Criteria is happy to let you certify anything, if there's a "protection profile" that specifies what the security requirements and threats may be.  Since there is no "protection profile" for web applications, you couldn't certify a web application to the Common Criteria even if you wanted to.

To summarize, Common Criteria primarily solves a compliance problem, not a security problem.


Would the theory of creating tons of duplicates of a small file, 'wipe' the hard drive? Mentioned here: https://discussions.apple.com/docs/DOC-5521

I was just curious if this would really work. It makes sense to me. As long as they don't do reverse forensics on the bits on the hard drive... But does that happen often?

Not surely.

If there is some data deduplication mechanism in the disk - even if it is only a side effect of its wear leveling mechanism - then your data multiplication will only result the low-level overwrite of only a small part of the disk, and not the whole one.
If your file size is smaller, or isn't an exact multiplicate as page size of your CPU architecture, or as the physical sector size of your disk, then the last part of them may left without overwrite.
Even if you fill all of the allocatable space in your filesystem with files, there may be blocks in the filesystem - directory entry tables, i-node tables, MFT, file metadata, cache/index data, any reserved data area - which won't be overwritten.
Also the wear leveling mechanism can have a hidden reserved area for free / unused blocks
Simply trimming (de-allocating the block on the hardware level) doesn't surely destructs all of its data. In many cases it only says the wear leveling mechanism, that it can re-use the block, and doesn't overwrite anything. Thus, not overwritten blocks may still remain intact, even after a block-level rewrite with random data (the idea what they suggest is much weaker as this).

In case of an Apple site, the probable reason behind that they suggest a lot of small files, that they have fear from filling the disk with a large, single one. But, if you want to make sure without block-level overwrite, this is what you had to do. On any unix system, incl. OSX, there is a command dd command for that, but there are also a lot of disk wiping tools for that.

In case of SSD: the disk sectors of an SSD disk can be overwritten only 10000 - 100000 times, after that they will die. The SSD controlling electronics has an internal reindexing mechanism to balance this load (some sectors are overwritten many times, these are re-mapped through the disk sectors). This is the wear leveling, and this will be overloaded if you overwrite the whole disk with random data on the sector level. Essentially, all of your data blocks get a single hit of overwriting. But a whole-drive wiping is not an everyday thing in the life of an SSD disk, doing this once is yet negligible harm, but it is better to know.

You can find some relatively sure ways to wipe the disk here.

On my opinion, a common "mortal" never meets technologies or organizations capable and willing to do such low-level data recovery techniques. Thus, the many question cycling on the about this is grounded mainly on the serious over-estimating the real threats.

For example, if you are a commoner trying to wipe a hard disk before selling it, a simple reformat will be enough. If it contains your very sensitive data, then wipe it with a specific tool. Even the forensics won't (be able to) go deeper.


Access-Challenge EAP Request From my understanding, after the Access-Request, the authentication server (RADIUS) sends a reply (encapsulated in the Access-Challenge packet) to the authenticator (AP).

The Access-Challenge packet contains an EAP Request in which it is specified the EAP method that the supplicant should use.

The supplicant can then acknowledge that EAP method or NAK it and replying with another EAP method that can be used.

My questions are:

1) In the EAP Request are both the EAP method and inner authentication specified?

2) Is it possible for the administrator of the RADIUS to specify a default EAP method and inner authentication, such that the EAP Request would contain always the chosen method?

3) It is possible, by using scapy, to edit the EAP Request and specify another EAP method and inner authentication?

No and yes, the nature of the inner request is that it's within a tunnel.  A great example is here: https://mrncciew.com/2013/03/03/eap-overview/   It looks like the Tunneled method is specified in the last request outside the tunnel.
Depending on the Radius server this is totally possible.  One way to force this would be: limiting available auth types to only the ones you want.
Yes, absolutely Scapy is the packet swiss army knife.  it looks like someone else has already done some of that work: https://github.com/rpp0/scapy-fakeap


Security requirement disk quotas When reading about security measures for operating systems I found the recommendation that disk quotas should be used. I thought that is just a general IT requirement to ensure everybody got the same space, hence this requirement targets availability only.

Besides this reason can somebody explain to me what security consequences it could have when disk quotas are not enabled?

Assuming absolutely no quotas are enabled, not even the default ones in many filesystems that give root a little more free space than other users, a malicious process could write to the disk until it is completely full. This would prevent any other program, even privileged daemons, from writing to the disk. This could lead to a denial-of-service condition and may interfere with important tasks:

Passwords may fail to change, as it often involves writing a temporary file.
Logs may stop being written, allowing one to attack the system without leaving traces.
Software updates may fail, leaving outdated and exploitable software on the system.


How is Tails operating system tested to make sure its authenticity It's said that tails is the most secure OS ever, but has anyone tested it? i.e How is it known that tails does not do operations such as:

sniffing on your own network and sending your data to a 3rd party
sending your machine hardware information to a third party and so on

How is it proven that it's actually safe and not made by a bunch of hackers.

The Amnesiac Incognito Live System, or TAILS, is a project of the Tor Project.

One can attempt to verify whether or not such an OS is benign on their own in a lab environment. Of course, there is the possibility of third-party verification by combing signatures, looking for anomalous code, watching network traffic and otherwise looking to see what the OS does on test/lab machines to see if it is working as indicated.

As Bruce Schneier has astutely elucidated, security issues come down to a matter of trust.  In this case the question is, do you trust the Tor project and the TAILS developers?

How do you know if you can trust Tor?

Start with the people: https://www.torproject.org/about/corepeople.html.en
You can see one of their lead developers is Jacob Appelbaum, of NSA surveillance outing/WikiLeaks fame, among others of note.

Then look at the track record of the organization.

From there you may be able to come to your own conclusions about the Tor organization and whether or not you'd trust them.  My personal opinion is, yes, for now I do trust them and they have strong and good ethics.

Also remember to verify signatures when downloading ISOs to ensure integrity in transit.


Collect XML files from web server with secure authentication I need to collect XML files from a 3rd party's web server.

These XML files are generated by said 3rd party on a daily basis (e.g. data_2015-11-26.xml) and should therefore be fetched at least daily as well, by a scheduled task of some sort, probably running on a Windows Server based OS. The files will be imported into an ERP system later on.

The suggestion by the 3rd party was to implement this with Apache's .htpasswd, i.e. password-protecting a directory with HTTP basic authentication, but over HTTPS.

I hope this question isn't too vague, but would this approach be "reasonably secure"?

What other (better) options are there? Would it make sense to additionally encrypt the XML file itself?

I'd like to keep this fairly simple, while also considering security.

The "level" of security for this really depends on what the XML files contain. If the XML files confidential data then you may want to explore further techniques than discussed here.

The suggestion of using basic auth can work however there are many reasons why you should consider using a different authentication method which has been discussed in the following question,

https://security.stackexchange.com/a/990/80801

If you're using SSL/TLS then you're more than likely fine using basic auth just consider the points made within the questions above. Another technique you may wish to consider is restricting access to the end point to only certain IP addresses. I would personally recomend using some form of authentication method provided by a framework of your choice rather than attempting to roll your own at any point.

As for the question about encrypting the files.... It wouldn't hurt to throw them into an encrypted zip as an additional layer of security. Ideally this would be protected with a different password / passphrase than the basic auth which is preshared between yourself and the third-party client.


Is it secure to have one salt or generate and send it over the air? To authorize user I'm sending salted hash over the air. My question it is more secure to obtain randomly generated salt (but send unencrypted), or have one salt on client (desktop application) and server?

For security, neither is secure. Sending a hash from the client to the authentication server does nothing to protect against password sniffing because the hash is acting as the password.  The only thing sending a hash does is to mitigate against password reuse attacks (eg. Preventing an attacker from using the same password on site A for site B).

Also keep in mind that salting a password mitigates against rainbow table attacks and nothing more. Salt is not considered private information, so encrypting the salt is a useless operation doing nothing to increase the security of the authentication process.

Without using encryption, or having a dedicated line, you cannot send authentication tokens in the clear and maintain security. Turn on SSL to create an infinitely more secure environment.


Which block cipher for a very short (40-bit) message? Question:

I'm trying to encrypt a 32-bit message to produce a ciphertext no longer than 40 bits. Are there vetted block ciphers or other good ways to encrypt very short messages? Are there any well-known ciphers with a block size this small?

Context and motivation:

Video games for retro platforms may have a campaign longer than one sitting but no nonvolatile memory for storing the campaign's state. To continue a campaign across a power cycle, the game issues a "password" and has the player enter it next time. This password is a short encrypted message containing the state of a campaign plus some extra bits used to ensure that randomly entered passwords or passwords with a few bits flipped are unlikely to work. For this application, the 32-bit message includes which chapter the player is on, quest flags, money, experience, and the like. A typical password has 8 characters with 32 possibilities (5 bits) per character (digits, consonants, and hyphen), for a total of 40 bits. Longer passwords are far more tedious to write down and key in.

I'm unaware of any well-known cipher with such a short block size. Ciphertext stealing works when is longer than one block but not an exact multiple of a cipher's block size. For example, if there were a 32-bit block cipher, one could encrypt the first 32 bits and then the last 32 bits, which touches the middle 24 bits twice. But as far as I can tell, it doesn't apply to a message shorter than a block. So currently I'm using a homemade cipher (yes, eww) with a structure inspired by XXTEA, with five 8-bit words instead of several 32-bit words. After packing the campaign's state into the first 32 bits, I pad the remaining bits with a constant before encryption and reject passwords where the padding does not decrypt to the desired constant. Is there something better for a 40-bit block than rolling your own?

Encryption and decryption need to run on an 8-bit microprocessor in under a million cycles. I'm worried about online attacks and pencil-and-paper attacks by bored gamers, as have been posted in the "Classified Information" section of Nintendo Power magazine. But I'm not quite as concerned about automated attacks by someone reading the algorithm and symmetric key out of the game's code and using this information to put a password generator on a website, as this would take conscious effort on a player's part to cheat at the game.

The generic name for that kind of stuff is format-preserving encryption. The Thorp shuffle is a nice candidate, provided that you use an adequate round function (e.g. truncated output for a cryptographically secure hash function) and enough rounds, as indicated in the paper.

That being said, with 1 million cycles on an 8-bit computer, it may be hard to run, say, a 64-round Thorp shuffle with a truncated SHA-1 as round function.

Unfortunately, there is no standard, well-studied block cipher with short blocks and good performance on small architectures. On the other hand, your attack model states that attackers won't try really hard, so you don't need absolute crypto-grade security; a construction which is academically weak may still be strong enough for you.

I suggest you skim through this page that lists "lightweight block ciphers" with some analysis. Some of them offer 32-bit block size. What you need is such a block cipher, such as there is a known attack on a reduced number of rounds, thereby indicating that some cryptographers tried to break it, and did not succeed for the full cipher. From a cursory look, at least KATAN, KTANTAN, SIMECK-32, SIMON-32 and SPECK-32 match these criteria; RC5 might also be usable with an adequate number of rounds.


Responsible Disclosures and Getting Sued Lots of websites like Google, Facebook etc acknowledge the white hat hackers on their sites for reporting security vulnerability. But for the vulnerability reporter is it safe from legal perspective ? Also how can the company "trust" the reporter that the reporter himself has not taken up any "benefit" from that vulnerability.

I have been reading about GCIH, where the instructors guide about the responsible disclosures but it should be first signed and approved that I am authorised to carry out the vulnerability assessment, but does not understand how websites/companies over internet are acknowledging people for reporting issues.

Thanks in advance !

Welcome to the conundrum of the security business and why it is more profitable to be a bad guy than a good.

Remember this about "getting sued"... Anyone can sue anyone - even if there is nothing justified to sue over. If an entity has money to sue the entity that doesn't have money to fight it looses, almost automatically. 50% of the time or more, if you get sued for some of these things, you are also having to fight off state or federal (or your country's equivalent) criminal or regulatory authorities at the same time.

This is why insecurity will always reign, and why I am sure no one wants any of it fixed.

Here in the US, if you even inadvertently find an issue and report it to a product owner you could be facing their civil (sue) wrath, you could be facing DMCA and others. What do I mean by inadvertently? I could be debugging what I think is an issue with my local machine acting wonky and decompile, or source code from a 3rd party (where I find the problem). Now remember, they are causing the problem to MY machine and I am trying to figure it out... As soon as I find it, and report it, I could be in this grey area.

And I am not even "hacking" per se.

So the rules have been written badly and poorly to really allow for public disclosure. I think that is why organizations that want bugs and security concerns to be found have create very open and clear "bug bounty" programs and do so with a very "open kimono" approach.

What I have seen work in absence of those, is to do what a lot of researchers do... set up anonymous accounts that you can report the information to the organizations to, and don't take credit for it until well after it has been taken care of - I guess that is unless you are hacking Facebook. Seems like everyone is in Facebook's face hacking it aggressively and publicly :).


Does Bitlocker qualify as the 'Cryptographic Module' defined in FIPS140-2? Wikipedia defines Bitlocker as:

  BitLocker Drive Encryption is a full disk encryption feature included
  with the Ultimate and Enterprise editions of Microsoft's Windows Vista
  and Windows 7 desktop operating systems, as well as the Windows Server
  2008 and Windows Server 2008 R2 server platforms. It is designed to
  protect data by providing encryption for entire volumes.

I've heard that some maybe using Bitlocker for drive encryption in order to comply with FIPS 140-2.

  The National Institute of Standards and Technology (NIST) issued the
  FIPS 140 Publication Series to coordinate the requirements and
  standards for cryptography modules that include both hardware and
  software components.

Does Bitlocker qualify as the cryptographic module defined in FIPS 140-2?

Are there any other pieces that are needed to fulfill the need for FIPS 140-2 security level 1 'cryptographic module' requirements?

Bitlocker is a FIPS 140-2 certified module with certificate number 1339.  It is important for you to read the FIPS security policy to determine if the operating conditions conform to your environment.  For example:

The BitLocker™ components (Windows Server 2008 R2 versions: 6.1.7600.16385, 6.1.7600.16429,
6.1.7600.16757, 6.1.7600.20536, 6.1.7600.20873, 6.1.7600.20897 and 6.1.7600.20916; SP1 versions: 6.1.7601.17514, 6.1.7601.17556, 6.1.7601.21634, 6.1.7601.21655 and 6.1.7601.21675) identified in section 4 have been validated on the Microsoft Windows Server 2008 R2 and Microsoft Windows Server 2008 R2 on x64.


Authenticating a user via SMS I'm involved in a project that's building a chat-bot that users can communicate with via SMS from their mobile phones. We'd like the users to be able to use the bot to do some basic account-management tasks over SMS for their accounts with us - changing their base plan, purchasing additional features, etc.

We're wondering if there's any way to (reasonably) securely identify that the user sending the text message is truly the account owner? Options we've considered are 1) ask for the last 4 of the user's credit card and 2) send a one-time-use passcode to the user via email.

Obviously, neither of those provides air-tight security, but the liability involved here is fairly low. If somebody loses their smartphone, the charges that the thief could make using this chat bot would be the least of the person's worries. In the rare event that somebody's phone was compromised, we'd be willing to eat the costs necessary to make the user whole.

However, we'd still like to make this identification process as secure as possible. Problems we see:

With scenario 1, the last 4 of the credit card are potentially left in the SMS history, so anybody who gets the phone (or installs a malicious app) has access to the last 4 of the card and can now authenticate.

With scenario 2, anybody that has access to the phone has access to the email, so it's not really much of an improvement over 1.

Are there any other techniques that we could use to authenticate that might provide more security than those two methods? I'm aware nothing will be air-tight, but I'm looking for good suggestions.

I've considered something like send a salt, have them compute a hash of their last-4, and send it back, but that's prohibitively complex, and still not much of a security improvement.

It sounds like what you're looking for is an "out of band" code or token. This means you want something that's not accessible to someone who physically has the phone. So things like emails and Google Authenticator are out.

I'm assuming that users will do (at least) first-time account setup through a web-browser, what about having them enter an "SMS PIN" which the chatbot will later prompt them for?

This is similar to using the last 4 digits of their credit card number in that it will be in their SMS history and a phone thief can make charges to your chat bot. What makes me nervous about CC digits is that for convenience of your service, you are increasing your users' risk of identity theft.

As you pointed out in your question: if the user gets their phone stolen and the attacker gets past the lock screen, they're kinda sunk anyway. What you are really protecting against is somebody impersonating your user from a different phone through SMS spoofing the from: number. In this regard either an email one-time password, or a pre-set pin will give you the security you need.


Why is CBC-MAC insecure for variable length input? Can anyone explain why CBC-MAC is not secure for variable length message?

I read many books, but there are still some confusion. Like the highlighted parts in following pictures

Slide 32:

Slide 33:

First question, why need to set T"=C0?
Second question which is biggest question i don't understand, why T"' = T". How to prove this relationship?
Third question, why is new message = P0.P1.(P0 xor T')?

Can anyone help me. Thanks!

In its plain form, CBC-MAC is vulnerable to "length extension attack", where you just add some blocks at the end.

So in order to stop people from doing that, you need to somehow mark the final block as indeed the final block. And not treat it like any other block.

Wikipedia lists two ways: either prefix with block count, or encrypt final block with independent key (This is then known as "Encrypted CBC-MAC" or ECBC-MAC).


What is the risk of someone else having access to your SSL certificate? Over the last couple of years, there were a few instances when some third party managed to create a SSL certificate for a domain that doesn't belong to them, for example google.com, or most recently github.com.

In my limited understanding, accessing a signed web site means my browser will compare the domain I'm accessing with the certificate it offers. So, if I somehow manage to get people to my phishing site called g00gle.com using the google.com certificate, my browser should complain that the certificate is not valid for this domain.

Obviously, I must be missing something here, this wouldn't be all over the news otherwise. What kind of mischief is possible, or likely, using a valid SSL certificate that points to someone else's domain?

It is not needed to get a forged certificate for g00gle.com. The person behind the phishing site just needs to obtain a regular certificate for that domain. Of course requesting such a certificate may fail as a computer or a human may be triggered by the likeliness to google.com. But otherwise any owner of a domain can create a key pair and send a certificate request to any commercial CA. Note that registering has the nasty side effect of making yourself known to the CA.

It's not possible to use the orginal google.com certificate. The certificate contains the information about the site / site owner, the issuing CA and the public key. You would need the private key as well to use the google.com certificate.

The problem with certificates issued to rogue parties occurs during man-in-the-middle attacks where the communication can be routed to another computer. In that case the attacker can choose to intercept, read and change traffic to e.g. google.com. The attacker may also impersonate the server or anything in between.

In the case of google.com the Iranian government was involved. As it controls (most of) the infrastructure of Iran's internet the routing to another computer is easy. More close to home (for most of us), attackers can also setup rogue WiFi access points and use that to route traffic.

Note that plain DNS doesn't contain security measures, so anybody controlling the network also controls the way that IP addresses are mapped to names and vice versa.


EML file type analysis I'm working on finding infection points in EML file format. Want to know on what grounds does a scanner declare an email as spam or attachment as malicious?

I mean does it scan by MIME content or any other pointer, Is malicious content detectable based on just file type/MIME content?
How is the attachment scanned?

I had put the EICAR test string on a check against ESET scan to detect it as malicious, but the file came out clean, whereas all standard anti viruses declare the EICAR as antivirus test or something  of sorts.

Spam and malware detection on mail files is done with a variety of techniques. To give you some idea of the techniques and heuristics involved here are some examples. Note that these examples are far from a complete list:

Information about the delivery path in the mail header, i.e. Received header. These might be used to extract the sender IP address and check against blacklists.  Also DKIM-Signature and Received-SPF headers, typical spam subjects or similar.
Type and structure of attachments, i.e. a ZIP file with a *.js file inside is typically malware. A HTML attachment with Javascript is often phishing. Office documented embedded in PDF is usually malware too etc.
The content of attachments checked by an Antivirus, i.e. check for macros in word documents or similar.
Links included in the mail which refer to phishing sites.
Comparison with previously classified mails, i.e. similarity to known spam, phishing or malware.
...

Note that most of these are just heuristics. This means that even if some features are very typical for spam or phishing they might sometimes happen in innocent mails too. Thus there is always a chance that a detection is actually a false positive, i.e. something innocent detected as bad. Similar there is always the chance that something bad is not detected and considered innocent (false negative).


Is using Skype safe on a computer with sensitive information? Does Skype client in some way harm the privacy of information not submitted over it? For example, by capturing the contents of the screen, scanning the disk, the memory of the system and submitting this information anywhere. Is it safe to use Skype on government or corporate computers for unrelated activities?

Skype is definitely not a safe client to use. A Google search of "Skype exploit" will reveal a lot of its problems in regards to exploits and various news articles provide information on how the NSA uses Skype as part of its Prism program (e.g. http://arstechnica.com/tech-policy/2014/12/newly-published-nsa-documents-show-agency-could-grab-all-skype-traffic/). Note: Although the news articles do not indicate that Skype is being used as spyware targeted at the device(s) itself, this may still be a possibility so it's best to stay away from Skype.

The good news is there are safer alternatives and one example is Tox (https://tox.chat/). Also, Open Whisper Systems (a company recommended by Edward Snowden) has apps focussed on privacy/security (https://whispersystems.org/) including a mobile messaging/phone app named Signal.


What are good password storage policies? The world has progressed to the point where most of us have faulty memories and dozens of passwords to remember.  What are good ways to solve this problem?

I am interested in multiple answers and ranked order of answers, such as human memory, a password book, or password key-chains.  Each of these solutions seem to have problems either with user convenience or security.  Suggestions?

The more entropy in a password, the better. Make your passwords long and complex to avoid hackers brute-strength breaking your account.
Do not use the same password on two systems; if one system is compromised, your password on that system can be used to get into your account on the other system.

These two rules mean that if you want to be secure, you need to have a different complex password for each of the systems you use. To make things worse, many of the systems you have accounts on will force you to change your password regularly.

All of the above means that unless you have a photographic memory, you need some secure place, other than your brain, to store passwords.

I recommend using a password manager. They use encryption to secure all of your passwords, and you access them by using one memorized master password that can be complex, since you only need to memorize that one password rather than remembering dozens or hundreds of different changing complex passwords.

The second best option is to print out all of your passwords on paper and store it in a secure place, like your wallet. The real threat to your system accounts is someone hacking into your computer or the system/server you have an account on, not a mugger running home after taking your wallet and hacking into your accounts. Even if you worry about the losing your wallet, you can go home, grab your backup printed password list, and then quickly change all of your passwords before someone gets into your accounts.

One method I recommend that you use to increase the security of any password storage method is to memorize a secret procedure that can modify any alphanumeric string to form your actual password.

For example, I might memorize a procedure that says "capitalize last letter, append 3, and then move first letter to end'. Then if I store my Gmail password in my wallet as 'googlepassword', the actual password I would use when logging into Gmail would be 'ooglepassworD3g'. You would apply the same secret memorized procedure to all of your stored passwords. This allows your passwords to be very complex, since you no longer need to memorize the password, you only need to memorize the secret modification procedure you use.

If you need to change your password afterward, create a new unmodified password, print it out or store it, apply your method, and then use the modified password on that system.

Using this technique, even if you store you unmodified 'passwords' in an insecure location (such as in a text file or in a wallet lost to a mugger), your real passwords will still be secure.

And finally, I believe that passwords will, at some point, go away as a remote authentication method. I have great hopes that SQRL, or some other form of remote authentication, will make passwords obsolete.


DVWA - Odd command injection behaviour (High) After completing the OS Command Injection level on High, I was delving a little deeper so I could write it up. It seems that while the solution works on the web app the same command errors on the linux terminal.

DVWA command for the High level

127.0.0.1|  |cat /etc/passwd

This works. Doesn't output the ping result but prints to screen the contents of /etc/passwd

If I use the exact same command on my linux terminal it errors. Code used to mimic the web application

ping -c 3 127.0.0.1|  |cat /etc/passwd

I receive the error

bash: syntax error near unexpected token `|'

If I remove the spaces the command works as expected. I can't explain why the shell_exec PHP command passes the command to the OS, the OS runs it and displays the result, yet the direct approach errors. Technically the DVWA command shouldn't work?

It's caused by the deliberately faulty blacklist. Pipe followed by space gets replaced with an empty string. The second pipe is immediately followed by a c and thus does not match the blacklist and hence slips through. The first pipe and space are redundant. Ip|cat should also work, as does ip%0acat and ip%26%26cat.


Why are low-entropy passwords considered OK in many cases? When talking symmetric encryption, a 56 bit key is known to be so weak. If you use it for your encryption, you are considered a goner as you wont survive brute-force.

When talking passwords however, the standard these days is about 8 characters selected from about 94 characters on the keyboard. This translates to about 94^8 possible passwords, which means about 52 bits of entropy.

Now, 52 bits is obviously less than 56 bits. But somehow a 56 bit key is considered weak while a 52 bit password is considered safe (i.e., many systems force you to use the 8 characters). Why is this so; I mean why are the standards lower when we talk passwords yet both passwords and keys are subject to the same kinds of brute-force attacks?

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter.

"Cracking" a password on a website is not subject to the same kinds of brute-force attacks as encryption keys. Unless your source is a breached database, the rate at which you can brute force is limited by the website, which can introduce source-based throttling or blocking, attempt limits, raise flags etc. which makes a simple brute force harder to do.

However, if hashes have been leaked and there is insignificant additional entropy, then 8 character passwords are not secure, as @Lie Ryan suggests.


Search engine forensics? I read an article that th3j35t3r (hacker alias) had written awhile ago and could not find it again to reference so I will do my best to explain correctly. An anonymous individual tried to dox  th3j35t3r. Th3j35t3r replied with a post to his website wherein he unmasked the Anon and explained that he did so by performing forensics on "Google search." He saw that a majority of the queries to Google for "th3j35t3r" came from a single IP address, did his due diligence and identified the person. My question is: how did he do that or what are ways to do that?

TLDR: If I had a term or phrase, what techniques could be used to get info on its queries on search engines like Google?

What you are referring to what I call a heuristic investigation where the investigator tracks a particular behaviour and tries to tie that to an individual. This technique is used in many fields not just cyber-forensics.

The method your article most likely proposed was somehow obtaining a list of the keyword th3j35t3r correlated with IP addresses that searched for that keyword. I am not aware of any such list publicly available but through legal means, can be obtained by subpena and/or warrants or potentially can be breached by a hacker.

A notable example of what you are looking for is the AOL search log leak where

You can find trends in searches publicly but these are rather anonymous. Some ways to capture specifics would be to setup honeypots such as creating special ads that only target a specific search term (in this case "th3j35t3r"). note: this works well with obscure search terms.


What unique device fingerprinting information can an iOS9 app collect? As a follow-on to these questions:

What unique fingerprinting information can an iOS7 app collect?

What unique device fingerprinting information can an iOS8 app collect?

Apple has apparently removed the ability to see other running processes in iOS 9, and throttled (and otherwise limited) the ability to test URL schemes. See: https://developer.apple.com/videos/wwdc/2015/?id=703

What remaining device fingerprinting privacy / security vulnerabilities still exist as of iOS 9, particularly those that have no user controls to block them?

e.g., There is still no official confirmation that "integrated" apps (like Facebook or Twitter) are subject to the above limitations. Both Facebook and Twitter claim that their apps are able to access an app list to use to target ads. Twitter's privacy policy hasn't been updated to state that app graph is unavailable in iOS 9. Also note that this capability is often discussed as "installed and not simply running apps"; see link in this comment for example: What unique device fingerprinting information can an iOS8 app collect?

e.g., There have been apps in the app store that show system information like uptime, battery level, disk size and usage, memory size and usage. These could easily be used as elements of a fingerprinting algorithm in a malicious app or in 3rd-party code in an app.

e.g, as always there is basic system info available similar to what any web page can access: IP address, HTTP headers, etc.

https://panopticlick.eff.org

EFF released a tool to check the uniqueness of a browser through things like canvas etc.

curiously i had never actually run this on iOS, but i just tried it on a device running default browser settings, and it found my browser settings were unique among 175000 tested. apple does not allow non-apple browsers to be based on anything other than their webkit engine. lastly, i am under the impression that all apps have full access to the webkit browser.

there is also a little bit of non-technical info here:
https://support.apple.com/en-us/HT205223


How secure is a git commit hash (sha1)? Consider the following scenario:

Someone, using a good version of git, issues a git clone followed by a git checkout of some commit hash (the 40 character hexadecimal).

To clarify, assume Bob does the following on a secure machine:

  $ git clone https://secureserver.com/HonestEve/project.git
  $ git rev-parse HEAD

which prints

5b3469eccbd7849d760f63af8537940c97c1d1bf

Bob goes over the just checked out code and verifies that it is indeed
what he wants/needs.

Then at a later date, Bob does on another secure machine (or at least, in an empty directory):

  git clone https://malicious.server.com/HonestEve/project.git

or probably he uses the same url, but somehow gets connected to a malicious git server. And then proceeds with:

  git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf

Then the question is, is it possible (ignoring any SHA1 collisions or weaknesses) that the resulting source tree is different from what he got the first time?

Here you may assume that the git client that Bob uses is the normal, most wide-spread git client that comes with most operating systems; some recent version. Considering how this git client functions, would an attacker be able to insert malicious code into this checkout? Note that we assume the following:

  1) There are no collisions possible (any SHA1 can only be gotten with the exact same input).
  2) The attacker can make the victims git client connect to their own malicious server and has full control over the server, but not over the client or the machine that the client is running on.
  3) The attacker knows the commit hash that the victim will use (far) in advance.

If I am correct then the attacker will not be able to do this when the client recalculates the sha1 locally from the original input to verify that the resulting checkout is what was expected. But that seems very inefficient. The size of sha1 is very large, but only intended to avoid accidental collisions it seems(?).

Surely a git checkout <sha1> will simply checkout whatever is listed under the given sha1 without any recalculation(?). However, perhaps the client verifies the correctness of the sha1's during cloning / fetching? If so, that would be paranoia and a clear effort to stop malicious attacks like the above. I am not sure that git does this.

Can anyone shine a light on this?

Bob goes over the just checked out code and verifies that it is indeed what he wants/needs.
Then at a later date, Bob does on another secure machine (or at least, in an empty directory):
git clone https://malicious.server.com/HonestEve/project.git

or probably he uses the same url, but somehow gets connected to a malicious git server. And then proceeds with:
git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf

Then the question is, is it possible (ignoring any SHA1 collisions or weaknesses) that the resulting source tree is different from what he got the first time?

Yes it is possible. This is not safe to do.
Mallory (the owner of malicious.server.com) can create a branch, named 5b3469eccbd7849d760f63af8537940c97c1d1bf, with arbitrary changes to the code/repository.
When Bob executes git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf, git will display a warning that the ref is ambiguous but will ultimately prefer the branch over the commit. (note if this gets run in e.g. a build script, you will likely miss the warning)
I have tested this just now on git 2.25.1 (on Ubuntu 20.04).
I have also tested pushing such a branch to GitHub - but that failed. GitHub seems to have a custom check that ensures that branches/tags cannot have a 40-hex character name:
[...]
remote: error: GH002: Sorry, branch or tag names consisting of 40 hex characters are not allowed.
remote: error: Invalid branch or tag name [...]

However, this check is specific to GitHub; and even pulling from GitHub note that you now not only need to trust git but GitHub too.
The solution to this specific attack vector is to tell git that the ref you want is a commit hash:
git checkout 5b3469eccbd7849d760f63af8537940c97c1d1bf^{commit}


How to store an AES Key? an Initialization Vector(IV)? I'm currently developing an authentication service for our company. I somehow understand how to store a salt used in hashing a password in that it should be stored together with the hashed password. That means for every account, a unique salt is also created.

What I don't get is how do you store an AES Key and IV? Should there be a unique
AES Key and IV for every account too? Or should there be 1 app wide AES Key and another app wide IV?

I've read this post but it only answers where I should store them.

You describe very little about why you are using symmetric encryption, but in general, you use the same key but a different IV for each encryption operation, provided encryption and decryption takes place on the same device.

The IV is not a secret value but it should be randomly generated using a CSPRNG.  This is very important.

It is common practice to prepend the IV to the resulting ciphertext so that it can be easily retrieved during decryption.


How do Java applet exploits work? Browsers store web pages in a local cache on the client's machine. How does a hostile Java applet exploit this information to gain more privileges than it is entitled to?

My understanding is that a Java applet can run either in sandbox mode or privileged mode. Only certified applets can run in privileged mode and uncertified ones CAN run in privileged mode but it has to request access from the user. However, this question implies it can use the browsers cache to escalate it's privileges.

The only thing I can think of is that the applet request access via the browser. The user can accept or decline this request and that approval is stored by the browser to determine privileges to the applet. If you could get at that cached data with the applet, you could alter the information and trick the browser into thinking it has been granted privileged access. Therefore allowing the applet to cause damage to the system.

Thoughts?

All the security measures you describe are from a perfect world. In real world, people make software, people make mistake, so software have bugs and some of them open breaches in this security scheme and can be exploited. This can be for instance exploits affecting the JRE, or the browser executing the applet.

You may google for tems like "Java applet exploit" to have some example of such threats which have been detected and solved in software updates.

To go a bit further, Java applet threat is often more sensible than, let's say, Javascript because Java is both a far more complex technology (the more complex, the more error and exploits) and a far more complete (offers more power over the host once exploited).


If we are behind a firewall, do we still need to patch/fix vulnerabilities? I have recently joined a security focused community in my organisation. Many of our products are deployed in the intranet (on-premise) nothing in the public cloud. So, the internal portals can be accessed within the organisation's network only.

Recently, a third party Apache library's security vulnerability (apparently, a remote code execution one) was published. Our security lead had asked us to upgrade the library to the latest fixed version immediately.

I had asked, "Since the portal is accessed only in the intranet behind a firewall, do we still need to upgrade the library?". The lead could not provide a detailed explanation due to lack of time and confirmed that the upgrade needs to happen regardless.

So, what's wrong with the statement (assumption?), "since we are behind a firewall and such vulnerabilities do not affect us".

Your statement makes two faulty assumptions:

Your firewall(s) is/are fully correctly configured and has no vulnerabilities that would allow an attacker to compromise it and that perfect state will continue.
Everyone in your organisation is trustworthy and presents no risk.

You should always operate on a defence in depth approach and secure every layer wherever you can. If an attacker does penetrate a perimeter, or you do have a rogue actor, then this Apache vulnerability could be exploited if unpatched.


Proper way to ask for parameters renegotiation with SSL Given a specific SSL/TLS connection, I would like to know what is the proper way to launch a parameter renegotiation, asked from client side.

1) Are they any requirements from the previous handshake in the parameters established?

2) What is the exact structure of the first message sent by the client asking for the renegotiation?

3) What are the next messages exchanged then by the server and the client. If they are different from an usual handshake, in what way?

Thank you in advance for your answers

Additional questions after Thomas Pornin answer :

A. Regarding the RFC 5746

I now understand a bit better how it works, however I still don't catch why renegotiating parameters are an issue when a MITM launches it, according to your link rfc5746#section-1. What interests has a MITM to ask for a renegotiation, since he won't know by any way the secrets exchanged, (in particular the pre-master secret [PMS] sent during the ClientKeyExchanged).

Once the renegotiation is done, the MITM has no way to decrypt the incoming messages sent from the client/server.

I see only 2 possibilities during the renegotiation for exchanging the PMS :

either the MITM provides his certificate to the client, so that the client encrypt the PMS with the MITM certificate. In that case, the client easily detects it, since it's not the certificate he is waiting for ;
either the MITM forwards the server certificate, but in that case the MITM won't have any way to decrypt it, and decrypt the following exchanged messages, since he won't have recovered the PMS.

So where is the security issue allowing some renegotiation by the protocol ?

B. Regarding the structure

You underlined that there was no defined and precise structure given by the RFC. How did OpenSSL team figured this out then? What structure did they choose?

See the standard:

  The client can also send a
        ClientHello in response to a HelloRequest or on its own initiative
        in order to renegotiate the security parameters in an existing
        connection.

(emphasis is mine)

So the client sends a ClientHello message when it wants to perform a new handshake. This is the very same message that the client would send when first opening the connection, with the same contents (except for the point detailed below). There is no relation with the previous handshake contents, except that the ClientHello, and subsequent messages up to (and including) the next ChangeCipherSpec, are sent within the current cryptographic context. This means that these handshake messages get encrypted and MACed with the algorithms and keys that have been negotiated during the first handshake. When the second handshake reaches the ChangeCipherSpec stage, the newly negotiated algorithms and keys replace those in force up to that point.

The slight difference in the ClientHello and ServerHello for a re-handshake is the Renegotiation Indication Extension: it is a method by which a client may (and should) indicate whether, from its point of view, the handshake is the first one or a new handshake within the context of the current one. The introduction of RFC 5746 explains the issue that RIE purports to fix. The structural issue, though, is that there is no clear definition anywhere of the security properties that a re-handshake are supposed to provide; implementers have resorted to guessing, and the attack for which RFC 5746 is a countermeasure demonstrates that such guessing, as usual, has gone wrong.

(One way to see it is that handshake security goes forward: security guarantees from a TLS handshake are transported into subsequent handshakes. RIE tries to make them go backward too: any authentication resulting from the second handshake would be deemed good enough for data exchange before that second handshake. But RFC 5746 makes no actual promise to that effect and I am not aware of any consistent, coherent and complete analysis of the issue.)


Install a vulnerable service for Windows 7 I have some kind of a project or demonstration, where I have to exploit Windows 7 to get a remote shell.

I did a vulnerability scan with nessus on my Windows 7 machine, but I didn't find any kind of vulnerability which lets me reach my goal.

So is there any vulnerable service containing a buffer over flow which I can install on my Windows 7 machine, and use it to exploit that machine remotely with metasploit.

More informations :

The machine that I am trying to exploit is mine, so everything is legal.
I am using Ubuntu 15.10 with the latest version of metasploit (I installed it from kali repositories).

On the assumption that the Windows 7 machine doesn't need to be fully patched / updated - you could look at running a vanilla (no updates applied) copy of Windows 7 with User Account Control (UAC) disabled, and exploit MS10-046.

MS10-046 is a critical vulnerability which could allow a potential attacker to gain the same level of user-rights as the local user (where most average-joes use an account with Administrator privileges). The vulnerability affects both 32-bit and 64-bit versions of Windows 7.

The exploit relates to the handling of .LNK files which has the icon resource pointing to a malicious Dynamic Link Library (DLL) file.

Without explicitly knowing whether it needs to be a buffer overflow vulnerability - I'd say this should do the trick, or similarly you could use a distribution like Metasploitable which is intentionally left vulnerable.


How do you get a secure bastion host if your IP address is constantly changing? I am setting up AWS stuff and wondering how to setup a secure bastion host. They all say to only allow access to your IP address, but how can I do that if my IP address is changing every few hours or days (just in my house wifi, or going to coffee shops, etc.). What is best practice here, for SSHing into a bastion host and limiting access somehow to only specific IP addresses. If not possible, what is the next best alternative?

In the case described above... Instead of changing the security group everytime you go somewhere I would strongly advise using the AWS VPN. The VPN allows you to connect to a static IP directly. You use a VPN to connect to the AWS enviorment securely and can allow the security group to access the ip from the VPN.


Odd characters -- including a backslash -- in magstripe track 1 name field? I've been in the Point of Sale industry for decades. Parsing card magnetic stripe track 1 data has never been difficult, but lately we've started to see some odd data in the name field of cards that customers have been swiping on our PIN pads. (It's also possible that this data isn't coming from a real magstripe, but rather from the virtual track 1 data encoded on the card's EMV chip).

Specifically, we're seeing occasional occurrences of the \ (backslash) character. I certainly know and use the / for its intended purpose. I've seen charts of the character set used for tracks 1/3. Backslash is included but it's generally got the notation "special" next to it versus "data".

I'm trying to find the purpose/use of the backslash.

I've seen exactly 2 cases so far. In both cases it appears as though the card issuer used the backslash as a substitute for a non-letter in the surname:

Case 1:

SMITH\JONES/JOHN

The \ was probably used instead of a hyphen. Not sure why they did this.

Case 2:

ST\JOHN/MARY

The \ was probably used instead of a period. Again, not sure why.

Now that Cardholder Name can be returned from an EMV tag, all bets are off! I've already seen a Cardholder Name (tag 5F20) that contained lowercase characters. Lowercase wouldn't be permitted by ISO 7813 in track 1 data; it wouldn't even be possible because of the limitations of the character set/namespace of track 1.


What should I do with the hidden/disabled Administrator account? In Windows 10, there is the Administrator account that is disabled by default. What should I do with it, with regards to hardening Windows?

I have heard of adding a password to it, but is that necessary if it is set to Disabled?

Thank you.

Considering teh concept of defense in depth, a password has to be set for all critical account irrespective of their status. So it is recommended to enable Admin to set up a strong password.

net user Administrator

Ref: http://hardenwindows10forsecurity.com/


Why no SSL certificate with multiple subdomains I know that you can't use a SSL wildcard certificate for multiple subdomains.
e.g. If I have a certificate for *.example.com I can use it for domains like test.example.com but not for test.test.example.com.

Why is that? I don't see a security reason why this was done.

If I'm the verified owner of example.com, why should connections to x.x.example.com be insecure?

Certificates for *.example.com are only valid for one subdomain level.

If you want a certificate valid for x.x.example.com you need a certificate with x.x.example.com or *.x.example.com , it's how it works.


How does consent.exe know what to display? consent.exe is responsible for showning the UAC dialog. Looking at the command line parameters with Process Explorer, I see the following:

consent.exe 1316 748 000000004385BD60

I have

read How does the Windows “Secure Desktop” mode work? here on SE
tried to convert the numbers to and from hex to see if it matches something
read the Technet article "Inside Windows Vista User Account Control" by Mark Russinovich
ran consent.exe /? (just in case - I didn't expect anything)
checked if one of the numbers occurs in the output of a !process 0 0 using LiveKD. If that command really lists all process objects, the process to be created (executable name displayed by the UAC dialog) does not exist yet.
Looking at Process Explorer's "Handle" lower pane
Finding the values in a session recorded by Process Monitor
I was unable to capture consent.exe in Rohitab's API monitor

So far, I only figured out the first number: it is the process ID (PID) of the parent process, which happens to be svchost.exe in my case.

How does consent.exe figure out from that command line information what the path of the executable to be started is?

Based on the Russinovich TechNet article you linked: Remember that applications call out to the Application Information Service (AIS) to elevate. So consent.exe doesn't need to know how to launch programs. It exists solely to establish user consent, and return the result to AIS. AIS then does the actual launching (assuming consent.exe returns success).


Password manager's hash choices (scrypt + sha256) Background information:
Master password is a stateless password manager. It (deterministically) generates a password using a hash function, depending on your master password and the site name (also some other fields, but these aren't important for this question).

So if you remember your master password and the site name (and some small details) than you can generate the password for your site's account everytime, without storing passwords (encrypted or not) somewhere on your computer (which needs backups) or in the cloud (which means you need to trust an additional third party).

It generates a password in two parts:

Part 1: scrypt_key = scrypt(password + some salts + other details).
Part 2: sha256(scrypt_key + site name + other details).

This last part is then used (pretty printed, not binary) for a site's password.

For the detailed version, see the page on the algorithm: http://masterpasswordapp.com/algorithm.html.

My actual question is then: What are the consequences of using sha rather than scrypt for the second part?
They obviously know of the existence of scrypt, so why didn't they use it for the second part as well?

The only reason that I can think of why using sha for the second part is that if an attacker finds a collision, then the found collision is probably not the one he needs (e.g. sha256("abcdef") accidentally equals sha256(scrypt_key + ...)).

Slow key-derivation functions like SCrypt, BCrypt or PBKDF2 are necessary, to protect relatively short and weak passwords, or to generate a key from such passwords (Password-Based-Key-Derivation-Function). Users need to remember their passwords, so they are typically not very strong, that's why SCrypt was choosen to hash the user password.

On the other side, hashing with a fast SHA-256 is absolutely safe for very strong "passwords". The key generated with SCrypt is such a strong password/key, so there is no reason to use SCrypt again.

Eventually it must be decided how much time can be spent to calculate the hash, lets say you are willing to spend 1 second of CPU power. It is a good decision to spend as much time as possible for the first SCrypt hash, and only few time for the second hash. Otherwise you would weaken the SCrypt hash, because you wasted time for the second hash.


If someone has a hashed password, how long till they decrypt it? Earlier my friend suggested that we have a race to see who could decrypt a hashed password first. I want to do it but I don't want it to be an all month thing. I know when passwords are hashed they can't be unhashed but if someone were to have the hash (no salt) of a password with the parameters being 6 char long and only contain lower case letters along with numbers, how long would it take for them to generate a wordlist and hash each one to see if they match?

Not too long.

If I understand you question correctly, you'll be using passwords that are 6 characters long, with only lowercase letters and numbers. So each character can only take be one of 36 possible outcomes (26 letters + 10 digits)

Effectively it's 36^6 combination which is 2.1 Billion.

Obviously it depends on the hash in question, and the hardware you're using, see here has a good comparison.

For e.g if you're using MD5, this would be cracked in under a second. Even with SHA-3 this wouldn't take more than hour. If you go wild with multiple high-end GPUs, this would be a walk in the park -- even if the password were truly random.

And I'm assuming you're brute-forcing every possible combination -- not from a wordlist. Most programs, like hashcat will allow you to bruteforce without a wordlist. Which seems apt for your use-case.


Are some privacy add-ons superfluous when using Tor browser? If running the Tor browser, should you still have the same privacy add-ons as you would if you were running a "regular" browser? Or will some of them be superfluous because of the built-in functionality in the Tor browser? For reference, a list of commonly recommended privacy tools:

uBlock
Ghostery
HTTPS Everywhere
Lightbeam
AdBlock Plus
Disconnect
Privacy Badger
NoScript
Self-destructing cookies

First of all, NoScript and HTTPS-Everywhere are included in the bundle by default (see "What is Tor browser").

Other than that, it boils down to your personal list of pros and cons. You will alter the browser's fingerprint by customizing it with add-ons which may result in your instance being more unique/trackable. This goes against recommendations and warnings to keep the bundle as default as possible to be indistinguishable from other Tor browsers on the net. This applies to actions like installing/removing add-ons, resizing the window, enabling/disabling title bar/menu bar etc.

The best way to stay anonymous is most likely to use Tor via Tails which will - by design - take care of things like cookies, and leave everything to default. Just make sure that JavaScript is disabled. That way, most of the tracking functionalities will be disabled and you'll be near-indistinguishable from other Tor browsers.

Additionally, you may want to check out Michael Hampton's thorough and in-depth answer regarding other Tor best practices (although he recommends installing Self-Destructing Cookies).


Authentication Middleware We run a large distributed system consisting of a number (>10) of Django-based web services and web applications with a consumer base of about 10000 university students. Currently, we use a single single-sign-on system (Shibboleth) provided by our university to handle authentication. Authorization/roles are manually configured per-user at each web service. Our current architecture is shown below:

We would like to extend our system to allow logins using Google, Facebook, LinkedIn and other universities. It seems like we need a middleware that is in charge of authentication and role management. Roles are frequently created and cannot be statically defined. The middleware should also perform session management (like handling timeouts, single log-out). We picture something like the following:

What components would we need in this middleware? Our sysadmin is considering Gluu or Keycloak along with an AD service. Would either of these solutions meet our requirements? Are there any best practices or vulnerability/configuration checklists for such systems?

What it seems like you are asking about is an Identity and Access Management (IDAM) solution which offers federated authentication from non-university sources.

I've only dealt with proprietary solutions (Oracle, CA etc..) but generally IDAM solutions are made up of the following elements:
- Authentication
- Access Control
- User Management
- User repository

I cannot answer your question whether Gluu or Keycloak plus AD covers your requirements and I know nothing about them.  Defining and mapping your requirements against each solution should indicate whether they are suitable.
I would also assume that any open source solution with a rich and mature community would have plenty of guidelines regarding hardening, configurations etc...


XSS inside JavaScript string literal without single quotes? As a pentester I came across this scenario:

<script type="text/javascript">

 URL = 'http://example.com?x=input';

I am able to insert a new line with %A0, spaces and almost anything except '. The problem is that I need that ' before making a new line so the JS doesn't break.

I am able to leave it like this:

<script type="text/javascript">

 URL = 'http://example.com?x=input;
 prompt`9`
 anything';

After the input and before the ; I need to insert a ' or it won't work... Is there any workaround/bypass on this? I am able to inset / too.

That's not XSSable.

(I'm assuming in your scenario angle brackets are blacklisted too. Otherwise, you could obviously close the script tag with </script> and inject a separate script that doesn't use single quotes.)

In JS/ES syntax, a string literal that starts with a single quote needs to be ended with a single quote. Since you can't inject one yourself, you may at most cause a syntax error by introducing unescaped line breaks or escaping the closing single quote with a \. An attacker could use that to prevent execution of the current script which may eventually be chained with other bugs to something more severe. But it's not XSS-exploitable by itself.


Cryptographic Hash function How can I implement a cryptographic hash function using the block cipher? I was wondering whether I can use AES in cipher block chaining mode to achieve this.

I would advise against implementing this yourself. If you disagree, have a look at the current existing AES implementations; many libraries are available and it's likely that these will suit your needs.

Have a look at Turning a cipher into a hashing function and Description of the AES cipher on Wikipedia if you're interested how the algorithm works.


BitLocker Password Change My team at work was recently working on encrypting some hard drives using Microsoft's BitLocker on Windows 7 hosts. The initial encryption for the 2TB drives took several hours to complete. This is all fine and dandy.

What is concerning me however, is that upon changing the password, the process was instantaneous. This doesn't make sense to me, since I assumed that BitLocker was using my provided password (or some hashed derivative) to actually perform the encryption. If that were the case, then the drive should require complete decryption followed by re-encryption (a several hour process, right?).

So how does BitLocker actually encrypt the data? Does it use some secret value hidden in the depths of the Windows code to perform the encryption? And if so, is my password merely a check to see if Windows will permit decrypting? If so, what protection am I really getting from BitLocker, since a stored encryption key is a breakable encryption key...

BitLocker uses something called surrogate keys. The data on the disk is encrypted with a random key (surrogate key), and that key is then encrypted with a second key derived from your password (header key). The encrypted surrogate key is then stored in the volume header.

When you type your password in, the system derives the header key from it, then uses that to decrypt the surrogate key, which is in turn used to decrypt the data. Changing your password just re-encrypts that volume header with a new header key, rather than the entire disk.


Why a web server HTTPS certificate can't sign its subdomain HTTPS certificates? Why having a valid certificate for "exampe.com" I can't make a "child" certificate for "subdomain.example.com"?

What insecurities will arise if browsers start allowing domain's certificates to be valid CA for subdomains?

X.509 validation is nominally disjoint from domain names. X.509 was designed in the context of The Directory, a mythical beast which can be thought of as a big, worldwide LDAP directory referencing every server on Earth and elsewhere. (Historically, it went the other way: LDAP is Lightweight Directory Access Protocol, a reduced version of the protocol which was meant to access the Directory.)

In the Directory, entities are designated by their Distinguished Name, a tree-like structure which has no relation with domain names (although some people have forced one into the other with "DC" DN components).

In true X.509, allowing a certificate owner, linked to a domain name, to act as a sub-CA for its own sub-domains is theoretically possible, but requires the use of the Name Constraints extension, which is standard, but almost universally unsupported. The idea would be to issue a certificate containing the name example.com, marked as a CA (Basic Constraints extension with cA set to TRUE), and Name Constraints extension with a "permitted subtree" of value .example.com (this should constrain ulterior certificates to sport host names, and these names may only be in subdomains of example.com). It is a neat idea, but it fails due to lack of support from browsers. So the net effect, if a CA issues such an empowered certificate to a domain, will be one of the two followings:

Client browser rejects the certificate.
Client browser accepts the certificate, but would also have accepted it even if it was not a proper subdomain.

Browser vendors are not keen on implementing this feature because it would be quite useless until commercial CA use it, and commercial CA won't use it until it is implemented by browsers. Moreover, commercial CA tend to prefer it if you buy several certificates from them instead of just one.

To sum up, this is a sad story of X.500 people not getting along well with IP/DNS people, and browsers not implementing the necessary features to get the whole thing to work. Things are unlikely to change in the near future.


Should 2FA be enabled on service accounts? See the title. I'm involved in a security audit right now, and am wondering whether 2FA should be enabled on not just human login accounts but also on service accounts (non-human accounts)? If so, how is this normally managed? Someone must still be at the other end to confirm the 2FA right? And would this be mainly a one time thing at setup or would they need to reconfirm the 2FA request periodically?

The trouble with requiring MFA on service accounts, is that it would have to be fully automated.  For instance, a time based OTP.

But as this OTP is based on a secret seed, it is effectively just another password stored in a config available to the service account.  And it therefore gives no real additional security above that of just a single factor such as a password.


What is the point of hashing passwords? Even when following strict security protocols, and what the user typed is (in this hypothetical situation) completely impossible to derive, the key that the server needs to compare to is still there. And even if that weren't the case, the server admin or someone with that ability could just access the account directly (either with rights to it or by modifying the system itself).

For example, if I ran an email service and correctly stored passwords, it obviously doesn't stop me from getting into their accounts by A. having the system up that way or B. modifying it to let it work that way.

Is the only reason for hashing to protect user's accounts on other sites in the event of a compromise?

Yes. For more analysis, see this blog post: we store hashed passwords because partial, read-only breaches happen (if only through a mislaid backup tape) and we do not want attackers to be able to immediately escalate this breach into full read-write access.

Also, passwords are private data (so many men use the name of their girlfriend as password, and their wife might not be pleased with it), so they should be protected from accidental disclosure to the eyes of sysadmins (or their interns). At least, looking at a database of hashed passwords is safe.


Restricting source code exposure Say you do not trust the data center technicians (or management) but have no other option than hosting your web application with them.

Also, say you want to keep certain files inaccessible to people who do have access to the server in an on-rack (live) and off-rack (turned-off) capacity.

Question
How effective would the following setup be in securing the source code and other sensitive files?

Method of protection:

Presume the application uses the following stack:
LEMP + Redis + Node (Websocket)

A. One time config

Disable autostart of Nginx, Redis and MySQL
Create a root directory for a RAMDISK partition:
mkdir -p /media/private
Change MySQL's data directory to /media/private/mysql

B. After each reboot

Create and mount a RAMDISK partition:
mount -t tmpfs -o size=2048M tmpfs /media/private/
Create required sub directories under /media/private
Upload MySQL data files, Nginx config file, SSL cert files, Redis config file, PHP source files, and node app files to the appropriate directory under /media/private
Start Redis server with custom config
Start MySQL server
Start Nginx with custom config

I think you're going about this backwards; you're outlining a solution and asking if it's secure against people "with access to the server", but haven't told us what level of "secure" you're aiming for.

Let's unroll that; secure against what? Which levels of access are you trying to block, and at what point are you willing to let it go?

Secure against network admins hitting your VM's ports? You probably had that already.
Secure against sysadmins who can access your VM's disk image? This may help, though there may be more off-the-shelf solutions, like providing a full-disk-encryption password at boot.
Secure against sysadmins who can get ssh keys to your VM? This probably doesn't help.
Secure against sysadmins who can take direct memory dumps of your running VM? This probably doesn't help, though you may look into memory encryption.
Secure against datacentre employees who can rip the RAM sticks out of the machine and dunk them in liquid nitrogen in a cold boot attack? This probably doesn't help, though you may look into memory encryption.

So I suggest you go about this the other way: define the level of security you want, and then design a solution that attains it.

[sorry for a giving a non-answer, but I feel like this needs a frame-challenge]


Router Receiving Unknown Packets from the Same IP and Port Even After Address Rotations - How? One of our client's routers is receiving packets from the same source IP address and port repeatedly, even when the router is rebooted and obtains a fresh dynamically assigned IP address, and while no other traffic or connections have yet been made. The router is configured to silently drop all unauthorized inbound packets and does not respond to unauthorized inbound packets (black hole, and no half-acks).

The IP in question is 45.227.254.22, registered in Belize. The source port is always the same (TCP 52383), yet the destination port it attempts to connect with can vary, and can start at TCP 20000 and go up from there.

Out of the thousands of random pings, scans, and pokes the router receives on a daily basis from across the internet, this is the only address that repeatedly and persistently appears in logs, and continues attempts to connect even when the client's router itself is rebooted and has a freshly assigned previously unknown IP from the ISP, and no other outbound or inbound connections have yet been made.

It would appear that what ever is at that IP address is following the router.

Sample From Log:

The client's IP has been anonymized below as 00.00.00.00 to protect privacy. The client router is located in North America (YYZ).

20:45:31.495556 IP 45.227.254.22:52383 > 00.00.00.00:48801: Flags [S], seq 1102121663, win 1024, length 0

20:45:42.621963 IP 45.227.254.22:52383 > 00.00.00.00:31373: Flags [S], seq 3756604334, win 1024, length 0

Questions:

What could be causing this?
How does it always find the client's router?

FAQ:

(This FAQ will be updated as needed)

Q. Who is managing and operating the router, the client or the ISP?

A. The router is fully managed and operated by the client.

NOTE: The answer provided below by @samy-kamkar is not considered the correct answer as typical scanning bot behaviors are well known and were ruled out early on. The IP was studied on the AbuseIP database and other places prior to this posting as well. It is certainly a suspicious IP. However, it having been reported already by others does not conclude that it is only a simple scanning bot.

The suspicious IP is noted to have a range of malicious behaviors, including scanning, brute forcing, and outright hacking attempts.

The client's router is hammered with scans, pings, prods, pokes, and even martian packets, 24 hours a day, 7 days a week, and that is considered normal for anything connected to the public internet. This particular situation does not point to any normal bot. Out of the many thousands of unknown inbound connection attempts, this is the only persistent suspicious IP address out of all others that rapidly and repeatedly appears across a large range of dynamically assigned IP addresses.

The client IP potentials it is targeting with our client are massively large, in the order of tens of thousands of possibilities because of the diverse network blocks assigned to customers by the ISP.

As an example, one connection could be assigned from a range of 10.11.0.0-10.11.255.255, another re-connect could assign from a range of 20.30.0.0-20.30.255.255, and yet another re-connect could assign from a range of 40.50.0.0-40.50.255.255, and so on, and there are dozens of such possible ranges. The suspicious connection also attempts a range of destination ports, but always from the same source port. This behavior is also different from other scans hammering the client's router.

When the client router does connect to the internet with a fresh dynamically assigned address from any random vast range, the suspicious IP begins it's attempts within 30 seconds or less. That is not normal.

How much of the public IP is changing upon the DHCP renew? How quickly before you see the packets upon getting a new IP?

This is unlikely a targeted attack and more likely a shotgun-approach scanner bound to scanning a large subnet. It only takes a few minutes to scan an entire class B with SYNs.

The IP in question has been reported by several as an abusive IP already:
https://www.abuseipdb.com/check/45.227.254.22


Under which conditions can dllhost.exe spawn child process? | MITRE ATT&CK T1191 I was looking for conditions/circumstances under which Dllhost.exe can spawn a child process. I examined a huge quantity of event logs from various Windows system and didn't come across any event in which Dllhost.exe spawns a child process.

The only noticeable event(eventid:4688) was dllhost.exe --> cmd.exe which was a result of a simulated 'cmstp UAC Bypass' attack.

Scenario:

Threat hunting for MITRE ATT&CK T1191.
Initial IOC being dllhost.exe spawning child process(attacker
payload/elevated shell).

I am planning not to look for specific dllhost.exe-->cmd.exe events as they limit the scope of rule.

The insight I am looking for is: If we create a detection rule for T1191 which triggers when dllhost.exe spawns a child process what is going to be the success rate and how many false positives could arise from this particular rule.

PS: Looking for events where cmstp.exe is spawned and examining the commandline for certain execution flags might seem like a better approach but that will not tell us about the final elevated program that has been launched.

PS: Looking for events where cmstp.exe is spawned and examining the
  commandline for certain execution flags might seem like a better
  approach but that will not tell us about the final elevated program
  that has been launched.

It depends on the data/visibility you have. If you have visibility to see a process's parent's command line, then one way to detect the behavior is to alert on any process whose parent has the GUID(s) associated with UAC bypass.

As far as the question of how often does dllhost.exe spawn a child process - it is fairly common. So - if you do not have visibility into parent command lines - perhaps the scope could be narrowed to command interpreters, scripting engines, and executables from "non-standard" paths, all whose parent is dllhost.exe.


Can controlling the content of a CSS url property possibly be exploited in any major way? So I noticed on a site I'm penetration testing that when you save your profile settings after changing them, one of the parameters in the POST request is avatar_url.

I realized that I could repeat the POST request and change this avatar_url to something like http://example.com/malicious.html and it put it in the code like this:

I also changed it to javascript:alert(1) and it again put it in the code like this:

It does indeed change the URL to this in the code, but it doesn't actually display that for the image. It seems to have some filter against displaying it. For the avatar image, it'll just show the first letter of your username.

Is there a way that this behavior could be exploited for RCE or XSS or some kind of code execution? It seems like a bad idea to accept any URL including ones with malicious files for the avatar URL but I guess it isn't if it doesn't parse it.

Possibly.  The response contains an URL inside CSS inside HTML.  All three have different escaping regimes, and if the application's developer did not do escaping for one of these right, you might be able to sneak in an XSS one level beneath it.  For example, what happens if the avatar URI ends in .../innocent.png')"><script src="malicious.js"></script> ?

You should also check for possible known vulnerabilities in the image rendering subsystem of your target browser.  You're probably aware that serious issues have been discovered and fixed in JPEG, PNG, and GIF renderers of various browsers, but it is less known that many browsers also support using more exotic image formats such as SVG and TIFF for backgrounds.  TIFF, in particular, is a highly extensible container format, with a rather broad potential attack surface.


Why the Windows Firewall has so many exception rules by default? Consider the default firewall configuration for Windows 10 Pro (Creators Update).

So, in a nutshell:

Block inbound connections.
Allow oubound connections.
223 inbound exception rules (some of which are disabled).
148 outbound exception rules (some of which are disabled).

INBOUND EXCEPTIONS

Why allow so many exceptions inbound? That sounds like a blatant security vulnerability and defeats the point of having a firewall in the first place.

Sure, you can remove these, but most users won't.

Sure, the router NAT/firewall will block these, but then why have a Windows Firewall at all if you need to rely on another firewall?

Also, the vast majority of apps don't require to listen to inbound connections anyway.

OUTBOUND EXCEPTIONS

Why add outbound exceptions at all? The default behavior is to just allow everything outbound anyway, so all the exceptions don't do anything. It's confusing and redundant.

SOME THOUGHTS

I wonder if these are just poor design decisions from Microsoft, or if there are actually good reasons behind all this.

I would say main reasoning for this "common application ports being open" issue you are addressing is to avoid a "boy who cried wolf" situation in the future.

If a large majority of Windows connections (and common third party connections like connections made by web browsers) had to be explicitly defined as OK in the firewall rules, your average user would click accept on any request to add a new rule to the system, as legitimate requests from common services are blocked by inbound/outbound rules. Now, whenever there's suspicious traffic travelling through the firewall, your user disregards the concerning message, as it happened with every other legitimate packet.