Does Nmap use only one of the DNS servers specified in the --dns-server flag per host? When I'm scanning with Nmap, I make an effort to get proper hostnames associated with the target IPs. To do this, I scan UDP 53 on the targets to identify DNS servers and then run something like the following for each identified DNS server:
nmap -sL -v4 --dns-servers DNSSERVER TARGETS

I have to review the results for each tested DNS server to see how many of the targets it can resolve, and also determine if the resolved targets differ.
The docs seem to imply that if you specify multiple servers in the --dns-servers flag, that it will choose one at random (or round robin). This interpretation comes from the "is often faster" part.
The problem I have is that my scan targets may not all be supported by the same DNS server. In my case, I'd rather specify all identified DNS servers in --dns-servers and have it fail over until it finds one that returns a response. If only one of the specified servers is used, to get accurate results I would need to perform multiple scans, each with a single DNS server specified.
My question is, is it true that the --dns-server flag will use only one of the specified DNS servers, and not try them all?

From simple experimentation, I can tell you:

If you give it two addresses, and one isn't a DNS server, it gets full responses from the other server (but has to wait for a timeout).
If you give it two addresses of viable DNS servers, it gets about half from each.
When one DNS server reports NXDOMAIN (i.e. no records), it does not try the other one.

The raw data: I used your scan for 256 hosts.  I captured, with tcpdump, at a router, packets for one of the DNS server.  It reported:
237 packets captured
257 packets received by filter
19 packets dropped by kernel

which would be 128 requests and 128 replies.  (I'm not sure why the "received" is +1).
So half the queries went here when the other DNS server, and no requeries where performed when the first server reported no name.
For the record (a debian build on a Raspberry PI):
$ nmap --version
Nmap version 7.80 ( https://nmap.org )
Platform: arm-unknown-linux-gnueabihf
Compiled with: liblua-5.3.3 openssl-1.1.1g libssh2-1.8.0 libz-1.2.11 libpcre-8.39 libpcap-1.9.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select


Does hiding version numbers increase my security? I’m currently trying to improve the security at our work. This sounds very broad, but, for example, I’m penetrating our systems and checking whether servers are vulnerable to certain exploits.

As an example, SMTP gave me this telnet result:

220 [redacted] Microsoft ESMTP MAIL Service, Version: 7.5.7601.17514 ready at Mon, 10 Mar 2014 14:15:30 +0100

After a few hours of searching for a solution, I’ve found a way to hide the details about this server, resulting in this result:

220 [redacted] Ouch, sorry.. 404 - version not found.. Mon, 10 Mar 2014 14:15:57 +0100

This seems a lot more secure, as it does not display the version number any more. My question is, did this increase the security of my server? Or doesn’t it actually make much of a difference and should I ignore version numbers as a security vulnerability?

Is there a security benefit in hiding the IIS version number?

If that's your only security measure, this is what is known as security by obscurity.

Security by obscurity is bad if it is the only thing you rely on. Your first priority should always be ensuring that the software isn't exploitable in the first place. This means patching frequently. That said, there isn't any point in shouting out the exact version of the software you are using. If hiding the version numbers make an attackers life harder, by all means do it. Just make sure you don't get a false sense of security and that it isn't the only thing you do.


Simple way to secure a webservice used by mobile clients I am currently working on a RESTful webservice with Java that is used by mobile devices, namely Android and iOS, using a framework that allows me to abstract from both. I'm adding this information because it means that I am slightly limited when it comes to the use of frameworks that might help with security.

What I am currently doing is the following:

The client has the password stored in plaintext in an app-internal file. That's because I need to send the username+password with each request --> RESTful. It is transmitted via the HTTP authorization header as username:password Base64 encoded. The transmission is done via HTTPS. The server decodes username+password and computes a hash from the password which he then checks with a hash for that user in the database. I have taken the hashing algorithm and code from here and here.

My assumptions:

If I assume that the client itself has not been compromised, this should be secure.
If someone gains access to the server's database, the users should still be safe because the passwords are hashed.
I can transmit the passwords to the server in plaintext (Base64), because the transmission itself is secured via HTTPS.

I'm only working on this project in my spare time, which means I don't want to spend too much time on security alone and since it's just a game, hijacking an account wouldn't be that critical as well. However, I would still like to have a robust authentication mechanism.

My questions:

Are my assumptions correct?
How would it be possible to compromise my current approach?
What could I do to further improve security?

One way to attack this would be with a replay attack. If I get hold of the message I can re-send it and the server would think that I'm an authenticated user and will grant me access.

This can be solved with server sending a challenge(e.g. one-time token). The challenge needs to be included in some way together with the username and password. Important is that this challenge/token needs to random for the guy with malicious intent to not be able to guess it. An even more simpler solution could be to add the timestamp and have an interval in which the timestamp included in the reply must be within.


Concepts of a secure note sharing system I am trying to design a system that will allow for staff members in our small company to securely share sensitive customer information (text) and see them on a web page alongside less sensitive communications. I intend to use PHP because that's what I know best.

The main challenge is that the data needs to be stored on the server but it needs to be very time consuming to make useful if the server gets compromised.

My idea is as follows:

When a staff user is created, they choose a secure password and this is hashed using bcrypt(12) and stored in our database. The plain password is also used to create a 4096 bit RSA key pair using OpenSSL. Both keys are stored on the server.
When a secure note is created, it is encrypted with the public key of every staff member and each copy is stored in the database.
When a staff member logs in, their plain password is checked against the hash to see if they match. If they do, the plain password, client IP and user ID are serialised and symmetrically encrypted using mcrypt. The key used to encrypt the string is stored on the server's file system. The cypertext is then sent as a cookie to the client.
When a staff member accesses another page, the server decrypts the cookie and uses the plain password and the user's private key to decrypt any sensitive information in that request and sends the sensitive information to the user's browser.

The whole thing will be over HTTPS with secure ciphers.

I'm aware that this is probably very hard to make completely secure but I would like to know if anyone can spot any obvious flaws in this setup that can reasonably be improved. Generally, it would also be helpful to know how useful is a private key is without the associated secure password.

Your system is flawed in the first two steps because you're storing the keys with the encrypted data on the same system. If an attacker compromises the server they can just go find the keys and use the keys to decrypt the secret notes. It's difficult to accomplish what you want to do without the users all storing a private key for encryption on their device.

Because I can't comment on your original question some more information would be useful to make a strong recommendation. Do you need users to be able to access this system for any device? Is the system Internet facing? Roughly how many users will the system support?


Localhost loopback risk By default, access to [::1] and localhost are disallowed in Microsoft Edge. One way to workaround this is to enable it in the about:flags page:

On that label it also says (this might put your device at risk).

What risks am I exposing myself to by allowing localhost loopback?

I'm thinking that XSS wouldn't be a risk due to Same Origin Policy (unless I'm XSS-ing a site running on my own local web server, but in that case the attacker already has local control of my device).

One risk that can occur here is Cross-Site Request Forgery (CSRF).  Say you have an application running on your localhost which presents a web server for administration purposes.  If you allow localhost in a browser, when visiting a site controlled by the attacker, the attacker could request a URL such as

http://localhost/admin/do_some_action?delete=yes

which if valid for the site listening on that host could cause an inadvertent action to be taken.

Now this of course requires a vulnerable service to be listening on that port, so not everyone would be at risk here.  However what Microsoft have likely done is look at the trade-offs of allowing or disallowing this access and decided that for the majority use case there's more risk than benefit, so they've set this default, whilst providing a work-around if needed.


How does this NoSQL injection work? Could someone explain what this is doing and how it works? I already know about SQL injection but the NoSQL is confusing.

This is a lecture slide from my professor but he provides very little context.

In Mongo JSON objects (I will call here them this way, in fact they are a restricted subset of JS objects and correspond more to python dicts. Also note that in Mongo Wire Protocol BSON is used, which is a binary superset of JSON, though not very efficient) are used as a part of query language. In PHP there exists a type array which maps to both JSON objects and arrays. So when you are populating a PHP array with values iteratively, unless special care is taken you can never be sure if it will result into JSON array or an object. In MongoDB JSON objects are used to specify conditions.

It is also often assummed by some webmasters that it is not possible to pass arrays via request parameters in PHP.

In your example an imagionary webmaster assummed that that arrays cannot be passed via request params, so there were no sanitization, the type was not checked. An adversary has managed to pass a PHP array, which has been serialized into a JSON object.. I don't know whether "<some name>":{ $eq: <some value> } is more secure than "<some name>": <some value>, the docs says they are the same, but IDK if they are really the same.

So before processing untrusted data withncore of your system you should always verify and sanitize them.


Stop Nmap scan and preserve XML output Every time I run Nmap I use the -oA flag. The XML output is an important output item as I feed it into a number of parsers plus Metasploit with db_import. The --resume option can resume a scan but it is not compatible with XML output.

It happens to me very often that a scan will be 99.XX% complete within a reasonable amount of time and then take twice as long to finish that last percent.

Is there a way to have nmap finish the scan and complete the XML output process early? I would like to avoid having to rescan or manually complete the xml file by hand/custom script.

I've tried bringing down the eth0 interface thinking that would make Nmap crash/quit the scan, however that doesn't seem to help at all.

Note: I know that there are flags I can add at the beginning of the scan to lower the timeout and prevent this problem. But this question is more focused on having already started the scan without those flags.

Nmap dev here: Sorry, but there is not an option to cleanly stop a scan and finalize the XML output. The --resume option, as you noted, only works with Normal and Grepable output. It also cannot cope with --randomize-hosts. Here are the stages of development we would need to undertake to make this possible:

Extend --resume to parse Nmap's XML output for last completed host. Not too difficult.
Change Nmap's XML output stream to clobber the final tags of a well-formed XML file if --append-output or --resume are started. Tricky, but doable.
Extend Nmap's signal handlers to finalize XML output if any. Difficult because the SIGINT and SIGSTOP signal handlers should be as small as possible and cannot rely on file handles being in a usable state. Maybe make this part of a different signal handler like SIGUSR1 or something and/or bind that to a ctrl key sequence. Also remember that Nmap must work the same on Windows, Linux, OS X, FreeBSD, Solaris, and many other platforms, so signal handling might look very different in those cases.

Feel free to add a feature request to http://issues.nmap.org/new for this, and please reference this question and answer.
UPDATE: Resuming was added in Nmap 7.40 (but not finalizing (closing open XML tags) with an interrupt signal or similar):

Added scan resume from Nmap's XML output. Now you can --resume a canceled scan from all 3 major output formats


How to safely reinstall Windows in Thailand - avoiding BadUSB/SSD I have newly bought HP Pavilion laptop, which i am planning to nuke and reinstall.

I really do not like the bloatware as it might posses a security risk.

However, in Thailand, i do not trust the sellers of USB sticks and external hard drives, i do not want to infect my laptop with that. (BadUSB etc.)

What can i do? Is there any safe way to do that? How to spot BadUSB/infected external hard drive?

First of all, there are plenty of tutorials on how to factory reset any massive storage device. For example, you can delete all it’s partitions and start a new full NTFS drive; it should be enough.

The danger is that you can’t reset the USB before it infects the computer where you mounted the drive, right? So we would need something like a sandbox or a discardable place to clean the USB.

_

Option 1

Running the USB in a coffee shop where you can pay for some minutes of computer usage. If something happens there, you shouldn’t worry.

Option 2

Mounting the drive on a discardable operative system. Whatever happens to the OS (I would suggest a Linux because it is easy to install and discard), you later delete it.

COMMENT: I’m not taking into account those tryhard USB devices which contain viruses by default or shall affect your BIOS or anything weird. Just a regular USB stick to which a virus has been set into the default storage.
Hope it helps!


Enabling feature to log in as soon as right password is typed (without pressing enter) My phone has an option for the PIN lock screen to unlock it as soon as the correct number is entered (without pressing enter). So for example if the password is 77912 then you only have to enter 77912 and not press ↵

What impact does this have on security? Still there is an infinite pool of passwords an attacker has to choose from. Is it much less secure and what is the minimum length of PIN should be? I'm concerned now that I'm starting to use my phone for banking.

Another nifty feature I enabled is to scramble the keypad layout so an attacker can't try to guess based on finger print smudges.

UPDATE: pin must be between 4 and 16 digits (inclusive)

What impact does this have on security?

Your passwords are at worst 89% of the strength they would be if you had to press enter first. Here's how I calculated it. Suppose your password can be either 1-3 digits long, and also suppose an attacker does not know the length of your password. There are 1000 total combinations (0-999). Suppose your password is 7. 111 out of 1000 passwords will pass that test. (One single digit + 10 2 digits + 100 3 digits.) In the worst case that's (1-0.111) = 89% as strong as forcing someone to press enter. If your password is 71, 11 out of 1000 will pass it (99% as strong), and if your password is 711, 1 out of 1000 will pass it (100% as strong). The more digits you add, the further away from 89% you get, and the closer to 100% you get. So, effectively, we could say the security impact of this feature is minimal. The time saved by you in the long run of not having to press enter is probably worth it.

Is it much less secure and what is the minimum length of PIN should be?

If you choose a pin length of one more than you would normally choose, you are almost at the same level of security.

I'm concerned now that I'm starting to use my phone for banking.

I'm not sure how this is relevant. You should still be using a different password for banking. If you handed your unlocked phone to an attacker, your banking information should still be safe. If that's not true, perhaps because you have passwords remembered by banking sites or apps, then you may want to consider changing that. You cannot guarantee that your phone will be locked when an attacker takes it. (Like if someone running down the street rips it out of your hand.)


How secure is VirtualBox for privacy/anonymity? Is it possible that Oracle places backdoors in VirtualBox that compromise a user's privacy/anonymity? For example, is running Whonix through VirtualBox a secure set up if your host OS is unencrypted? How likely is it that Oracle can break out of the VM and "silently" gain root access to the underlying OS? What precautions can be taken to minimize these threats? Are there any viable alternatives?

I just put some opinions from this link:

If they wanted to include backdoors in VirtualBox, they would've closed the source a long time ago. Why would they spend time implementing a backdoor in open-source software that, if ever detected, would pretty much lead to everyone abandoning the software en masse? Leaving it open allows potentially thousands of individuals to comb through different areas of the source as they look for bugs and compile it on their own. There are too many eyes on it for me to buy into the notion of backdoors being likely. Yes, it's still possible. Anything is possible if you want to speak in technicalities.

You can download the source, review it, and compile it yourself.

Generally, yes, a backdoor is possible in any kind of software.

Yes it is possible but if the guest OS is installed in a TC container they need a backdoor also in TC before they are able to have access to the guest OS, and atm i dont think TC has backdoors, even if in these weeks some users are investigating about that.

and also this Virtualbox Programming Guide and Reference

that says: – there are no hidden backdoors into the virtualization engine for our own frontends.

but I think nobody can prove his/her opinion.(the answers are opinion-based not expert-based)


Issues with html code I am just wondering if this HTML code is vulnerable/unsecure at all and if so, why?. Thank you. I am only beginning to learn about HTML so that is the reason for the question.

<form method="post" action="Login_Account.php">
<input type="text" name="username">
<input type="password" name="password">
</form>

This code is a standard form, there is not much secure or insecure about it.

Some enterprise policies will require it to include a flag to stop browsers from auto completing, but if you do not need that it is better to leave it off.

There seems to be no anti-CSRF token in this form, this seems to be a problem. Other than that make sure it is hosted on https and the server side handling the input is secure.

You might also want to add some headers against frame inclusion and set a content security policy to turn off or limit scripting.


How secure are "mobile authenticators" versus traditional key fobs? Two-factor authentication, password + device, seems to be increasingly mainstream among consumers with products like Activision Blizzard's Battle.NET authenticators.  However, I am curious what the difference in level-of-security between a stand-alone key fob and mobile phone.

Given the connectivity of a mobile phone, it seems vastly more vulnerable than a device with a button and display which would need to be disassembled to gain access (but even with direct hardware access, is the key protected?)  Given that both add some additional security and the pool of people who opt not to use it is still large (if not the majority), this is probably a non-issue in the Battle.NET case, but generally, how do they compare?

Relative to the idea of multi-factor authentication, any additional factor beyond something you know adds an additional level of complexity for someone to gain unauthorized access to an account.  The second factor that many organizations use is something you have be it a fob of sorts (event or time based OTP), smartcard (HSM), phone (SMS, call), or an application (in the case of "soft" tokens (either an app that's installed on the phone or computer)).

Key fobs have become popularized but the security industry has seen that exploitation is possible (do a search on RSA and you'll see why).  Key fobs can be broken if someone breaks the system.  Instead of disassembling each token out there, an attacker broke into RSA and gained access (though I don't recall if this was "proven" or not) to the secret sauce that makes each token unique.  Similarly, smartcards and USB tokens can be broken if the adversary successfully attacks a higher level in the tech stack or process to ensure each smartcard is unique.  Mobile authenticators can be broken (same way as with RSA or via other means), but the idea hasn't ever been to block 100% of the attacks, which is cost prohibitive for most organizations.  The goal is to implement preventative (where possible) and detective technologies such that unauthorized access attempts are blocked or identified where successful.  To that end, mobile and hardware fobs still add value.

Perhaps to your point, mobile authenticators likely provide sufficient protection for Battle.NET users.  Fundamentally, they're protecting against users stealing money or gaining access to someone else's account.  In the event someone is really interested in breaking the system, hardware or mobile authenticators (or even biometric) layered in third and fourth factors may not be sufficient.  So from a cost perspective, mobile authenticators are cheaper to deploy, simpler for users to use, and provide an additional layer of protection.  Hardware authenticators are more costly for both the user and game provider to implement and maintain.

To sum it up, mobile is good enough for the use case.


Recreating the Half Coins of Jin-Qua In the Asian Saga series by James Clavell, the Struan family gave away the half-coins of Jin-qua: in exchange for a desperately needed loan, the pirate Dirk Struan received 4 halves of 4 coins.  The Chinese merchant, Jin-qua, kept the remaining halves. The repayment of the loan came in the form of an oath: Dirk Struan and his descendants would grant a boon to whoever presented one of the four halves, with no limits and no conditions. Those who wish to become head of the Noble House, the family’s powerful trading business, must swear to uphold this promise.  When fulfilling the bargain the Struan descendant gets out his original coin and checks it against the one presented to him.  He keeps the coin in exchange for the favor.

How would someone make a bargain like this nowadays? The system with the original half coins could be easily broken using a modified key copier.  Admittedly only four times (at most, perhaps less if they get suspicious), but for carte blanche you only need one.

The key:

Cannot be copy-able (see below).
Must be a physical object, though it may contain digital parts.
Can be anything up to briefcase-sized.
Must survive at least 5 years at room temperature and preferably 10
Must survive rough handling to the level of an airport carry-on (but does not necessarily have to be shippable or legal to take on planes).  For example, laptops meet this criteria but very thin china does not.
Must be verifiable with a high degree of confidence.  The only limit on verification procedure is that it should not take more than a week and preferably much less than that.

Let’s say the threat model is that faced by the Noble House: well-funded private companies and individuals, but not the CIA or magical assassins.

It sounds like the only attack you're worried about is that someone might counterfeit one of the IOUs. Therefore, I need to pick something for my IOUs that is hard to counterfeit. This suggests that money is still a good model.

I could just say "I'll hire an engraver to engrave some very detailed and intricate plates, mint four certificates from those plates, and use those certificates." That's what actual nation-states do, when they want to create tokens that are exchangeable for goods and services — excuse me, "favors." Such tokens are non-counterfeitable because hiring an engraver is expensive — like, state-level expensive — and we're not worried about that level of adversary.

However, hiring an engraver would also be very expensive for me. That's not good. Is there some way for me to piggyback on someone else's expensive engraver?

Here's what I'd do. I go into my wallet and pull out four 20-dollar bills. (100s if you've got 'em. Fives are probably okay. Probably don't use singles.) I write down the serial numbers on a single piece of paper. I give this paper to my descendants. I give the 20-dollar bills to my creditors. I tell my descendants, "If anyone ever presents you with a 20-dollar bill with one of these serial numbers on it, you do what they say, okay?"

If my descendants are really paranoid, they take the presented 20-dollar bill to the bank and have a teller look at it, before they do what the guy says.

In fact, if I and/or my creditors are smart, we'll take the bills to the bank and have them examined (after I write down the serial numbers, but before I hand them out).

The above scheme is foolproof for as long as

20-dollar bills are legal tender, and
your descendants have access to a bank that accepts U.S. currency (which admittedly might be tricky if you are a family of pirates).

The Fed estimates that in circulation, any U.S. bill will last at least 4 years; and if you treat it like the average $100 bill and keep it "as a store of value," it'll last at least 15 years.

Observe that a U.S. bill shows its serial number twice — on the left and right sides. You might be tempted to rip your $20 in half, give half to your creditor and keep half for your descendant. The problem with this idea is that two-halves-of-a-ripped-$20 are not legal tender, and so you lose your safety net: if you suspect forgery, you can no longer ask a teller, because they might just say "Nah, we don't take ripped $20s," and refuse to speculate about whether both halves were originally real or what. So, don't rip that bill!


Auditing Existing Socket Connection Is there any way to interact with a program's socket traffic without installing Winpcap?

I understand that the one listening program per port is a restriction regarding TCP/IP, but I guess I'm more asking whether or not it is still safe from code injected into the program or something similar.

I figure a situation probably calls more for intercepting traffic through MITM or something, I'm just interested in how "low-level" this port rule applies.

You can use tcpdump for TCP/IP sockets

Unix domain sockets are something else.


'Continue experiences on this device' group policy In an enterprise or office setting, should I set 'Continue experiences on this device' under the group policy to be disabled? Why should I set it to be disabled, or why shouldn't I set it to be disabled, and what are the consequences if I didn't set it?

This policy setting determines whether the Windows device is allowed to participate in cross-device experiences (continue experiences).
If you enable this policy setting, the Windows device is discoverable by other Windows devices that belong to the same user, and can participate in cross-device experiences.
If you disable this policy setting, the Windows device is not discoverable by other devices, and cannot participate in cross-device experiences.
If you do not configure this policy setting, the default behavior depends on the Windows edition. Changes to this policy take effect on reboot.

https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.GroupPolicy::EnableCDP
This is probably the description listed from the group policy editor description. Cross device experience is a network service that lets users continue where they left of on another device. It may (probably) have security problems, and it can have security implications with regards to different devices for different tasks, so it may be desirable to disable in some scenarios, whilst it may be unproblematic in other scenarios.
If you don't set it, the default value will depend on the windows edition.


defend against LOIC Hive Mind attack Other than client puzzles, what are some things a website can do to defend itself against a
LOIC Hive Mind attack?

The Low Orbit Ion Cannon (LOIC) is an attack tool which features a user-friendly GUI as well
as an option to voluntarily add yourself to a botnet controlled via an IRC channel.

Akamai and Cloudflare provide DDoS protection services which will disperse traffic using DNS load balancing, blacklist bots, and filter attacks before they reach your server(s).

LOIC produces an HTTP GET flood, this is not an advanced DoS technique but rather a simple script to carry out a trivial attack.  Any worthwhile DDoS prevention product should solve this basic attack.  Until a certain point, of course, and then no one can solve it.


Can a 0800 and 00800 be from different companies in UK I recently received a call from a 00800 number, that seemed like a prerecorded message asking me to press some keys to continue. I disconnected.

I later googled the number and I noticed that a company in UK (Thames Water) uses the same number but with 0800. When calling the 0800 version I could hear different 'automatic secretary'.

Is it possible that 00800 is controlled by a different company than the 0800 number? If so, then this is a dangerous scamming technique.

00 is the telephone prefix to dial international numbers in many countries, including the UK. The 1 to 3 digits that follow 00 are a country calling code, in this case the code is 800 which is an international toll-free number.

As far as I know, 00800 numbers are always toll-free, so this can't be a scam where you are tricked into calling an expensive number.

The 00800xxx number bears no relation with the UK number 0800xxx. So this may be a scam where you're tricked into communicating with a party you aren't expecting. For example, they might try to trick you into paying them something, pretending to be Thames Water giving you the last chance to pay your water bill before they cut you off. Or it could be a different scam copying an 800 number from a different country such as the US. Or it could be some simple spam, perhaps with an invalid caller ID. Or it could be a mistake.


New Certification: C|CISO. Where it stands? I recently found a new professional certification: C|CISO, currently in the grandfathering stage. It seems to be targeting security professionals that want to prove they are suitable for C level manager positions.

Still, there is already another such certification, CISM, by ISACA.

Is there any real difference between the two?

There are distinct differences, even just from the statements regarding them on the EC Council and ISACA websites.

To answer your headline question: where does C|CISO stand:

At the moment, nowhere, but they are aiming for a slightly higher grade than CISM. I'm not sure how well it will work though; CISM is for experienced security management and not pretending to be anything higher; C|CISO is aiming at CISO's and those planning to be CISO's soon but appears to have remarkably similar entrance criteria to the CISM.

It is an interesting change of direction for the EC Council - the C|EH is at the opposite end of the spectrum: a beginner's security testing cert - so I will be watching to see how it goes. I have asked them for more information and will be sure to discuss further once I know more.

(disclaimer - I am the President of ISACA Scotland, but not biased - I am also the Chairman of the Scottish branch of CIISec, and believe in the value of certs where appropriate)

Update - I grandfathered in to the C|CISO at the end of 2012, and it looks like my original assumption is correct. It is aimed at the wider CISO experience, not just a security manager, but brings in elements that a CISM doesn't necessarily need around wider business risk, board level decisions and strategy, and a more holistic business view.


Could "Windows Network and sharing center" constitue a security risk? "Windows Network and sharing center" allows to see ALL windows OS based devices on a network (and sometimes more).

My inquiry is how this could represent a security risk ? i.e why would a sysadmin would not configure a GPO to disabe it everywhere ?

Is it not harmful ? I'm not an expert but I suppose a malicious user could use it as a footprint tool to scan the network right ?

Devices will only show up there if they are configured to be discoverable - for Windows computers machines (7 onwards IIRC) you are asked when first joining a network whether you want to treat it as Private (the computer will be discoverable) or Public (it won't be). See here for more info:

https://www.howtogeek.com/245982/whats-the-difference-between-private-and-public-networks-in-windows/

While it has convenience value for legitimate users looking for devices and resources on the network it really doesn't offer much for a malicious user compared with more dedicated scanning tools. Turning it off to try and protect things is very much security via obscurity IMO - if you've got a discoverable machine called "SuperSecretServer" with an open share called "PlainTextCreditCardDetails" then the fact that it's discoverable is NOT your big problem!

Other devices that show up there are usually doing so because they are UPnP enabled (typically things like printers, media streamers, that kind of thing) where being easily discoverable is often something they aim for.


Why would Amazon include an already trusted Root CA in the bug report they filed to get into Mozilla's truststore? Amazon will soon be a trusted Root CA. To this end Mozilla Bug #1172401 was filed a while back to get into Mozilla's trust store.

Along with 4 of their own Root CAs they've included a fifth one (Starfield Services Root Certificate Authority - G2) to be trusted again.

Why would they include an already trusted and working Root CA in their application?

See comment #9 on that bug from Peter Bowen at Amazon:

  It also includes one additional root CA already in the Mozilla program which we wish to have enabled for EV certificate issuance.

That suggests that the root was already included in NSS, but not enabled to issue EV certificates; this is a request to change that.

Quote from comment #21:

  I am now opening the public discussion period for this request from Amazon to enable EV treatment for the currently-included “Starfield Services Root Certificate Authority - G2 certificate, and to include the following 4 new root certificates, turn on the Email and Websites trust bits for them, and enable EV treatment for all of them.


Is it cryptographically safe to use veracrypt in a virtualbox virtual machine? Does virtualbox provide enough entropy (random numbers) for the veracrypt program on the virtual machine? Is it cryptographically safe to use veracrypt inside a virtualbox in a windows 10 guest?

According to this question modern VMs have access to "the CPU instruction RDRAND" which provides high quality random data.
This suggests that yes, you can safely use VeraCrypt inside a VM. However, the significant caveat is that you must trust the host machine. If an attacker has full control over the host machine, they have full control over the VM.


Native app, token authentication without login/password I'm working on a always online mobile game (native android/iOS app with Unity) and i would like to be able to authenticate the player without requiring any login/password at the beginning. For those who know, i try to achieve a similar authentication scheme as famous Supercell games (Clash of Clans, Boom Beach, etc..)
What i have in mind:

The very first time the user launch the game, a request to the server for a new account is done, the server send back a UUID.
This UUID is stored in the device (should i crypt or hash it ?).
When the user start the game i authenticate him with a token (UUID+timestamp+hmac(sha256, username+timestamp, K)). Is it better to generate a temporary session token (stored in the database) or could i use the previous token for all the requests after authentication?
For each request i send token+params+timestamp+hmac(sha256, token+params+timestamp, K)

And every communication will be over SSL.

is it totally insecure ?

NB: In the game you will be able to do in-app purchases and in this case the first time you try to buy something you will have to bind your game with your GameCenter or Google Play or Facebook accounts. This information will be store in the database. Should i use these accounts to authenticate if it's possible?

As you can see, nothing is clear in my head and i'm definitely not a expert in security. So every little advices will be appreciated.

What is your threat model?

If every connection is sent over SSL, you do not need to worry about anyone sniffing your communications.  This is actually the strongest part of your system.  Good job choosing something standard.

Because SSL is ensuring nobody is listening in on your communications, we should look at the endpoints.  Your UUID is basically a shared secret.  Anybody with this UUID will be able to imitate your users.

As for cypting it or hashing it, no.  Do not bother.  If they have access to your encrypted UUID, they certainly have access to the source code for your game, which would have to contain the password.  Anything which could prevent an attacker from authenticating also would prevent a customer from authenticating.

You need to develop a threat model.  What would an attacker do if they got their hands on a UUID?  If all they can do is in game purchases for that account, then there is very little they can gain from having a UUID.  They could try to piss off a customer by stealing the UUID and using it to buy a whole lot of stuff the customer didn't want, but if you are able to refund that, then they can't piss off a customer much either.

On the other hand, if UUIDs can be used to purchase things that are useful for others, then you have more incentive for attackers to steal them.  If they could be useful to the mafia, then you have an even bigger threat, because they might throw one of their botnets at your system.

All security is based off of a threat model.  Nothing is perfectly secure.  As Kevin Mitnick once said, "The only completely secure computer is one which is disconnected from the internet, turned off, encased in concrete at the bottom of a silo guarded by armed guards.  Even then, I'd check on it once in a while."


SSL cert securing an on-premises web service where the domain is hosted externally We have a customer, let's call them ABC123 Ltd, who have an existing website on abc123.ie hosted by a hosting provider. It's just an informational site with no login\commerce function so currently just runs over HTTP. They will continue with this.

They now want to implement a web application that must be hosted on-premises under IIS. They will be communicating with this web application using an Android app on tablets, via an domain name and port. The traffic for this must be over HTTPS.

The customer's premises has a static external IP.

So in overview abc123.ie is a website hosted by their hosting provider.
They need to also have an on-premises web service secured by SSL.

My understanding of how this can be achieved is as follows.

Customer obtains a new subdomain from the hosting provider, say mobile.abc123.ie.
Customer generates a CSR on the on-premises server and obtains a domain-validated SSL cert from the hosting provider for mobile.abc123.ie.
Hosting provider sets things up so that traffic for mobile.abc123.ie is forwarded to the external IP of the customer's premises.
Customer's IT vendor configures on-premises firewalls for traffic on port 443 to be forwarded to the internal name or IP of the IIS server.
We create a HTTPS binding for the web service in IIS and install the cert.
Android devices hit https://mobile.abc123.ie to access the web service.

Does this sound sane?

Yes, this sounds like a normal way of doing things.

Step 3 will be via a DNS A record pointing mobile.abc123.ie to your external IP with the 443 port forward.

You could consider SSL offloading on your firewall if it is supported for increased performance and scale if that is a concern.


What is preventing us from sniffing the mobile phone communication? I'm learning wireless penetration testing. It really is amazing. But it made me wonder, what about mobile phones? They are also means of wireless communication. So, our entire voice must be in the air surrounding us. So,

What makes it difficult to intercept?
By the way, is there any standard like 802.11 for Wi-Fi, for telecommunication over mobile phones?

For telecommunications, check out GSM, CDMA, TDMA, and EDGE. The two competing protocols in the United States are GSM and CDMA. The resources linked below are lacking when it comes to CDMA, but using site:defcon.org and site:blackhat.com in your Google searches will turn up some presentations.

For interception of GSM, I refer you to a white paper Intercepting GSM traffic from the BlackHat conference:

Intercepting GSM traffic - Black Hat Briefing - Washington D.C., Feb 2008

  Abstract: This talk is about GSM security. We will explain the
  security, technology and protocols of a GSM network. We will further
  present a solution to build a GSM scanner for 900 USD. The second part
  of the talk reveals a practical solution to crack the GSM encryption
  A5/1.

The corresponding video of the presentation:

DeepSec 2007: Intercepting GSM traffic

Also a talk on cellular privacy and the Android platform:

DEFCON 19: Cellular Privacy: A Forensic Analysis of Android Network Traffic (w speaker)

and a whitepaper on the Lawful Interception for 3G and 4G Networks (though see first comment on this answer):

Lawful Interception for 3G and 4G Networks - White Paper by AQSACOM

  This document will first provide a brief description of the various
  evolutions of public  mobile networks that have been commercially
  deployed, followed by a discussion on the  evolution toward the newer
  “long term evolution” technologies.  We then discuss possible
  configurations for lawful interception of the evolving mobile
  networks, followed by descriptions of approaches to 3G / 4G
  interception solutions now available from Aqsacom.

And a SANS article on GSM security:

The GSM Standard: an overview of its security

Also note that smart phones typically just automatically connect to networks with SSIDs it remembers. Sniff the airwaves for beacons that it is sending out and set up an evil access point with a matching SSID. Launch a remote attack across the network or man in the middle the device and launch a client-side attack appropriate to the device.


Encrypt/sign a client-to-API request? We are building a JSON API on top of our Ruby on Rails Web application, using JSONAPI::Resources to expose endpoints and Doorkeeper to handle user authentication.

Most of our API endpoints will be exposed only to authenticated users, and Doorkeeper will probably do a great job at enforcing that. But we still have a couple endpoints that will not be authenticated: sign up, login, account confirmation, and maybe a couple others.

I am worried that letting those API endpoints completely open will expose us to attacks, in the form of spamming new accounts for example.

Maybe I am worrying more than necessary? Do APIs usually let this kind of endpoint unsecure, and add prevention systems like throttling?
If not, is signing (or encrypting) my requests before sending them to the API server the right approach?
And if that's so, do you have any recommendation, or preferred approach, in doing so?

I tried to Google keywords like "rails API sign request" or "rails api encrypt request", but I'm not sure the results are pertinent, or which one would be recommended.

The first clients that will talk to this API will be Android then iOS applications, and we might add in the future client-side web applications (at the moment, our web application is monolithic and does not use the API).

Signing is pointless when you don't have a public key of the signer. You can't validate the signature anyway, so an attacker who wants to spam you with new accounts could just send a bogus signature. There are more efficient measures you can take like captchas or IP-based throttling.

Encryption, on the other hand, is never a bad idea. "Sign up" and  "Log in" require exchange of sensitive information, so they should be encrypted. Also, in the age of data-mining everything can be sensitive information, including that John Smith looked at the profile of user 29252 on example.com at 2015-08-19 17:02:03. So even seemingly harmless information should be encrypted whenever feasible. Making your whole website - both API and static content - https-only or at least https-capable is never wrong.


What is the endgame of a site like this? I came across the following ad:

It's in Dutch, and the title seems to be a mix of autogenerated words to probably create as much of a clickbait title as possible.

The ad goes to the following page: https://cotqt.com/rtl-late-night-wil-scoren-met-nepnieuws-over-knappe-man.php

It is clearly some fake page and the story also seems to be autogenerated with words that attract attention.

There is no follow up advertisement
There are no clear links to other products
The shop is not even working
There is no submit button so it also doesn't seem to try to capture passwords
I don't any weird XHR requests going off

Someone is paying 10 cent - 50 cent per click for this.

Is this a phishing site? What can be the goal for this?

Without analysing the code on the site, the idea could simply be to see what types of material users will click on. The "endgame" is to create profiles of you or people like you to determine what will interest you enough to click on things.

Is this malicious? It doesn't have to be. It could be for generating commercial advertising profiles or for more nefarious purposes like political/ideological profiling for the new game of cultural influencing.

I created a phishing platform that would send a variety of different types of phishing emails to a user to see what the user would click on. It would figure out what elements of the phish would trigger the user to click. Then it would use that data to compose its own emails. This could be a similar process for ads. The fact that it seems auto-generated would support that hypothesis.


Penetration testing real-life practice I see a lot of similar question but my is different. I had done a lot of challenges like Kioptrix  and De-ice. But I'm not sure that this is real life pen testing. I mean this is so simple only nmap and metasploit (and some web app hacking). So is there something closer to real life penetration testing?

Something closer to real life requires an infrastructure with systems and networking equipment. You can virtualize that but it still requires some resources to set up and run. That's why you have to pay for most of the good labs.

BackTrack PenTesting Edition lab is an all-in-one penetration testing lab environment that includes all of the hosts, network infrastructure, tools, and targets necessary to practice penetration testing. It includes: a DMZ network with two hosts targets, an “internal” network with one host target and a pre-configured firewall.

OSCP, OSCE, SANS 660 and HackinkDOJO are some of the paid courses that have good practical labs.

CTF365 is a continuous real world Capture The Flag with free and paid services.

You can also build your own security lab.

And if you want real world pentesting, go do bug bounties and get paid for it at Bugcrowd and HackerOne.


Choosing the right X.509 certificate infrastructure for securing LAN communications between a PC and a device Edit: seems like I was quite hasty when typing in my question at first, so here is an updated version of it.

I am developing an application that runs on PCs which are on the same LAN as other devices. I want to connect to these devices. Since the data communicated between the PC and the devices is sensitive, I want to protect it with encryption, authentication and integrity. Therefore I am using TLS.

The idea is that if someone manages to get access to the LAN from outside (somehow) he should not be able to use the data sent between a PC and a device (because of encryption). Also if someone gets access to the LAN from within he should not be able to just connect to any of the devices. There is currently no real user/password protection on the devices so I need some other sort of authentication. I was thinking of certificates here. The idea is as follows:

The company which is running the LAN represents the Certificate Authority. There is a general server certificate which is stored on the devices. There is also a client certificate which is held private on the PC's that should be allowed to connect to the devices (like service notebooks, for example). The company signs both of those certificates.

Now, if someone is able to get access to the LAN, he might be able to sniff out any traffic, but it's encrypted so he cannot use the data. Moreover, if he wants to connect to any device, the connection will be refused since he is not in possession of the appropriate client certificate. However, clients can check if the devices they are connecting to are really those devices and not some intruder.

My question is: is this the right certificate infrastructure? Is this effective? Are the certificates sent via encryption or will they be sent unencrypted? If they are sent unencrypted, does this even have any use? I guess an intruder can just log the certificate sent by the client and then hold it on his own machine.

It's rather hard to give a sensible answer without knowing what you are trying to acheive.

Using self-signed certificates you'll get secure point to point communications, but there is no intrinsic authentication - I can walk into your office with a laptop using my own certificate and start connecting to your services. OTOH if you run your own certificate authority, then you have the ability to restrict communications based on the issuer of the certificate (in this case your CA). The common name is just a convention used as an assertion of identity (it doesn't have to be a fqdn) which is certified by the CA.

  However, I don't have a domain name because all of the computers and devices will get dynamical IP addresses inside the LAN

Nonsense:

1) what you don't have is an entry in the public DNS to identify your network - there's nothing to stop you calling your network anything you like - but you may experience problems connecting to the other google.com if you call your network that.

2) DHCP does not preclude using using static IP addresses for some hosts

3) DHCP does not preclude having a consistent hostname with varying IP addresses.

  I want that only users in posession of the certificate

Then why are we talking about FQDNs and IP addresses? These are properties assigned to machines not to people.

I think you've still got a long journey ahead of you before you are asking the right questions.


HTTP login to iframe HTTPS/ MiTM attack I would like to know if the credentials can be intercepted/MitM attack if the site is using HTTP to HTTPS login iframe.

Here are some login details from my Chrome dev tools (Form Data)

So I can see the credentials on my Chrome but I cant see on the Wireshark and can I capture this on Burp?

Cache-Control:private
Content-Length:141
Content-Type:text/html; charset=utf-8
Location:/mobile/account.aspx
p3p:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Server:Microsoft-IIS/7.0

FbAccessToken:
ctl00$initfvk1$AccessTokenHiddenField:
ctl00$cph1$LoginForm$UserName:hacker@hacker.com
ctl00$cph1$LoginForm$Password:password123

... if the site is using HTTP to HTTPS login iframe.

If I understand you right then you mean that the login frame is loaded via HTTP, but the results are send via HTTPS. In this case a passive MITM attack (i.e. sniffing only) can not be used to sniff the credentials because they are sent with HTTPS. But an active attack like sslstrip can still be used because it can change the target of the login form and thus make it sent the data in plain.


Can I "hide" the private key, while still allowing it to be used? Let's say you assign SSH keypairs to all users on your system; none of these "low trust" users have root privileges. You want the users to be able to use their keys in SSH connections, however, you don't want your users to be able to read their private keys.

This can be used to either prevent users from accessing secured servers over SSH from unauthorized computers (by copying their keypair to another computer), or to prevent their private keys being accidentally leaked.

Is there already this type of system in place for "hiding" private keys from the users, while still allowing them to use them during the shared key negotiation?

You are focusing on securing the keys on the client side. I would recommend that you take a look on the server side.

On the server, you can limit what they key is allowed to do and what servers it may be used from, by editing the authorized_keys file for the target account. Here's an example of a key with limits:

from="their.workstation.only.example.com" no-port-forwarding ssh-dss AAA....

You can use IP addresses instead of an FQDN if you like.

In order to prevent the users from tampering with the authorized_keys file, you can move it to a location where they do not have write permission. It will still work as long as they have read permission. This can be done by editing the sshd_config and changing

AuthorizedKeysFile .ssh/authorized_key

to e.g.

AuthorizedKeysFile /usr/local/authorized_keys/%u

The %u gets replaced by the username, so when someone connects to ssh with the username foo, ssh will look for the keyfile in /usr/local/authorized_keys/foo. As long as foo has read access to that file, the connection will work.

Edit: Instead of moving the key, you could simply set the file to immutable, like this:

sudo chattr +i /home/user/.ssh/authorized_keys

Once you've set up the source IP limitation, and you've secured the key file against tampering, it won't matter if the private key gets leaked - it still won't be usable from any other system.

There are a lot of other things you can do to limit the users when they connect with keys - see the man page for sshd. There's also been some questions about this at Serverfault, for example Limited SSH access for log retrieval.


Which Browsers support TACK? TACK is an IETF draft that allows certificate pinning for a TLS web server, provided the clients' browsers support it. Unlike the certificate pinning feature available with HSTS preloading, the server's operator is not committing to a particular certificate in the chain (and hence typically to a particular root or intermediary CA), instead retaining his own (offline) key that can be used to authorize the use of a new server TLS certificate.

Which browsers support TACK? Are there extensions to add support to browsers that do not otherwise support it?

Good Question.  TACK is a "dynamic pinning" solution to the broken Certificate Authority model we all depend on today.  A competitor is Google's Certificate Transparency (CT).

Status of TACK is

No browsers currently support it.
There are no browser extensions to enable it.
The last posting from the developers (January, 2014) is that it is entirely up to the browsers to support it and that we "hope we'll get more progress in 2014".


DOM Based XSS attacks: what is the most dangerous example? I knew that XSS attacks (“non-persistent” and “persistent”) can hijack user session, deface websites, conduct phishing attack, etc.

However, I can't understand what is dangerous of DOM Based XSS if its not able to (Hijack session, click jacking, etc)?

I reviewed OWSAP DOM Based XSS and also This Page that outlines these two notes:

  The malicious payload was not embedded in the raw HTML page at any time (unlike the other flavors of XSS).
  This exploit only works if the browser does not modify the URL characters. Mozilla automatically encodes < and > (into %3C and %3E,
  respectively) in the document.

Then, what kind of attack (XSS DOM Based) Can accomplish?

Cross-site scripting is cross-site scripting -- the difference between DOM/persistent/reflected is only in how the attack is done (and prevented).

The threat is the same -- an attacker somehow has injected malicious javascript into pages that they shouldn't be able to control, usually due to vulnerabilities in the design of the website.

Take the example from OWASP, where the HTML page, included some inline javascript (part inside the  tags).  The purpose of the inline javascript was to a variable from the "default" query parameter and use the value of it to modify the DOM -- that is change the value of the first <option> tag to the value of that query parameter.

The webpage source (sent over the network) looked like:

Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>

but after being viewed from http://www.some.site/page.html?default=French, the DOM would become:

Select your language:
<select>
<OPTION value=1>French</OPTION>
<OPTION value=2>English</OPTION>
</select>

Meaning your web browser treats the webpage like the above was sent over the network once its run the DOM-modifying javascript (the calls to document.write).

Now a clever attacker then sends a link (via email/webpage link) that a victim clicks pointing to http://www.some.site/page.html?default=<script>alert(document.cookie)</script>.  Then the webpage on the page (after processing the initial javascript with the document.write) looks like:

Select your language:
<select>
<OPTION value=1><script>alert(document.cookie)</script></OPTION>
<OPTION value=2>English</OPTION>
</select>

Again alert(document.cookie) could be whatever arbitrary javascript the attacker wants.

Maybe there's a secret username/password or session cookie or credit card number on the page, and instead of alert you bind pressing the submit button to an ajax call so that when the user presses submit, it sends all the secret data to a server that the attacker can access.

There isn't really one worst-case scenario -- any action you can do with javascript you should be able to do if there is a DOM-XSS vulnerability.


HIPAA compliance without PII I have a web site where people fill medical syndrome questioners.
They can see how their condition changes during the time period.

I am not storing ANY PII information, just user name.
I can store in encrypted (if I have to).

My question is – Do I have to be HIPAA compliant? Remember NO PII.

If I would store email address (encrypted) – will it change my regulatory situation?

Thanks

Aaron

Yes, you do have to be HIPAA compliant.
I'll keep the reasons as short and as logic as I can:

Protecting data by the use of cryptography is nothing else but a security layer you are using (which is good) but it does not void the need to be compliant to Health Information Privacy. In fact, this kind of protection is described in the "Security Rule" of HIPAA.
A "health profile" by itself can be personally identifying even without the storage of a name or email. One of many examples would be possible information about a person's DNA, or an uncommon disease, or a specific handicap, or even a non-typical illness. Even the blood-type is PII when you combine it with small pieces of other information from a health profile.
You talk about requesting a name or even an email. A real name or even an email address on it's own also qualifies as PII as it explicitly allows personally identification. Combine that with he "health profile" and you're in even bigger trouble if HIPAA compliance isn't 100%. An example of what happens when it's not: July 2011, UCLA agreed to pay $865,500 in a settlement regarding potential HIPAA violations. Think about it. Stuff like that happens. Got enough cash in your pockets for something like that? If, I bet you'ld rather spend it on something else. ;)
You describe the example of "web site where people fill medical syndrome questioners. They can see how their condition changes during the time period." Tracking these "medical conditions" is like tracking website visitors online: every additional piece of information builds a more complete "profile" up to the point where people can personally identify the people by looking at their condition changes and comparing that (for example) with a randomly selected group of people that could potentially match such profiles.

There are a few more points, which I'll skip to keep it short. But
as you see, there's already ample reason to watch your steps if you think about collecting "health profiles" while thinking about ignoring HIPAA.
The combination of a health-profile with any other kind of personally identifying information (like a "real name" or "email" or even a simple "postal code") actually forces you to be HIPAA compliant.
Besides, it will make your customers/website-visitors/health-profile-providers feel a lot more comfortable and safe if they notice you take their privacy more than serious. I think that's a bonus you shouldn't ignore... including the fact that HIPAA compliance can legally protect you in a worst-case scenario.
To wrap it all up again:

Health Profiles are PII (Personally Identifying Information) since they are PHI (Personal Health Information). Guess why HIPAA was created in the first place!
Emails are PII.
Names can be PII when real names are used.
Encryption has nothing to do with the question "if" or "if not" you need to be HIPAA compliant, because "what has been encrypted can be decrypted". Let me be absolutely clear on this one: Encryption does not void the fact that you collect PII, it only protects the data you collect.

In fact, you should go check on HIPAA yourself to make sure you know what you're asking about here...
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html

Protected Health Information. The Privacy Rule protects all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Privacy Rule calls this information "protected health information (PHI)."
“Individually identifiable health information” is information, including demographic data, that relates to: the individual’s past, present or future physical or mental health or condition, the provision of health care to the individual, or the past, present, or future payment for the provision of health care to the individual, and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual.13  Individually identifiable health information includes many common identifiers (e.g., name, address, birth date, Social Security Number).
The Privacy Rule excludes from protected health information employment records that a covered entity maintains in its capacity as an employer and education and certain other records subject to, or defined in, the Family Educational Rights and Privacy Act, 20 U.S.C. §1232g.
De-Identified Health Information. There are no restrictions on the use or disclosure of de-identified health information.14 De-identified health information neither identifies nor provides a reasonable basis to identify an individual. There are two ways to de-identify information; either: (1) a formal determination by a qualified statistician; or (2) the removal of specified identifiers of the individual and of the individual’s relatives, household members, and employers is required, and is adequate only if the covered entity has no actual knowledge that the remaining information could be used to identify the individual.15

As you'll notice, my answer indicates nothing else than what the "U.S. Department of Health & Human Services" says... I just use more human wordings. ;)
Now, if you really want to avoid being compliant to HIPAA, all you have to do is to make sure your "health profiles" are 100% anonymous. No emails, no real names, no collection of any potentially personally identifying information or health information... the lot. And be sure you're not missing something!
The alternative to that is to make it easy on yourself and simply choose the HIPAA compliant way to work.
If you want to dive in a bit deeper, there's some additional info at https://www.cms.gov/hipaageninfo/ which might be interesting for you to check out. That is, besides that link I already noted above: http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html


Can an old fashioned crypt encrypted file be brute forced, if so how? If I encrypt a file using the old Unix/Linux crypt() function, how can it be decrypted or attacked?

I understand how a password file (for example) is attacked, you guess passwords, run them through crypt() and see if the result matches the entry in /etc/passwd (well, /etc/shadow on modern systems).

However, I don't see how you can do this with an encrypted file, you can't seriously guess the contents of the file and run that through the crypt() function to see if you get a match for the encrypted file.

The usual way of cracking an encrypted file is trying different keys until you get a result which makes sense. How do you know you found such a result?  Usually because you know the resulting file must have some kind of internal structure. For example, when you know the decrypted file is in an XML format, you would run every result through an XML validator. Or when you know the decrypted file has its own checksum somewhere, you would check if it matches. When you expect natural language text, you could check the letter frequency to be similar to natural language.  On UNIX systems you have the tool file which can detect many common file formats. When it returns something, it might be a possible hit.

But when you have no idea at all what might be the content of the file, you have no way to tell if the garbage returned by applying the algorithm with a random key is in fact the garbage you are looking for.


Wiping possibly infected USB drive If I disabled any automounting in the OS, is it safe to plug in a possibly infected USB drive(whatever the worst case in terms of that) to wipe it?

If the (infected) drive is set to autorun malware after mounting, will erasing or overwriting the partition table prevent it from running?

If automount mount is disabled I don't see how they could infect you. You could even go a step further and boot a live image and run your DD from there.


Distributed tokenization for credit card numbers I have two locations within the same firm that hold credit card numbers.  I want to be able to "join" on credit card number to do business analytics after transmitting card number-linked data from one location to another.

The credit card number itself isn't actually needed to link the datasets.  A token, with zero or very rare collisions, would be good enough.

The problem then becomes how to generate tokens in the two locations such that the same credit card maps to the same token, and do so securely.

Naively, one could just use a cryptographic hash, but since the space being mapped is so small (facially 10^16, but of course actually less than that), that's not a good solution, especially if the hashes aren't salted.  (And it's not clear how salting would work and yet enable records to be linked anyway.)

One could also propose using strong symmetric encryption of the CCN's themselves, with very careful sharing of the secret key, but I'm not well enough versed in cryptography to know if the fact the set of plaintexts is so limited opens up the scheme to attack.

(NB:  I know one shouldn't "roll your own crypto".  I'm not directly on this project, but I'm curious about the solutions I hear being discussed.)

The first thing I would do is run any proposed solution past your PCI auditor to ensure your not going to deploy anything which will cause issues and put the company outside of PCI compliance.

It sounds like all you need is to have the card numbers tokenized in such a way that you will always get the same token given the same card number and there is no requirement to go back the other way? This would indicate you are after a hash rather than encryption. You can add a salt as well.

A lot would depend on what data will be associated with this information. If the only data you have linked to those hashes (outside your very secure vault) is the hash of the card number and no other personally identifiable data, such as card holder name etc, then a good hash, with a salt to increase the length, will likely be sufficient. Credit card numbers just by themselves without other information are not that useful. We already know the algorithm to verify valid credit card numbers and so could just as easily generate large numbers of valid card numbers. It is only when you can add the additional information, such as expiry date, card holder name etc that the data becomes really useful.

On the other hand, if your going to include additional sensitive data in your work, then I would be looking at ways to generate a unique token which does not rely on the credit card number - customer id or possibly a hash which consists of multiple fields - it really depends on the details of what your trying to do.

In general, think of the worst case scenario - don't assume your solution is safe. Instead, assume someone will be able to reverse engineer it at some point. then do a risk assessment of what the impact will be if they are able to do it. Then look at ways you can reduce that impact as well as ways to reduce the likelihood. For example, be very sure that all the data is actually needed - sometimes, just removing some bits of data can make all the difference. Also consider what controls you can put into place to alert you to a problem i.e. detection of unauthorised access, response to unauthrised access, etc.


Password help with coding! So, I'm terrible with any sort of coding, and I need help with generating a series of possible passwords. I've forgotten the combination of a password I put in for an email - I know the password, just not which letter was capitalized and which weren't.

I'm trying to write some code to output all the possible outcomes of the password with capitals in different places. The password is 7 characters long.

Edit: I know the placing, too, so I don't need a randomizer. Just the capital and lower cases in all possible locations.

Edit 2: I tried

def random_char(y):
    return ''.join(random.choice(string.ascii_letters) for x in range(y))

print (random_char(7))

it didn't work, I need the output to be the specific letters and number I know I put in my password.

If the password is 7 characters long - then that is the maximum number of alpha characters possible (some may be numerics). Therefore the maximum number of combinations will be 128 - which surely just takes some determination and a bit of time to work through methodically.

E.g.

passworD
passwoRd
passwoRD
passwOrd
passwOrD
passwORd
passwORD
passWord


Do my Android apps use TLS or other encryption when connected to public Wifi? How can I tell? I have an Android phone. When it's connected only to my carrier's 3G network I imagine it's reasonably secure against eavesdropping (although not invulnerable). However, at times due to lack of reception or other reasons, I may connect to a public Wifi network and use my phone that way.

It worries me though. If I use my GMail app, or a banking app, or even something less important like Twitter, is my data being sent securely? Or is it likely that somebody else could be reading my messages sent in this manner?

If I load GMail or Twitter in a browser, I can see if the protocol in the URL is https, and if the certificates appear valid. Most browsers have a prominent icon to let you know when they are in secure mode and everything checks out. The Android apps I've seen have nothing like this, so as far as I can tell I have nothing more than blind hope that the developers have secured the traffic in their apps.

Are the Android apps I have sending my personal information over Wifi securely? How can I tell? And is there standard or feature of the OS that Google can use to enforce this? Or is it every developer for themselves?

The encryption and authentication inherent to the 3G network protect you only within the infrastructure of the 3G provider, but not beyond. If you do a plain unencrypted HTTP connection with your phone, the data is unprotected once if gets outside of the provider's network, and enters the Internet at large, where wild beasts roam. If an app is sending unprotected private data, you have a problem, regardless of whether the sending goes first through WiFi or through 3G. The WiFi just makes the problem more locally obvious.

To get an idea of how things are handled on your phone, you may run a packet capture application, just like you could do with a PC. It will probably needs the phone to be rooted, though. Moreover, even if the capture shows an SSL/TLS session, you still do not know how the client authenticates the server certificate (in particular, what root certificates are accepted by the application, and how it matches the certificate with the intended server name), so you cannot gain full assurance that a random app does things properly.

There is nothing in the OS which enforces use of TLS; but at least a reasonably good TLS client is provided, and most app which want to do some SSL/TLS will actually use HTTPS, for which the default implementation does things in a reasonably sane way (just like a Web browser). So we can say that an app developer who uses SSL/TLS but botches it must have been inordinately creative in his sloppiness.


How do i verify a banks contact number is correct? You will often get contact numbers for banks online or through other people, even on the back of your cards. How can one verify whether a number is genuine?

For it seems to me that it should be easy to send specific emails/voice messages saying call back on this number, but once you are on the call, there is really no verification of the dialed number, only the person calling.

What system could be devised to verify the receiving party is genuine as well, as they can easily fake a verification system for your responses, and testing them by telling incorrect information seems like shooting yourself in the foot, as it might get you locked out of your own account?

I know the current method of ensuring correct numbers is dialing the number at the back of your card, or from your statement, or from bank's website, but I am sure all that information can be modified in some way or other.

To add a bit to the discussion -

Over the phone, all you hear is a person talking, and they can be persuasive, regardless of if they are genuine or not, that's why most scams work on the telephone, as there no other indicators of authenticity.
Whereas online, you can see the SSL symbol, verify the domain name, and see their branding ...etc (admittedly this all can be duplicated as well, but is not at the same level of ease as duplicating a call script and a person).
At a branch - again you have the branding, and public visibility, professional staff (more than one, in a decent branch). These are legally protected as well from duplication.

Sophisticated phishing attacks have successfully used a combination of these to trick end-users. Usually incoming calls are the chief suspect, but outbound calls could also be tricked is my guess. The reason i posted this question, was I got a similar incoming call from the fraud department and asked to verify with PIN, and I wasn't sure even after calling the legitimate number.

If you cannot trust the phone company to route your phone call, do not use a phone.

If you are concerned about the number being legit, just ask for it in person at the bank, use official papers, cross-reference with a phone book and the website. Use your personal account space online to get the contact information.

If the bank is decent enough and the persons here well trained, they wouldn't share, confirm or denying personal information about yourself.


How to make Squid Proxy undetectable by ip-check.net? I have setup squid proxy on a CentOs server where I set forwarded_for to delete and denied request headers on the /etc/squid/squid.conf file. However, whilst connected to the proxy, if I visit http://ip-check.net/detect-proxy.php it still detects that I'm using a proxy. How can I configure Squid to hide the fact that I'm using a proxy?

The URL you've used seems to determine if a client uses a proxy not (only) based on HTTP headers but also where the request comes from.
To check I've used ssh -Dport dst, which creates a SOCKS proxy listening locally on the given port and where the traffic then comes out of the proxy with the IP address of the SOCKS endpoint. I've tried this with an external system at some public hoster and with localhost as a target: in case of localhost the URL claimed that no proxy was used while in case of the external system it claimed that a proxy was used. But the difference here was only in the source IP of the traffic, not in the use of a proxy.
While no details are known it is possible that this specific detection algorithm distinguishes between IP addresses which are associated with public hosting sites and other IP addresses, and in the first case simply assumes the use of some proxy, VPN or similar.


Wifi for Room Renter? I am considering renting out a room in my house (I'm the owner).  One issue is about providing WiFi.  I have Comcast Wifi.

I have asked another person who told me they give the renter a guest password (not sure who the provider is).

My concern is if they (or maybe one of their friends) does something in my network.   Also, I don't want to be the go-to person every time something goes wrong -- my Wifi has been fine so far -- don't know if higher usage might change this.  If I did this, I'd be specific in the lease that nobody else (friends) can use the WiFi.

I called Comcast twice, and basically they don't have an answer.  The guest password seemed iffy -- I wasn't clear on it, and it sounds like it's temporary.

What would be a safe way to provide WiFi to a room renter?   Or is it better just to have them get their own mobile hotspot and not deal with this issue?

In order to properly secure yourself from guests, you'd want the guest AP on a separate network (e.g a VLAN) and you would block access to/from the rest of your home network to the guest network.You'd want a dedicated router or firewall that can implement some form of usage caps and enforce network access controls. Unfortunately these things all carry a price tag - which can be minimized at the expense of time and effort.

I think you just have to trust your house guests. Depending on where you live you may also be able to protect yourself with some form of a written agreement with the guests.


Privilege Escalation: C functions setuid(0) with system() not working in Linux Quick disclaimer: I fully understand that the code I am attempting to write is insecure, and allows for arbitrary users to escalate to root. I am writing a simple C program like this to demonstrate how privileged escalation works to those unfamiliar.

What I have right now is a simple C program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int BUFFERSIZE = 512;

void main(int argc, char** argv) {
  char ipaddr[BUFFERSIZE];
  snprintf(ipaddr, BUFFERSIZE, "ping -c 4 %s", argv[1]);
  if(setuid(0) == -1) printf("setUID ERROR");
  system(ipaddr);
}

I compile this code as root and set the permissions as such:

-rwsr-xr-x 1 root root 16840 Oct 28 14:13 pingSys

As you can see, the setUID bit is flipped. So what should happen, is if I run the program like so:

./pingSys 127.0.0.1; /bin/sh

It should execute ping -c 4 127.0.0.1; /bin/sh as the root user and spawn a shell. But instead, I get this:

user@localhost:~/privEsc$ ./pingSys 127.0.0.1; /bin/sh
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.118 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.089 ms

--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 59ms
rtt min/avg/max/mdev = 0.034/0.082/0.118/0.031 ms
$ whoami
user

What is going wrong here? I have the setUID bit flipped on the executable, and I even tried running the function setuid(0), which doesn't throw an error. I'm very confused as to why I can't spawn a shell as root because everywhere else I've looked this has worked.

Any ideas?

./pingSys 127.0.0.1; /bin/sh

The semicolon will be interpreted as a command delimiter by the current shell. This means it will first execute ./pingSys 127.0.0.1 in the current shell and then /bin/sh in the current shell, i.e. spawning a new shell with the current (non-privileged) permissions.

What you instead need to do is to put quotes around your argument so that it gets passed in full to your pingSys program instead of getting interpreted by the current shell:

 $ ./pingSys '127.0.0.1; /bin/sh'
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.071 ms
...
# whoami
root


PHP stuff requests on Node.js based web app? We have a Node.js based web application, that has routes like:

myapp.com/posts/[postId]

We tracked strange requests, which lead to 404 on this routes. The requests were to routes like:

/posts/phpinfo.php
/posts/.user.ini
/posts/info.php3
/posts/phptest.php

Neither we're using PHP nor do i know anything about it...

To me it seems that a crawler/bot is requesting these routes, using some PHP related stuff as postIds which makes no sense (to me)...

Is this legit, though useless, or a security related issue?

What could cause this?

This is a classic case of an attacker scanning your website to look for any interesting directories or files that may lead to exploitation. I can say that this happens to a very high percentage of websites online.

The hacker is running a not so sophisticated directory scan and is using the .php extension by default.

As mentioned in the comments, this question may be able to give you additional information.


vpn vs ssh, what to choose? First of all i am noob in this area so came here to get some idea from the experts.

My friend was telling me the other day that ssh is pretty secure protocol and one should not be worried about network security while using ssh.

In my company, we always use ssh to connect to remote devices. Now-a-days out security expert is saying that he wants to remove all ssh access in favor of vpn. I told him what my friend told me but he is insisting on ssl vpn having better security. Is he right or I am right in the sense that as i am using ssh i am secure enough.

In other words, does ssl vpn give any extra security facility that ssh does not give or ssh could fail badly in those fields?

VPN and SSH are similar in the sense that they both establish a trusted and encrypted point-to-point channel, but that's pretty much where the similarities end. The goal of VPN is to grant you access to a network you would otherwise not be able to access, while the goal of SSH is to grant you shell access to a particular system. They play different, non-exclusive roles -- it is perfectly common to require VPN before being able to use SSH.

There are multiple benefits of using VPN over direct ssh. SSH is a root-level daemon that gives direct access to a device. There have been 0-day vulnerabilities in SSH in the past, and who knows, there may be one lurking around the corner, giving attackers direct access to any internet-exposed system. Alternatively, a misconfigured ssh daemon may allow logging in with passwords that can be guessed or sniffed via keystrokes. Not exposing ssh on your devices directly to the internet is a very good security policy.

VPN, on the other hand, is usually done via an appliance or via a non-root daemon, limiting the attack surface. VPN also dramatically simplifies access to restricted resources other than just SSH -- e.g. internal-only websites. While you can port-forward using SSH, it is a lot more hassle compared to using a VPN. Additionally, running a VPN server allows implementing centralized 2-factor authentication, assigning static internal IP addresses to authenticated accounts, etc. The latter is useful when tracking admin access via netflows and when restricting access to internal resources by groups.

In other words, requiring a VPN connection before accessing ssh on systems is both common practice and good security policy.


How are client side hacks created? Many games today are prereleased in an alpha/beta state and instantly overwhelmed by "hackers" downloading programs manipulating the game itself to become overpowered.

I guess they make injections into certain memory addresses in runtime but I have no clue of how to go about to create a program like that. Also, how do you prevent it?

Any suggestions of how they do this are greatly appriciated.

The more details, the better!

Your question is really broad. I can tell you about how I did in one instance, for fun, in a small arcade game several years ago. This should make you gain some educational insight, but won't help you much otherwise, I'm afraid.

I simply had another program running in background, scoping the memory of the arcade game.

I started playing, and then I lost one life. Hit both shift keys -- and a snapshot of the memory was saved to disk unbeknownst to the running arcade. Then another. BAM another snapshot. A third, and a fourth. And then game over and I exited the arcade game.

Then I just compared the snapshots, looking for a memory location that changed from one snapshot to the next, either increasing or decreasing by exactly one. I remember finding some twenty of them. I could have checked all of them, but I spotted immediately that one among them, and only one, had value "five" at the start of the game, and became "four" on my first death. And I had started with five ships. Now that's interesting...

So I wrote a small program that would look for that memory address, recognizing it by its distance from other pieces of code and strings that didn't change, checking its value every few seconds, and just poking back "5" into it as soon as it became anything less:

: install
    look for string 'COPYRIGHT ACME GAMES'
    add 1138
    is it a five?
    no, abort, something went wrong
    yes. lie in wait.
: wait
    is it still a five?
    no. Set it to five.
    sleep for a couple of seconds
    goto wait

Sure enough, the next game, I died - and an instant later, my four remaining starships became five again. For the heck of it, I discovered that I could get up to seven 'lives' with this method (eight crashed the game).

By using a "debugger" it would also have been possible to stop the program as soon as the location was modified, thereby seeing which instruction had done the deed. Then you would just blot out that one instruction from the assembler code. Or you could follow the program flow in reverse, and discover where, for example, the collision check was made between your player's sprite and the enemy missiles'. Thwart that check, and the enemy missiles no longer affect you (possibly, also yours no longers affect them; it's a tricky business).

I expect the techniques to have matured and progressed a great deal in these years, but I'm confident that basically the idea is still the same - spot the change you don't like, then either defang the code causing it, or patch the code so that the damage is undone as soon as it happens.

To make things more difficult one could devise strategies to make the changes stand out less, or make them seemingly random. Add "chaff" or "dummy" variables that change just as if they were useful. Use them as telltales - if all variables don't tally, it means that someone is trying to hack.

In the end, however, you can't beat a determined and experienced hacker. All you can do is try making the deed not worth his while. There are code obfuscators, code protectors, code encryptors, debugger detectors, anti-virtualization techniques...


Blocking Windows 10 telemetry destinations with Windows Firewall Is is effective at all?

As it commonly known, Windows introduced plenty of allegedly diagnostics collection tools which collect our private data and send this info to MS servers.
Is it efficient and reasonable to block them by means of Windows Firewall? This seems equivalent to putting the cat among the pigeons, i.e. quite useless. It is naïve to force Windows to protect user from itself. I have a strong suspicion that disregard of firewall rules Windows Firewall will always pass all requests that are treated as "internal" or OS-related. Am I wrong?

Now I use router-level firewall and assume this measure as a most efficient in this case.

There are two competing tools that accomplish the goal of blocking Windows 10 Telemetry

Anti-Beacon by the makers of Spybot S&D
ShutUp10 by O&O Software GmbH

which to use is subjective and I will let you make your own choice.

In terms of using Windows own firewall ... unsure, but to the best of my knowledge both of these programs make use of the hosts file which seems to work just fine.  Something that you have to understand is that as much as M$ wants to spy on you ... this OS is also used by businesses and the government / military ... while im sure M$ could write a backdoor in there own firewall I suspect it would cost them more government contracts then it would gain them in analytics / advertising.


2FA: Do app passwords render the second factor invalid? I am currently in the process of employing a 2FA authentication on as many services as I can. If it is relevant for the question: I use a time-based OTP authenticator app.

When setting up, I noticed that some services offer a way to login on systems which don't allow 2FA by generating specific app passwords:

Microsoft offers  app passwords to login e.g. via IMAP /SMTP

Effectively, this is a fully working "alias" password for my account, bypassing the second factor. Also, due to its "hiddenness" I might certainly forget to regularly regenerate it every now and then.

Is 2FA with activated app-password really still 2FA or have I just replaced my password-manager-generated password with one generated my microsoft?

Another point: people who type a password usually have it remembered and will surely use it on another service - password reuse. In this cases, no matter how long and strong your password is, it is as secure as the least secure service you use the same password.

So if you have a random 128-byte password, but use it on 3 services, and one of them stores it on plaintext (and it happens more than you think), it only takes one leak to your unbreakable password to be left on the wild. And there goes your security.

To protect on those cases, you have the 2FA. It protects the password on every service you activated it, but protects the third party services sharing the same password. Even if the attacker manages to grab both the password and the 2FA token on, say, orange.com, and you use the same password on pear.com, I can bet the 2FA tokens will differ, and the attacker will not be able to log in at pear.com with your password.

Application passwords solves some problems:

No password reuse. Every application will have its own secure, long and unique password.
Less chance to a keylogger grab it. They are usually set-and-forget, and most of the time it gets displayed only once, and if you forget to copy it, you must generate another one. As they are long, you will copy and paste, not type.
Less change to fall for phishing. User will most of the time go to the service they want to connect, generate a password, go to the application, and configure the password. It's very rare to see a phishing site asking for the user to setup an application password.
Easy to revoke. One application is misbehaving? You suspect something is wrong with one application? You don't want to use a service anymore? Easy: revoke its password. No need to change the main password, and change it on every single connected service.

As the threat models for user entered password and protocol-used password are different, you need a different protection. That's why an app password is secure, even without 2FA.


Should I be concerned about this ip spider accessing my documents? So I set a hacker trap. Created a word document named 'passwords' filled with fake information. And I was just notified that is was accessed by this ip: 141.8.142.232.

I looked it up with nslookup and got this:

Non-authoritative answer:
232.142.8.141.in-addr.arpa  name = spider-141-8-142-232.yandex.com.

Should I be concerned? And if so, how can I prevent this?

update
Should of mentioned the file is in my private documents on my computer. Which is why I'm concerned. A yandex bot shouldn't have access. And I don't know if it is just impersonating yandex. Either way it's not good, and I don't know how to fix this

This question is a bit unclear, while the comments are correct if in fact you did put this file in a public location. i.e. in some sub directory of a web service, accessible to anyone who navigates to this file. You dont specifically mention this.

What I'm saying is the answer to this question could vary heavily depending on where exactly this file was. was it on a web server? or was it on your desktop. these are two very different situations.

Yandex is the web crawler for russia's largest search engine. think of it like their version of google (for russians who dont use google already). It's harmless. Unless somone is impersonating it (paranoia hat). By itself its meaningless, but again, if yandex is crawling the root folder of your home desktop, thats a serious issue, not because of yandex, but because yandex can get there. What i think is really going on here though is you set up a web server and just put this file online, where all the search engine bots will pick away at it. You will find many doing so. In order of highest percentage of web crawled, at least it was, i don't know how outdated my list is anymore, its been a few years, but its good enough to give you the idea.

Googlebot
Baidu Spider
MSN Bot/BingBot
Yandex Bot
Soso Spider
ExaBot
Sogou Spider
Google Plus
Facebook

these little guys are how all of our search engines work, they need to know whats out there so they "crawl" all over the place and find out.

if you want to lay a "hacker trap" you are better off using what are called "honey pot" tecniques. involving fake mysql dbs, hidden forms, fake RFI vulnerabilities and things like that.


Legality of downloading leaked hashes / attempt cracking Note: I realize there is no legally binding talk hereinafter.

There are lots of leaked password hashes on the internet. Twitter searches for "hash dump" pull back tons of links, generally from "deep web" servers. As security yokels, we find it interesting to see how secure (or insecure) these dumps are; many are from reputable entities. To that end, it would be fun, interesting, and provide good experience to crack some of these dumps.

A court had previously found a man guilty, as Thomas pointed out in this answer, for simply running a password cracker, but this was expunged (as if he never did anything wrong). In addition, gimmiky articles have journalists writing about how they've cracked passwords.. I doubt they'd be shouting it if it were illegal.

So, is there any legal risk at visiting one of these "dump servers", downloading the hashdump, and cracking passwords? At what point do you metaphorically "cross the rubicon"?

Obviously, using any cracked passwords would just be rude.

Starting with the huge caveat that this may or may not apply based on your locality and is not in any way legal advice, a large portion of cybercrime laws are based around illegally accessing resources.  If you use a computer system in a way that it was not intended to be used, you could be prosecuted by the owner of the system.  This is essentially laws in the vein of trespassing.

Now, one could make the argument that the list is stolen goods, however that often doesn't really hold up very well as it isn't stolen, it is a copy.  The copy was obtained by trespassing to get it, but the information itself (unless protected by intellectual property somehow) is not actually stolen.  It is the user's copy even if illegally obtained.

In most cases, that means this information can be distributed just as freely as any other leak.  The copy of the file belongs to the attacker and if they release it, then accessing it is probably legal.

Now, that could be wrong if your local jurisdiction may have laws that make it illegal specifically, but it becomes a tricky slope if you are responsible for determining if every single thing you access was legally obtained.  Again, most of the precedent of this kind of thing stems from intellectual property and is most often civil law rather than criminal.

One thing is certain, it is a complex legal issue with no immediately clear solution.  It will take time for the legal system to catch up with the 21st century in a way that helps prevent cybercrime but that doesn't cause unintended consequences at the same time.

Your best bet, as always, is to talk with a lawyer in your local jurisdiction that is up to date on the laws where you are rather than talking to a random developer on the internet that just happens to follow the applicable laws half hearted and casual.