How were weak passwords brute forced in github? Github faced a brute force password-guessing attack recently that involved "nearly 40K unique IP addresses".

Passwords were also "stored properly" using bcrypt, (salt + hashed).

Given that bcrypt generates a random salt per password and that the Github database wasn't compromised, how was a "remote" brute force attack possible and how long* was that process?

  "These addresses were used to slowly brute force weak passwords or passwords used on multiple sites."

Given that bcrypt generates a random salt per password and that the Github database wasn't compromised, how was a "remote" brute force attack possible and how long* was that process?

Two different attacks are being confused here.  Brute forcing password hashes means the attacker has got ahold of the database table containing the password hashes and if they are properly salted and hashed, then it is very time-consuming to brute force.

In this case, github was attacked by guessing passwords at the login page so it doesn't matter how the passwords are salted or hashed or anything.  It just matters if the user in question used an easy password.  Github says "we aggressively rate-limit login attempts" which means it locks an account out after x tries for a certain amount of time.  The attacker had resources (40,000 unique IPs to guess from) many accounts to choose from, and a long period of time so they could lazily keep guessing and waiting for the lockout to expire.  Even with all those resources, their bot can't guess fast enough to break into accounts with anything but dead simple passwords.

It is really great that github posts a security history at https://github.com/settings/security for your account to see account activity (failed logins, logins, etc.)


network traffic decryption with proxy devices How is data decryption handled with proxy devices in perimeter networks (DMZ) in companies? Let's assume we host hundreds of web sites on our DMZ servers, how can we get the data decrypted or even first authenticate the server to the external client connecting from Internet ? I cannot imagine that Symantec , GoDady etc. would provide us with a Root CA for our proxy device for certificate resign, so how can a proxy by used in such cases ?

The CA will not provide you with a certificate for a proxy. They will also not provide you with a certificate for a specific server. They will just provide you with a certificate matching a specific hostname (or multiple names). Where you use this certificate is up to you (some CA might restrict this). You might even use the same certificate on multiple system.

This means for your case that you could use the same certificate both on the proxy and on the final server, i.e. terminating the TLS traffic at the proxy and then having another TLS connection with the same certificate to the real server. But you could also terminate the TLS traffic at the proxy with the certificate issued by the public CA and then use a different certificate for the real server by using your own PKI which is trusted by your proxy. Or, if the connection to the real server from the proxy is considered protected by other means (like IPSec) you could also use plain traffic without TLS to connect from the proxy to the real server.

By terminating the TLS connection in the proxy the proxy has access to the plain text and can also make changes to the traffic, like requesting authentication, filtering traffic in a WAF etc.


User Account with no password I'm currently job searching, and sometimes I come across sites that are just huge databases full job postings, and before you apply you have to create an account. I came across a site, but I'm skeptical of its security practices.

When I found a job posting that I wanted to apply to it asked for my e-mail address, so I entered it. A pop-up asked for me for resume, and the usual contact information. I supplied want I needed to and I sent my application.

I noticed however, it used my e-mail address and created a user account without prompting me for a password.

Immediately, I was alarmed by this, so I checked my e-mail thinking that the site supplied me with a temporary password that it requires me to change, only to discover that I had to confirm my e-mail address and then be prompted to enter a password. From my perspective, I had a user account with no password for maybe 3-5 minutes.

Was I right to be skeptical? Should I delete my account?

Just because you had not set a password, that does not mean that your account could be accessed. Without seeing the code, I cannot be sure, but it is possible that you could not log in to your account until you used the link in the email to set the password. You were still using the same session ID while you continued to use the site.


How does an android device/os prevent me from getting root? I have never used an android phone and so hopefully this is not a bad question to ask.

I know on iOS the kernel itself is signed and so cannot be extended and all applications are signed. Hence I cannot ssh/telnet into it for example and getting a shell. Unless you jailbreak it and disable signature verification and do other stuff you cannot install custom apps as well.

So how does it work on Android? Is the kernel signed? If so is rooting and android device similar to jailbreaking an iOS device? I read some articles saying that you can install custom kernel onto an android device, which kind of indicates that the kernel is not signed. So is this how root access is prevented? The kernel does not allow userid 0? What exactly happens or needs to happen to prevent root access? Or what actually needs to happen to OS functionality to enable root?

As already indicated by @Cube in the comment, some (not all) Android phones allow to unlock the bootloader to flash custom kernels and firmware to your device. However, there is only a limited number of models that support it since it is meant for researchers and developers. Also, during the unlocking process you lose all your data, so you cannot use this to silently flash a malicious system or kernel to someone's device without him/her noticing it.
But in general, the bootloader is locked, so this is the one line of defense against getting root: disallowing to flash custom software. As an experimental feature, Android recently also introduced dm-verity to make persistent rootkits even harder.

The other way is to use privilege escalation attacks, meaning you actively exploit a vulnerability in Android that allows you to get root privileges. For example, some services need to run as root, so if you can run code in their context you execute your code with root privileges. However, let's get back to your question about the defenses. First, app's processes are isolated from other processes and the middleware by the kernel. More concretely, Android (ab)uses Linux' user seperation by assigning each app a unique userID. So the kernel isolates them the same way as users are isolated on classical Linux systems. So classical viruses where other programs/apps are infected is simply not possible on Android if there is no critical vulnerability at hand. Also, the middleware contains a lot of access control points where the caller is checked and verified. In addition,
beginning with Android 4 Google started to integrate SELinux into Android as the so called Security Extensions for Android, or SE for Android.
Here, more fine-grained mandatory access control is added to further lower the chance of a successful attack.
When it comes to preventing special kinds of attacks, Android also added support for ASLR in the 4.x versions and extended it ever since then. For example, on newer Android 5 versions binaries are only loaded if they are compiled as position-independent executables.

So this is a subset of all the defenses that Android provides against attacks in general or root exploits in particular. This list is not complete but it gives you an idea what attackers need to overcome and how much the Android devs care about security (which I personally appreciate a lot).


Would a Password Using All Possible Unicode Code Points Cause Problems in Traditional Hashing Algorithms, such as Bcrypt? I've been toying around with this idea, but hypothetically, if you had a password manager that would use any possible renderable (e.g. not control characters such as BEL, NUL, DEL, etc., or surrogate characters) Unicode code points, and a site backend and hashing algorithm that would accept them, how many bits of entropy would a sixteen character password provide?

I'm not 100% sure I'm calculating this correctly, but according to this StackOverflow answer, there are 1,111,998 possible valid code points for this purpose, so each character should provide log2(1111998) ≈ 20 bits of entropy per character, correct?

Would this break any common password hashing algorithms such as bcrypt? Are there any unforseen problems in using unassigned unicode code points in passwords, save for some sites restricting the character set available to use?

Not really. Hashing algorithms and Key derivation functions (side note: bcrypt is a KDF, not hash) works on bytes, not characters. This means instead of working on Unicode, it sees instead the utf-8 encoded bytes (or whatever encoding you use). So the hash/KDF itself wouldn't have any problems processing Unicode passwords.

However, Unicode had many different representations for the same characters. This is due to combining characters. Different OS and different text entry methods may produce different code points for the same characters. Application developers need to ensure that Unicode characters are normalized before passing it to bcrypt.

Another potential complication is that there are a different number of possible characters between unnormalized and normalized Unicode string. To produce a uniformly random Unicode password generation method, you need to generate uniformly over the normalized characters otherwise your password generation method may bias towards the characters that have multiple representations.


Hawk vs. API key authentication For a HTTP(S) API, which is better (/ which is better under which circumstances)?

Hawk authentication (a secret key is used to create a signature which is transmitted with the request: similar to AWS Signature v4)
API key authentication (a secret key itself transmitted with the request)

A downside of Hawk is that since the secret key isn't transmitted, but just a signature, then the server has to store the secret part of the key somewhere in plain text (/ able to convert it to plain text) in order to sign the incoming requests itself to compare to the incoming signature.

A downside of the API key is that the secret key itself is transmitted.

(Acceptable answers could include "neither: instead do X in circumstance Y because Z")

AFAIK, the standard way is to use asymetric keys for signing:

the private key is only known by the sender
the request is hashed with a standard algorithm, and that hash is encrypted with the private key to form a signature which is transmitted with the request
the server uses the public key to decrypt the signature and control that it corresponds to the message.

That way:

no secret has to be shared
no secret is transmitted
assuming a cryptographic secure hash, it is admitted that it is not possible to build a request corresponding to a given hash


Multiple hash algorithms Using Hashcat, is it possible to crack hashes using nested, or combinations, of algorithms?

As a simple example of what I am looking to do, consider sha1(md5('password')) or md5(sha1('salt') + md5('password')).

As it has been mentioned in the comments, your first example is actually covered by hashcat (hash type 4700). However, it is not possible to create your own, custom hash type "on the fly".


How to protect against SIM swap scammers? SIM swap occurs where the scammer uses phished information about you to request a SIM card replacement from your cell phone carrier, by tricking them into believing that it is you who is making the request for a SIM card replacement by passing their security questions on the phone based on the biometric data they phished about you.
Once they have that duplicate of your SIM card, they can receive access codes to your banking and cryptocurrency accounts, because all of this is linked to your phone number (the SIM card).
How can anyone possibly protect themselves against this sort of attack? Rarely does anyone have a second phone number, so whatever account you based on your sole number, means they instantly have backdoor access (by fooling your service providers using phished information about you, orally over the phone and by online forms)

You don't use SMS for a second factor.
SMS is not secure by any means. The text is on clear, the traffic is on clear, and it's trivially easy to get a new SIM by pretending to be the victim. I once got my phone stolen and got myself a new SIM just by walking to the telco booth and telling my name and the phone number.
Google Authenticator is offline. It does not depend on the SIM in any way. You can even calculate the OTP token using PHP/Python/Perl/Javascript, all offline. You would even be able to do it with a calculator that lets you run programs on it.


Can the content of a password protected zip file be known? Let's suppose that I share an illegal copy of a material on web which is in password protected zip file, can the owner send me a copyright notice or know what's inside the zip without knowing the password?

Yes. Aside from the fact that the filenames are unencrypted, the contents of a password-protected Zip file can be recovered if it uses the old, insecure ZipCrypto cipher which uses the insecure, non-cryptographic CRC algorithm for data confidentiality. A research paper from 1994 showed that an attack against the underlying encryption can be done in several hours regardless of the strength of the password on a contemporary home PC. Nowadays, such an attack can be completed in seconds with free and publicly available tools. You must not rely on default, legacy Zip encryption.
The PKZip format supports three encryption methods. The first is the legacy, highly-insecure ZipCrypto. The second is AES-based encryption stored in the compression field in the metadata, and the third is AES-based encrypting using its own header format. The encryption specification is online. Using AES-based encryption rather than legacy encryption can result in incompatibilities, especially with older programs, but most modern, well-designed Zip programs can handle it.
In order to protect the contents of a Zip file, you should use strong encryption. Various tools such as WinZip and 7zip support an ad hoc AES-based format for Zip files which additionally encrypts the individual filenames and sizes within the compressed archive.


What are the risks to a network if a single computer is compromised? If I open up a dedicated server on my home network to accept incoming connections (HTTP, SSH, etc) and that machine is compromised by an outside attacker, what are the risks to other devices on the network?

Is it enough to keep important personal files off the server itself, or is the entire LAN potentially open to the outside world?

Without a defense in depth security strategy, once the perimeter defense of your network has been penetrated through your compromised server there are a few threats to the rest of your network.

The vulnerability exploited by the attacker could be available on other machines on your network, allowing an attacker to move to another machine with ease.
A poor access control or authentication scheme to other machines on the network could allow an attacker access to those machines or unauthorized use of service. i,e. Intended for ease of use, A web application server that will gracefully accept any kind of traffic from the compromised machine.
Malware could be present on the compromised server, and may even propagate via a network vulnerability itself. i,e. a worm.

To answer your second question, given that your server has been compromised; The potential is there. Any information that you would like to keep the Confidentiality and integrity would best be placed on another machine with limited access. I would recommend some kind of defense in depth strategy. Or a firewall with well configured policy and traffic monitoring. Snort is a free network based Intrusion Detection System if you want to take it up a notch.

Risk is the calculated cost of a threat agent carrying out an attack on asset. (I offer this definition for completeness because some people use risk and threat interchangeably.) Risk = (probability threat will occur) * (Value of the asset).

A threat is the potential for a vulnerability to be exploited by a threat agent/attacker. (Note, acts of god are considered threats, and their risk should be accounted for!)


Does an email newsletter form on a HTTP-only website constitute a GDPR violation? Problem:

I am part of a non-profit club that has a form on the website for signing up for an email newsletter.
The website (and thus form) is only available through through HTTP. HTTPS is not available on current infrastructure.
There is no other data the interested party shares with us through this form, only a field for their email.
The email distribution itself is later processed through a common service (such as Mailchimp, GetResponse or similar).

Question:

From a GDPR standpoint, will the club seen as negligent for accepting emails (which may be personally identifiable, and thus confidential?) over a knowingly insecure connection? Does it constitute a GDPR violation?

The act of collecting data on an insecure connection may not actually violate GDPR but to be safe you should go for ensuring personal data is always protected. GDPR's main concern is the processing of personal data and the exchange of personal data from a collector to a processor.

So for example, you mention that the emails get sent to mailchimp, you will need to ensure that this is done in a secure manner.  This is where GDPR really plays: can you demonstrate that you are not storing the emails in an secure manner, canyou demonstrate those emails are being submitted to mailchimp in a secure manner.

Also remember that today solutions like Let's Encrypt allow you to easily get a web server certificate with no cost.


Addressing 'body parameters accepted in query' vulnerability I received a failure on a vulnerability assessment  because a heuristic determined I was probably processing query string parameters as form values (they used the words 'body parameters').

I think this is a false positive because MVC (the technology), similarly to other frameworks, routes GET and POST based on rules. The method which gets executed on GET is fundamentally detached from the form.

Also, AppScan seems to indicate that it determined this failure based on the "test response" being similar to the "original response". I can't find any information online to understand or address this issue.

This vulnerability is considered "low" and has a CVSS score of 5.0.  The pen test takes an existing page and simply changes the verb in the submit, passing the form payload in the query string.  If the web site raises an error, or displays a page that is different from normal, it is a PASS.  If the web site returns a page that is substantively similar to the normal page, it is a FAIL.

Handlers for POST requests often have different mitigations; for example, CSRF is often implemented for POST and not for GET.  By changing the verb, an attacker could potentially bypass the check.  An example can be found in the common vulnerability database, here, if you are curious if this is ever an issue.

You could actually have a vulnerability if you have used the ActionName attribute to map the GET and POST to different methods and the methods have different filters (e.g. POST has the AuthorizeAttribute and GET does not).  That would be a pretty serious oversight and would need to be corrected before closing this issue.

On the other hand, this sort of test is likely to produce false positives, especially on pages where the posted content doesn't have an immediate effect on the user experience.

If I came across this report for an MVC site, I would just check to ensure there is a verb restriction on the action method, and then mark the item as "false positive" and move on, without thinking about it too much, for reasons that the OP has explained.

If there isn't a verb restriction, you will either need to add it (with an HttpPostAttribute), or come up with a justification as to why the page/handler is not sensitive or is not less vulnerable when accessed via GET.


How do I identify, characterize and detect if trusted CAs compromised? What is the best approach to use in identifying, characterizing and detecting compromised CAs? I do not mean an invalid certificate or invalid CA that can be identified by an X.509 during validation process. I am looking for a tool/approach that can identify and detect “trusted CA that is actually compromised. For example the cause of compromisation like attacker Impersonate or compromise CA key and try to issue fraudulent certificate/ fake CRL.

A part from existing methods such as CT, key pinning, DANE  etc which partly address some issues related to CA compromised.

I there a way from method like Blockchain, Machine learning or any role based approach can be used to first identify, characterize and detect if trusted CA really compromised?

... like Blockchain ...

CT is already basically the same idea, i.e. a public list of all the certificates issued by a CA.

Also, the actual problem is not if a CA is compromised. The problem is if a CA issues certificates for sites which it is not supposed to do, no matter if this is because of a compromise, change in ownership and policy or bugs. Certificate transparancy provides a public record of the certificates a CA has issued. Certification Authority Authorization provides a way for the domain owner to specify which CA is allowed to issue certificates for this domain - which then could be checked against CT records. Certificate pinning and public key pinning provides a way to narrow down at the client which exact certificate, public key or CA to expect for the certificate.

  ... which partly address some issues related to CA compromised.

I'm not sure if we actually need yet another technology or if we should use existing ones more extensively. It is impossible to tell if a CA issued fraudulent certificates unless it is clear what it is supposed to do and what not in the first place. As long as domain owners don't restrict which CA can issue certificates, any public CA can actually do. Sure, one could use human crafted or automatically crafted heuristics (i.e. machine learning) to predict what the domain owners might want based on previous behavior, but this will always lead to false positives which need to be somehow addressed.


Why regenerating a password's hash? I've read http://alias.io/2010/01/store-passwords-safely-with-php-and-mysql/ on how to store passwords using PHP and MySQL, the secure way. Elbert says:

  Use a cryptographically strong hashing function like SHA-1 or even SHA-256 (see PHP's hash() function).
  Use a long and random salt for each password.
  Use a slow hashing algorithm to make brute force attacks near impossible.
  Regenerate the hash every time a users logs in.

I get the first three rules, however I don't see why the password should be regenerated all the time. Why is that?

What the blog poster probably means is that you should hash the provided password when the user tries to log in, and you will have to do that hash for every login attempt, since the server stores only the hash.

It is possible, but not probable, that the author really meant to change the salt and recompute a new hash upon each login, which would be kinda stupid, explaining why I deem that "improbable". But hey, this is the Internet, anything can happen.

The blog post is partially right. Yes, you need a slow and salted hash. But no, a homemade loop of hashing cannot be condoned. Cryptographic algorithms must not be improvised; homemade is bad. What must be used is a well-vetted construction which has been inspected by many cryptographers over a long time. See this answer for details on the usual solutions. In PHP, this means using the crypt() function with the CRYPT_BLOWFISH parameter.

(Apart from the necessity of using standard constructions, it is also important to use a fast implementation, since the whole concept of slow hashing is a muscle contest between the attacker's machine and the defender's machine. Using PHP standard functions allows for accessing native code implementations, which will be much more efficient than anything written in PHP.)


How secure is Windows 10 account control? I have a Microsoft account in my machine (Admin).
I set a guest account (Standard) for a friend so he can play games.

Is there any way he could access my files/folders info? I mean, get data, view photos, videos, docs...

I knew this could be done in other Windows versions, but I'm scared this could happen in Windows 10, too.

Is there any way he could access my files/folders info?

Yes, he could reboot from a live CD and then access your files directly, unless the drive is encrypted.

He could also attempt privilege escalation by leveraging any vulnerability within Windows 10 (such as this), or via any insecure configuration on your machine (e.g. overwriting a .exe that he has write permission to of which the administrator later executes).

Or he may be able to leave a USB stick in which acts as a network interface and directs your traffic through a device he controls. Usually all bets are off if there's physical access available.

This all depends of course on the skills and motivations of your "friend".


Safety difference between running on localhost versus the private internal ip address? I am wondering if there is any additional security increase by choosing to run your webserver on an internal private ip address and port like xyz.ab.cd.efg:8080 versus localhost:8080 or 127.0.0.1:8080
If so, what does this mitigate against?
For this scenario lets assume that your webserver is serving some site example.com, and that the policy of the load balancer (which is the only interface for internet traffic routed inside your box), is told to only deliver traffic over HTTPS on 443, where once inside your box, local iptables are configured to route the traffic to your local webserver running on {localhost or 127.0.0.1 or xyz.ab.cd.efg}:8080.

I do not think there is any security increase, rather there would be a security decrease.  The localhost or 127.0.0.1 is only accessible from the host computer, or the computer running the web server.  A website listening to only 127.0.0.1 under normal conditions, would never be accessible to any other computer on the private network.
Using a private IP address, you open the webserver to all communications on the private network and communications that are forwarded by the load balancer, to the web server from the internet.


What can be a reason you DONT want to use port 443 for SSL communications I have a very open question which I dont know if it's allowed but I am so curious about any possible answer.

We are trying to make a connection to a other service for my company and the webservice is hosted over a VPN on port 444 with SSL. I am just wondering why you should NOT want to use the standarized port for SSL, 443. Of course it's theoritical possible to host SSL/HTTP communication over any other port than 443 but I dont see a reason to do it.

The only reason I can imagine is that your webservices are routed based on the portnumber. So 443 goes to internal application X and 444 goes to internal application.

Can somebody give me some insights?

The usual reason to use something else than a well-known port is to reduce the attack surface by eluding scans of well-know ports.

Here if the port 443 is not open some 'bot scans' will consider there's no https access possible and won't try their usual attacks on this system.

This is the same reason for not answering ICMP requests publicly.


Getting automatically logged in to others session via Wi-Fi Recently, I experienced a very strange behaviour on our Wi-Fi network: we share a Wi-Fi network using a simple router. One of us pays the bills and he's the one, who got the management account from our ISP.

So if I want to log in to look at my mobile bills (the ISP does both, mobile and wired Internet stuff; I have my own account) I am logged in automatically with his internet management account, from different devices over the Wi-Fi.

How can this be possible? I cannot find useful information about that. As I know from a programmers point of view, simple session management should avoid such a behaviour (e.g. cookies). Does it mean that the session management is only server-sided and just bound to IP (server, programming issue)?

I think the ISP bound the external IP of our router automatically to this single management account, which would be, in my opinion, a very big issue (watching bills, changing address data and so on).

Yes this can be possible. The website of the ISP automatically detects that you are connecting from a router of it's own network. It thinks that you are the owner of the router and automatically authenticates you as such (credentials are stored on the router).

I have seen this done before and it's just stupid design IMHO. Especially if this works from WiFi as well.


Security implications of rooting Android My Android smart phone has fancy features that I can get only if I root it, e.g., free-wifi tethering or Cisco VPN (with group name/password).  However, the procedure to root my phone makes me question the underlying security model.

Specifically, I used a Lifehacker's method that uses an application called "Revolutionary" that first gets the phone into S-Off mode (so you can access the parts of restricted parts of the NAND flash memory).  Then it downloads and installs ClockworkMod recovery and installs to the bootloader, from which I can then run to install a superuser.apk (e.g., from here.)

Revolutionary is closed source, so I have absolutely no idea if it does anything extra to my phone; e.g., install a (malicious) rootkit, keylog my activities, using my phone in botnet ddos attacks, etc.  I don't keep super-sensitive data on my phone, but I still want my accounts to be safe and stay in control of my phone.  I'm also a bit paranoid that Revolutionary needs a key that you get from their website if you submit your serial number.

SuperUser.apk also appears to be closed source, but seemingly vetted by the avgfree anti-virus team as well as Android marketplace.  Though I assume I can use tools like android-apktool to re-egineer the apk.  I can't figure out whether ClockworkMod is open source.

Have any security experts looked into these tools?  I've tried running Revolutionary through a decompiler/disassembler, but couldn't make any headway.  Have there been any published accounts of attacks via this method?  Am I being overly paranoid?  Should I worry that one of these apps did something like DroidDream?

Non-professional opinion here (not a security guy, more of a software dev), but I'd say in the right hands: more secure, considering how many phone manufacturers are not issuing critical updates to the Android operating system, and how many phones are just running around with giant exploits in them.

Also the source code is available, you, as far as I know, can compile it yourself (download from Google, grab drivers for your phone from one of the various projects providing these drivers, review/compile them together) if you're really paranoid.

Furthermore, people putting hacks into your open-source software is a lot more difficult, being as you have a ton more eyes on the code, and anyone can speak up and reference code that they've forked (hence the original guys can't take it down), and it would pretty much be the end of those guy's professional career.

Edit:

HBoot isn't open source, however they do have alternative open-source bootloaders along with projects analyzing hboot:

http://tjworld.net/wiki/Projects/Bootloader-AP


What is the difference between secure element and smart card? From smartcardalliance.org:

  The secure element [...] resides in highly secure crypto chips (usually a smart card chip).

My questions are:

Aside from smart card chip, are there any other types of secure elements?
Is a smart card chip always a secure element? By "smart card", I means a card that has CPU and can do crypto.

According to globalplatform.org, there are three SE technologies:

Universal Integrated Circuit Card (UICC)
embedded SE
microSD.

From the same website, a secure element is a physical object, not data.

  A secure element (SE) is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.


What's wrong with SHA-1 having collisions? Say you go onto a website and are downloading a program. Next to the file there is a SHA-1 checksum of the file. You download the program, verify the checksum and find that it is the same as the one on the website - perfect!
However you soon find that the SHA-1 checksum is not the same because the program is the same, but a man in the middle appears to have delivered you a collision of the program, and it's not what you thought it was at all.
My question is, What's the problem with that? It would be extremely improbable for an attacker to be able to generate a collision that would be a runnable program, and could somehow infect your system. The biggest inconvenience I can see is that you would have to download it again.

So what harm could actually be caused by a collision?

Its been a while that SHA-1 collision was successfully achieved by Google researchers As proof of concept, the research presents two PDF files [PDF1, PDF2] that have the same SHA1 hash, but display totally different content.

You can learn more in this academic paper.

Its also worth to mention that this cryptographic hash function is 22-year old but as far as I'm concerned we still far from seeing real world attack conducted especially in the scenario you described except if you are targeted by a government or a a wealthy criminal enterprise:

  A practical collision attack against SHA-1 would cost $700,000 in
  2015 and $143,000 in 2018. He surmised at that cost attacks,
  especially if they were carried out by a wealthy criminal enterprise
  or government entity, could be feasible. (Bruce Schneier)

Now to be more practical, a SHA-1 collision may affect the Microsoft Kernel-Mode Code Signing Policy for instance. This attack relied on signature verification for loading only signed kernel-mode drivers. You can find more here but for now I'm not sure you need to worry about a MITM attack delivering an altered file..


Can RAM retain data after removal? Is it possible for RAM to retain any data after power is removed?  I don't mean within a few minutes such as cold boot Attacks but rather 24 hours plus.

Working with classified systems the policy always seems to treat RAM the same as disks and must be removed and disposed of according to classification.

Is this a myth which has become standard practice or is there really a data security risk present?

I am assuming regular PC RAM designs over the past 20 years.

This 2013 article analyses retention time for several DRAM chips. Among the relevant information, one may list the following:

Retention time depends on a lot of things, including the values of neighbouring bits. A DRAM bit is a potential well, and it loses its contents by moving charges from or into neighbouring areas, so whether there is room in these neighbours matters.
Temperature is very important for retention time (which is why cold-boot attacks insist on cold: if you plunge the machine in liquid nitrogen, you can keep the charges in place for substantially longer).
At room temperature, typical retention time is counted in milliseconds, at best a few seconds, and, more importantly, the discharge is exponential in nature (it goes in e-Ct for some constant C), as could be expected (capacitors also work that way). So the remaining charge after 2 minutes will be half that after 1 minute; after 10 minutes you are down to a thousandth of the initial charge; after 20 minutes, a millionth; after 30 minutes, a billionth.

To sum up: 24 hours... forget it. You won't find meaningful data in DRAM that has been kept unpowered, at room temperature, after 24 hours (even if the room is, say, in Canada).

This is for DRAM, where a stored bit can be envisioned as a charged capacitor. This is the kind of RAM commonly found in PC for the last 20 years.

There also exists SRAM, where each bit is stored as the current state of a bistable circuit that consists in 6 transistors. SRAM is substantially faster than DRAM; it is also a lot more expensive. In PC, SRAM is used for cache (usually integrated in the CPU). Without power, SRAM loses any trace of its contents within microseconds.

There are some stories about bits being "burned" into RAM when the same value is stored for a long time in a specific emplacement in a chip. To the best of my knowledge, these stories are exactly that: stories. They come from "thought by analogy", by people who think of RAM in the same way as they think about CRT displays (which could have "burn-in" effects, hence the development of "screensavers"). I am not aware of any case where such stories were ever substantiated.

But fears and doubts are powerful forces that cannot always be dispelled by the strongest logic.


bootp enabled by default on dhcp reduce security? by default in Microsoft DHCP server configuration Bootp is enabled and choose both(accept DHCP request and Bootp )

i know that how this work and know about how configure two DHCP Server by Bootp enabled router. but i have a question...

can be this default configuration a security risk?

  if can, how this make hack? (theoreticaly)

for example :
in CISCO documents we have this:

  Option to Ignore All BOOTP Requests

why we ignore that? a security reason?

DHCP supersedes BOOTP; you keep BOOTP around only to help old hardware and software which does not know DHCP. Anyway, both are about offering a service to whoever asks (namely, IP address allocation and publication of network configuration) so they are no more, and no less, a security issue than what their definition entails: by running a DHCP or BOOTP server, you make it easy for people to plug in and get network connectivity.

Neither is more secure than the other, but if you offer both then you must mind both when it comes to controlling access to that service (e.g. MAC filtering). See this page for a comparison.

The usual security stance applies: if a service is not needed for operations, then don't enable it. To know if a service is needed for operations, disable it and see what breaks. In that case, deactivate BOOTP, and if you can live without it (which is probable), just leave it deactivated.


Would it be safe to connect to a shadowsocks server using rc4-md5 encryption? I'm currently using a shadowsocks client on my PC to connect to a remote shadowsocks proxy server using rc4-md5 encryption and wondering if it is safe to do so. Would the server intercept my data because the encryption is deemed unsafe? I'm worried about it as I often use some banking or other privacy related applications.

Thank you.

Would the server intercept my data because the encryption is deemed unsafe?

I'm assuming that you mean with "server" the system where your shadowsocks proxy is running on. While RC4 is considered a broken algorithm it still takes a considerable amount of computing power and thus lots of money to actually break it in practice. Thus it is highly unlikely that somebody will take this route unless you are a very valuable target to hack (i.e. cost of attack vs. gain).

And even if you are a very valuable target it might just be easier and cheaper to capture the traffic leaving your proxy to the final target system which is no longer "protected" by RC4-MD5. Or if the attacker gets access to your system he can replace the shadowsocks binary with some other binary which seems to do the same but additionally forwards the decrypted traffic to some third party.

In summary: don't worry about RC4-MD5 in this case because there are probably far easier  attacks against your setup.


Is Java vulnerable to glibc GHOST Vulnerability in Linux? I see on our RedHat Linux platform that "java" process has dependency over glibc library:

[root@hpproliant1 ~]# ldd /usr/bin/java
linux-gate.so.1 =>  (0xffffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7f77000)
libjli.so => /usr/java/32bit/jre1.6.0_26/bin/../lib/i386/jli/libjli.so (0xf7f6e000)
libdl.so.2 => /lib/libdl.so.2 (0xf7f69000)
libc.so.6 => /lib/libc.so.6 (0xf7e11000)
/lib/ld-linux.so.2 (0xf7f97000)

Does Java APIs call indirectly problematic glibc functions? If so is the jvm using the vulnerable function in a way that's vulnerable?

Possibly.

The two functions that are vulnerable in glibc are gethostbyname and gethostbyname2.  You noticed that java is linked to glibc, but to even be possible to be vulnerable it has to link to these specific functions.

It's possible to scan the ELF binary and look through the linked libraries with the program readelf.

It's recently come out that procmail is vulnerable, let's check this approach works with a known vulnerable program.

readelf --dyn-syms /usr/bin/procmail |grep gethostbyname
    46: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gethostbyname@GLIBC_2.2.5 (2

And it does!

If you can the jvm executable, you won't find references to gethostbyname.

If you scan the libraries included with java, you will:

readelf --dyn-sym libdt_socket.so |grep gethostbyname
    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND gethostbyname@GLIBC_2.2.5 (4)

Whether this is exploitable or not requires further analysis.  But until proven otherwise, you should update your glibc library.


Does complexity of salt in password hashing matter? I have no cyber security knowledge whatsoever, and am trying to safely store passwords in a database. I understood I need to use salt, to avoid rainbow table attacks and to make sure two users with the same password will have different password hashes.
However, does the complexity of the salt matter? I was planning on simply using the user's id (an integer that's incremented each time a new account is created), but is it good enough, or should I generate a more complex salt?

The important part
The fact that you are generating salts on your own is a red flag. The best way to do this, especially if you have little experience with security, is to use an established library for password hashing.
A well-designed library will generate and use salts automatically for you, and it will store the salt and the hash in the same string, that you put in one column in your database.
So, use a slow algorithm designed for password hashing, and use an established library, and you won't have to think about how to generate the salt.
The answer
Still, I should answer your question. Does it matter if the salt has high entropy? There are two properties that we may want the salt to have here, that randomness helps with:

Unique, in your database, between password changes and preferably globally, so that an attacker can only crack one password at a time.
Unknown to the attacker (before a breach), so that an attacker targeting a specific account can not start any preparatory work before the database is leaked.

Using a counter as salt is a decent solution, but not perfect. The salt is at least locally unique, but it's not globally unique or even unique over multiple installations of the same software. It's not unknown to the attacker, but that really isn't such a big issue. Once the hash is leaked, the salt will be leaked too.
But still, using a library that gives you a random salt will be better. Don't mess around with homebrew solutions for something as important as this!


Managing DUKPT keys in AWS cloud I work on a payments system.  So DUKPT keys are a must-have requirement.  In most cases PIN and Card data are encrypted using DUKPT keys.  However, every time we have checked with AWS, we have found that none of the HSMs available on their cloud are DUKPT capable.  That is obviously a non-starter for us.  Can some experts here shed some light on this?  Have you run into this problem on AWS?  How have you worked around this AWS limitation (short of moving away from AWS)?

DUKPT is required for payment processing because PIN pads are comparatively weak HSMs running on low horsepower devices that are at high risk of being stolen and attacked. DUKPT exists to meet several security requirements, including the protection of past keys, the efficient production of future keys, and to ensure datagrams are always different.
AWS HSMs aren’t subject to the same limits or risks, and since their capabilities include cryptographically secure pseudo random number generation, DUKPT doesn’t make sense on that platform.

Instead of asking AWS to meet DUKPT requirements, ask your payment provider for alternatives that work in AWS.


Burp suite - trying all parameters such as numbers|numbers A website I'm looking at for my colleagues has a parameter which is number|number

Where the likely values will be 1-99|1-999 (e.g. 14|234)

How do I configure burp to try all possible values? (Would this be the intruder tool?)

Burp Newb!

You can set up that payload set within the Burp Intruders options.

Just set the payload position in the "Positions" tab in Intruder, and then set the payload type to "Numbers" with your required setup.

For the described scenario with two independent sets for the two positions you should use the "Cluster Bomb" attack type. Then you define two payload sets (one from 1 to 99, the other one from 1 to 999) as described above.

That will iterate through all combinations for payload set 1 while keeping the first element of the second payload set:
1|1
2|1
...
99|1

Then the intruder will choose the next item from payload set 2 and iterate through all of set 1 again until every combination was tested.
1|2
2|2
...
99|999

Edit: Forgot to said that you should also check the "Attack type" in the "Positions" tab to fit it to the request you want to perform. Read about the attack types here: http://portswigger.net/burp/help/intruder_positions.html#attacktype (The attack type is just how Burp is going to handle the payloads in the requests).


AES encryption between Java and Ruby: what is the default mode and padding for AES in Java? I'm writing a ruby app that needs to create some encryption that our java app needs to be able to decrypt. For this I have done some research, and I have this Java code now:

Cipher cipher = Cipher.getInstance("AES");

While in the doc says the format can be of:

  "algorithm/mode/padding" or "algorithm"

in our case that I have posted above is just the "algorihm". But what does its mode and padding defaults to? Also does not say if it is 256 or 128 etc.
I can't find what is the default for AES - I am not a java programmer, so sorry if I missed it. And I need it to be able to replicate in Ruby.

The default mode of operation and padding isn't defined by the JCA Standard. Each provider is free to provide different default values. As you can imagine, relying on the default values is completely unreliable so you should always explicitly set the mode of operation and padding.

For Oracle JDK 7, the default for AES is AES/ECB/PKCS5Padding.


How does the Intel CPU design flaw affect us? Today, I saw this in the news. I'm hesitant to install the fix, because I've heard it would slow down IO 50%, which is not acceptable for me.

But a guy said that the flaw allows JavaScript in the browser steal your information. Is this true? Worst case scenario for me is that any website I visit could run some dangerous JS that takes conrol of my PC. Only that would get me to install the fix.

I am not familiar with security, I just want to know actually how it affect us in the real world.

The Spectre and Meltdown attacks are about programs reading data they're not supposed to.  They don't provide any way to make modifications or take control of computers.

If you're running a typical desktop system, the flaws aren't a major threat simply because anyone in a position to use them has so many other ways to do the same thing.  The real risk is to cloud services and shared-hosting providers, because the attacks let one user read another user's data.

The fix to Meltdown will slow things down by 5% to 30% (depending on your CPU and what you're doing); computer games appear to be at the 5% end of things.  There is no general-purpose fix to Spectre, but it's also much harder and slower to exploit than Meltdown.


Is there a way to "lock" a YubiKey after a period of inactivity? I have a YubiKey 5c nano attached to my laptop used for 2FA, etc. It works great and is unobtrusive, but I feel like the small form factor encourages leaving it plugged into the laptop all the time, essentially weakening the two-factor nature of they key... or effectively making my laptop the second factor.

I have Yubico Authenticator set to protect the Yubikey with a password so that if my laptop were stolen, the Yubikey is unusable without the password. But once the password is entered, the Yubikey is usable until unplugged (or the machine is shut down) and I am worried that I may forget to unplug the Yubikey before traveling.

Is there any way to "lock" a Yubikey and require the password after some period of inactivity, or via a CLI-interface? I'm on Mac OS X and could write a shell script, but an OS-angnostic answer would be more useful to the community.

Understanding @Joseph's point, I was still concerned...

I discovered that actually, simply quitting the Yubico Authenticator GUI will require the password set on the OATH applet when it's relaunched. It appears to store the OATH application password in memory, because ykman oath code asks for the password every time it's run.

Given this, it was very simple to create a small cron job which runs every minute, checks the idle time on the GUI and runs killall yubioath-desktop 2> /dev/null is the idle time is greater than a configured value.

This provides what I was looking for.


How could a third-party know the contents of an email I sent to someone? Apparently, a third party knew the contents of an email I sent to someone within an hour after I sent it. The following possibilities come into mind:

The recipient forwarded the email to the third party. (I doubt this though as the email was sent to a business address on a non-business day.)
The third party has access to the recipient's account.
The third party has access to my email account.

Are there other possibilities I have failed to consider? How would I check those possibilities?

I was only able to check the possibility that the third party has access to my email account. Unfortunately the incident happened some time ago, and it seems to me there's no way to get your logged in IP addresses from Gmail after some time. So my only recourse is to change my current password to something stronger.

Thanks in advance.

There are multiple additional ways:

The message was not encrypted, and somebody captured it during transmission (as pointed out by Gumbo)
The client is compromised and has some sort of malware that reads keystrokes, intercept emails, ...
The recipient is compromised
Any "mail relay" in between is compromised
The recipient indeed did forward the mail, or the recipient address is an alias which delivers the mail to a number of users, who each might have forwarded the mail or be compromised.


What are the areas to focus on to protect users and devices? What are the areas or technologies to focus on to protect users and devices?

Are patching, antivirus and firewalls still the main areas?

How do you defend against attacks against vulnerabilities that have no patch?

User education & training is huge.  Get the users to help you play good defense.

I always like to see the security programs that award spot bonuses to employees for challenging a person in a secured area without a badge.  You can be creative and extend this idea to phishing attacks, pretexting, etc; for example, send out a mock phishing attack and reward employees for calling it out and not falling for it.

Keeping up to date on patches is key - Secunia Personal Software Inspector rocks.


Is email OTP improving the security for 2 phase authentication? There has been similar questions before where people say that using some other means (sms, hardware devices, etc.) is a more secure way to provide 2 factor authentication. Provided we don't have an option to do it this way, will a simple email OTP improve the security nontheless compared to just username/password? Is it possible that it might weaken it somehow on the other hand?

The flow is like that:

User enters a username/password, and hits log on
User receives an email with an OTP which he puts in the field that is visible after completion of point 1
If the user does point number 2 within 5 minutes after completing point number 1, he is logged on (in other words OTP expiration is 5 minutes).

OTP is a simple 6 upper case symbols string like that: ARKOGD

This is essentially the scheme that Steam uses if you log in from an "unknown" device.

It increases the security slightly, as an attacker would need to compromise both the username/password combination for the application, and the email account of the user. This effectively makes non-targeted attacks worthless.

This could be argued as a bad thing - if the system does not also incorporate the standard protections against brute force attacks, it would be relatively easy to try lists of potential usernames and common passwords, looking for the second login screen to appear, then specifically target those users. The users may well assume that since they've not attempted to log in, the email must be a mistake, and hence not realise that they may be coming under attack.

It also doesn't work well for some circumstances, such as for a mobile application. Many people nowadays receive email to their phones, so an attacker who had access to the mobile device may well be able to log in without further effort. This is no different from an SMS token though.

There is also a slight usability impact, especially for users who may not be highly skilled with web browsing. In some cases, switching between a login form and email client (even if in another tab) may cause issues, resulting in frustration with the site. This is probably why Steam only uses this method for "new" devices (or at least, ones where cookies are disabled, which in turn suggests a reasonable level of security awareness).


Loopback with Suricata Is there any way of analyzing loopback traffic with Suricata?

I am trying it this way without success:

root@security-onion:/home/sar/TFM/alerts/suricata# suricata -c /etc/suricata/suricata.yaml -i lo -l . -k none
7/9/2018 -- 19:32:25 - <Notice> - This is Suricata version 4.0.5 RELEASE
7/9/2018 -- 19:32:29 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'lo': Operation not supported (95)
7/9/2018 -- 19:32:29 - <Notice> - all 2 packet processing threads, 4 management threads initialized, engine started.
7/9/2018 -- 19:32:29 - <Error> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Frame size bigger than block size
7/9/2018 -- 19:32:29 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't init AF_PACKET socket, fatal error
7/9/2018 -- 19:32:29 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - thread W#01-lo failed

This is the suricata configuration file: suricata.yaml

Any hint?

If you wanna run in Pcap live mode then you should turn-ff AF_PACKET mode from suricata configuration file: suricata.yaml.

# Linux high speed capture support
af-packet:
  - interface: lo

you got error because of af-packet packet capturing mode, probably not configure properly.

7/9/2018 -- 19:32:29 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't init AF_PACKET socket, fatal error


Secure Boot - Verifying applications I have been reading up on Secure Boot, in particular what it actually checks during the boot process.

According to Microsoft the Secure Boot process works as follows:

Firmware Boot Components: The firmware verifies the OS loader is trusted
Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each
    component. Any non-trusted components will not be loaded and instead
    will trigger Secure Boot remediation.

Antivirus and Antimalware Software initialization: This software is checked for a special signature issued by Microsoft verifying that it is a trusted boot critical driver, and will launch early in the boot process.

Boot Critical Driver initialization: The signatures on all Boot-critical drivers are checked as part of Secure Boot verification in WinLoad.
Additional OS Initialization
Windows Logon Screen

From this I have understood that Secure Boot will only check the firmware (bootloader, EFI applications, OS integrity).

But would it be possible to have the secure boot process also verify the integrity of the OS applications from tampering as well? I.e some user applications that run on Windows e.g paint etc.

If you do the whole signing process of a user application you want to have its integrity checked, and add it's public key to the Secure Boot whitelist database,  would it actually check the user application's integrity? I searched online but I could not find a definite list of what exactly Secure Boot checks for.

UEFI firmware launches the Windows bootloader when it has been correctly verified (it's been signed by one of the entities your firmware trusts). Once on the Win bootstrap, there is a module that verifies code integrity of every module in the kernel. All the drivers/modules that are not signed or signed by an entity not included in the code integrity db are simply rejected and the boot process will fail warning the end-user.

Now, you can override that policy to even load unsigned drivers. OK, but what about user delivered apps/programs? Well there exists something called code integrity where a developer signs his software including a timestamp, so if the certificate expires somehow, that timestamp validates the signature. It's a security matter that entirely depends on you, you are exposing yourself installing unverifiable software, so be sure that the source is reliable when code signing is not included.

I'm not an active Win user right now but I'd say that most of the shipped software included in any modern Windows OS is directly signed by Microsoft following the code integrity specs. Look also for signature catalogs, it's very instructive. Now, if you were a Linux user, software downloaded from official repos is guaranteed to be signed so signatures can be validated with pgp keys of the repo, there have been cases of compromising the official repositories, so danger it's still out here for us all.


How can I properly secure the WiFi setup process of an IoT device? My company develops a WiFi-connected IoT product. I want to make sure that the process of getting the user's WiFi credentials into the device is as safe as possible. At the moment, the product is in a prototype stage, so we can (and will) make further changes before it hits the market.

At the moment, the process is as follows:

The device creates its own WiFi hotspot. The credentials for this hotspot are printed onto a label on the device itself.
The user visits a certain URL (a web page served by an embedded web server on the product, using plain HTTP)
The user enters his WiFi credentials into a form on that page
The device saves those credentials and uses them to connect to the user's WiFi

Several guys in the company think that this is secure. An attacker would need to get into the hotspot to sniff on the user's WiFi credentials.

I disagree since I think that getting into the WiFi is a pretty low hurdle. The attacker could have glanced at the credentials on the label during a visit, brute-forced his way into the WiFi hotspot or exploited a weakness in the WiFi hotspot authentication (not unheard of). I suggest to change the process to look as follows:

The company creates a self-signed SSL root certificate.
We use this root cert to sign individual certificates unique to each product sold. The product's certificate and private key is embedded in flash memory during manufacturing.
The user goes to our website and downloads our root certificate and installs it into his operating system.
The device creates its own WiFi hotspot. The credentials for this hotspot are printed onto a label on the device itself.
The user visits a certain URL (a web page served by an embedded web server on the product, using HTTPS and the device's unique certificate. The browser trusts the certificate because our root cert is installed.)
The user enters his WiFi credentials into a form on that page. The information is sent to the device over the TLS-encrypted channel.
The device saves those credentials and uses them to connect to the user's WiFi

I think that this process is very secure. But it imposes other problems:

How can we update a device's certificate? Possible, but very cumbersome and a lot of effort.
The user has to manually install a certificate. This is not very user-friendly and less tech-savvy users may fail to do it correctly even if we provide very detailed instructions.

My question(s):

Is the suggested process secure enough for an IoT product (imagine it as some kind of smart energy meter measuring your electricity consumption)?
Is there any way to improve the user experience of the process (e.g. getting around the need to install our certificate)?
Is there any way to improve the process in terms of implementation complexity for us (without compromising the user's security)?
Are there alternative ways to get the WiFi credentials onto our device? We cannot use Bluetooth and the device has neither screen nor keyboard.

Answering this question reminds me about the one I answered in regards to security on fire safety products.

Security is only as good as the weakest link. In this case it's the end user.

Asking end users to install root certificates is not only begging to raise questions (are you or your company even reputable enough to be a CA?), but will prove a waste of time if a user somehow works their way through things. You will need to update certs over time, or maybe even revoke one, the sky is the limit, and building a PKI is out of scope for a project like this.

Technologies such as WPS and Bluetooth pairing prove that easy is generally better suited for security in a wider audience. While WPS suffers from problems, it doesn't really matter as most WiFi routers come flashed with ISP branding and horrible default credentials based on serial numbers. Mine even offers a no way to disable "password recovery" feature, because storing plain-text passwords is never a bad idea right...

Local attacks aren't really prevented anyways, because who would honestly break into your house (a criminal offense), to tamper with a device for free WiFi (potentially another criminal offense), when they could commit more profitable criminal offenses like photographing your credit card(s)?

The initial scenario seems suitable, given that the hotspot only remains "on" for a limited time period, and times out when nothing is setup. Pushing the button on the device starts the "setup" phase again.

If you are interested in other ("exotic") solutions:

I've had fun with "key loaders" used in military or police radios before. Potentially adapt this idea with a USB key that holds WiFi setup info that erases after loading the info?
Generate a one time password, display it on the device for 60 seconds, and then require a device wipe to change device settings or pair the device again.
If this is going to be used in a commercial setting, pairing via bluetooth and then using an app to setup may be good idea.
If you want a more "high-tech" approach, use an app that transmits information to the device via NFC after a button on the device is pushed. Marketing departments really love buzz words like NFC.
Do as the fancy store payment terminals do. Include features like proprietary interfaces/standards and pressure sensitive switches that clear keys in volatile memory.
Assuming certificate based WiFi, you could load certs onto a YubiKey, and have a user place the Yubikey on the device. Have the key do all the crypto, and private key extraction would prove difficult to most attackers. Charge $$$ for including a "FIPS" model, because again marketing departments like buzzwords.

In the end, security is only good if it is usable. Keep that in mind for your end users.


What are the features of Dual EC DRBG that are lost when using a different cipher? Due to a potential NSA backdoor, the NIST is now recommending that implementor no longer use ECC-based PRNG Dual EC DRBG.

(As described in Wired.com) this PRNG has certain features such as:

continuous testing of output
prediction resistance
re-seeding
... possibly others

Question

Now that other PRNGs will be used, not all of them will offer the same feature set. What are the features we'll be missing, or be "weaker" in any sense of the word?
What do these features mean?  Why are they useful? (continuous testing for example)

You can assume for my question / threat model that the NSA is not my adversary, however I do want to prevent other capable attackers from compromising the integrity or effectiveness of my encryption.

A PRNG which lacks reseeding, prediction resistance, or whatever these people mean by "continuous testing", is not a PRNG. Not in cryptographic terms.

Conversely, a good PRNG, like HMAC_DRBG, will be as good as Dual_EC_DRBG, actually better since Dual_EC_DRBG exhibits measurable biases, and is awfully slow. The only good point of Dual_EC_DRBG is the potential for a security proof which would demonstrate that the output is as random as a given number-theoretic problem is hard; but no such proof is known yet...

Here, by Dual_EC_DRBG, I mean a fixed Dual_EC_DRBG, with the two "random" points replaced by two points really generated randomly, not with the probable backdoor of the two standard points. But even "fixed", it would still be slow and biased.

The article you link to quotes the chief technical officer from RSA Security, who lists some advantages of Dual_EC_DRBG over "other algorithms". Without stating which algorithms Dual_EC_DRBG is compared with, these statements are vacuous. NIST themselves would feel quite offended at the suggestion that Hash_DRBG and HMAC_DRBG don't have the same features.


Can a VPN server be traced through Tor? I was wondering that if my data was intercepted by Tor by an exit node, would they be able to see which VPN server is being used to encrypt the data.
I am asking because I planned on making an OpenVPN Server and using it with Tor

No, the exit relay does not know your VPN IP.

It might be helpful to understand how Tor works. A diagram from the EFF explains it well:

As you can see, the third relay, the exit, can only see the site you are visiting and, if you are not using HTTPS, the traffic to the site itself. The exit does not know your IP. In fact, it does not even know the IP of the first relay (the guard) that you are connecting to. Tor works because no one relay can simultaneously know both who you are, and who you are connecting to. When you use a VPN before Tor, what you are doing is effectively changing your public IP from that of your ISP to that of your VPN. An exit relay whose traffic has been intercepted will not be able to know your VPN IP any more than it would be able to know your public IP were you not using a VPN.

It is important to remember that most of the times Tor has failed people were a result of either operational mistakes or browser exploits. While Tor is very good at hiding the origin of internet traffic, a vulnerability in the browser could be utilized to bypass Tor, revealing your VPN IP or even your real IP. The best way to avoid browser exploits is to keep Tor Browser up to date, and to set the security slider as high is practical. If you want even further guarantees, use Tails.


Is it normal for shell scripts to contain binary data? I ask because I've been looking into Miniconda (https://repo.anaconda.com/miniconda/Miniconda3-py39_4.9.2-Linux-x86_64.sh), and the installation shell script has TONS of binary data starting at line 577.
I ended up checking the shell script because Google Chrome flagged it as potential harmful. I know, it's just Google Chrome, and any shell script may harm your computer, however the binary data starting at line 577 kinda scared me a little... if it's not normal for installation shell scripts to contain a binary payload like that, then there's no way I'm installing it.
But if it's normal, then I'll feel much better about installing Miniconda.

It's normal-ish; such a file is often called a 'sharball' (shell script + tarball).  It's a way to send files (the tarball) and the method for extracting and manipulating them (the shell script) together in a single easily distributed file.
As to whether it's safe to run, that's a question you should ask with any shell script you're asked to run, not just those with binary content.  It boils down largely to trust in the distributor of the file.


SAML token and service calls I am working on a tablet application and have come across an interesting issue.

We have a domain joined tablet that runs a Windows Store Application. We already have user identity and we need to call a web service endpoint that is secured with SAML.

Do I need to hit IDP to get a SAML token and pass that with my web service calls? Or would an identity object be enough to get my callers identity context?

The web service is a SAP service, that only accepts SAML.

It doesn't matter that you have the identity unless you are a trusted idp for the service that's protecting its resource with SAML. That said, if you have a SAML response from an idp that the service trusts, then you should be able to post that to them as an sso token.


Automatically insertion of 00 in EIP in Stack Overflow 64bit I am trying to overflow a stack in C sample code to execute uncalled function in code.
The problem is when i overflow stack by entering a(24 times), $EIP is 0x555555550061. I want it to be 0x555555555561. Why these two zeros are inserted automatically?
I retrieved this values from gdb. For Instance, if that uncalled function address is 0x555555555561, I can not call that function because of these zeros.
I tried using:
./(name of executable) $(cat input.txt)    #input.txt has input string 24 times a with no '\n'
but same problem.
I am running 5.5.0-kali2-amd64.

The null byte is almost certainly from the end of your a filled string. if you're not trying for a partial overwrite the more common approach would be to send more characters and overwrite all of EIP with 0x61616161.... You can then alter the overwrite bytes to any value you want, including 0x555555555561.


Why is Google still using a sha1 certificate on its own site when they are phasing them out in Chrome? Firefox dev tools shows that https://www.google.com is using a certificate signed with SHA1. Why is Google doing this when they are phasing out the certificate themselves?

Shouldn't this only hurt Google's reputation and interests?

This may be a case of "do what I say, not what I do". Note that Chrome complains about use of SHA-1 for signing certificates whose validity extends beyond the end of year 2015. In this case, Google's certificate is short-lived (right now, the certificate they use was issued on June 3rd, 2015, and will expire on August 31st, 2015) and thus evades Chrome's vengeful anathema on SHA-1.

Using short-lived certificates is a good idea, because it allows for a lot of flexibility. For instance, Google can get away with using SHA-1 (despite Chrome's rigorous stance) because the algorithms used to guarantee the integrity of a certificate do not need to be robust beyond the certificate expiration; thus, they can use SHA-1 for certificates that live for three months as long as they believe that they will get at least a three-month prior notice when browsers decide that SHA-1 is definitely and definitively a tool of the Demon, to be shot on sight.

My guess as to why they still use SHA-1 is that they want to interoperate with some existing systems and browsers that do not support SHA-256 yet. Apart from pre-SP3 Windows XP systems (that should be taken off the Internet ASAP), one may expect that there still linger a number of existing firewalls and other intrusion detection systems that have trouble with SHA-256. By using a SHA-256-powered certificate, Google would incur the risk of making their site "broken" for some customers -- not by Google's fault, but customers are not always fair in their imprecations.

So Google's strategy would appear to be the following:

They configure Chrome to scream and wail when it sees a SHA-1 certificate that extends into 2016 or later.
Because of all the scary warnings, users of existing SSL servers (not Google's) begin to desert (e.g. they don't complete their online banking transactions, because they are afraid), forcing the server administrators to buy SHA-256 certificates.
Now these new certificates "break" these sites in the eyes of the poor people that must live with outdated browsers or firewalls. This ought to force people to upgrade these browsers and firewalls.
Meanwhile, Google's reputation is unscathed, because their site never trigger any warning or broke an old firewall -- since it still uses SHA-1 !
When the whole World has switched to SHA-256, and all firewalls have been updated, the path becomes clear for Google, and they can use SHA-256 for their new certificates.

It is a pretty smart (and somewhat evil) strategy, if they can pull it off (and, Google being Google, I believe they can).


How to get an internal network address range during a footprinting stage? As new to pen testing, I am a bit stuck at finding out a local network address range from external network to perform a pen testing. I will give you a fake scenario with fake IP addresses as below.

Company name: www.testme.com
IP: 125.124.123.122
Name server: main.testme.com
Name server IP: 150.149.148.147

main.testme.com is our main office where all our employees are with our internal network address range is 172.160.0.0/24

During a footprinting stage, how, if possible, do I extract 172.160.0.0/24 address range? Whois, nslookup, dnsenum, Netcraft, or other methods don't seem to get me that far unless I was doing something wrong.

Any help is very much appreciated.

Like most other businesses in the world, this target network is likely using Port Address Translation (PAT aka "overloaded NAT") whereby internal addresses get translated into the public IP (or an IP from the public pool) on egress into the Internet when making connections.  This means that the private space (172.160.0.0/24) is used on the local LAN inside the company network, but any communications to/from the Internet use the public IP (125.124.123.122).  Usually, you are unable to tell what the internal space is from the outside.  Even guessing won't get you anywhere, since the firewall will block unwarranted requests from the Internet to 172.160.0.0/24 on the external interface.

There have been known some information leakage vulnerabilities that expose private internal address space:

I personally found internal address space addresses among HeartBleed audits performed against a friend's external-facing web server.  Memory leaks can expose private information like this, especially from servers in a company's DMZ that also talk inbound (many companies allow MS domain traffic to/from DMZ to LAN for management purposes).
Emails from the Exchange server within your target network will stamp each SMTP message with 'message headers' that include the LAN IPs and hostnames of any internal Exchange servers the message was processed by on its way out of the target organization.  It's possible for a company to scrub these, but most don't, and RFC 2821 says you shouldn't.  More info on that here.
There are common ways to misconfigure DNS to expose private internal addresses.  Here is an example.
If you can be on the same network as an asset from the target network elsewhere (Bob from Victim Corp. is on the same WiFi as you in a coffee shop), you can possibly sniff the traffic for RARP, SMB, and other requests that leak this info in hopes that (A) Bob is using a company VPN, and (B) the VPN client is configured for split tunneling, which is relatively common.

If you have physical access to/near the victim network, however, there are far easier ways to obtain this data from plugging into a conference room port, cracking the WiFi, etc.  You could even spear phish with malware designed to perform some network reconnaissance and exfiltrate back to your server if you feel someone will open your malicious email attachment (hint: they always do).  Otherwise, NAT/PAT prevails and there is no standard or common way to reveal the internal IP range.


Is accessing carelessly not protected data of any service unlawfull? The following scenario: I just visited the webpage of an phisshing company of an german service which is here in germany acting at least not unlawfull, but just trying to get money for not even giving something usefull.

After surfing a bit I filled a formular which just gave me a php created response with a lot of paths of the page. The paths aren't protected and contain stuff like sql databases and a lot of other stuff they probablly don't want to be as accessable as it currently is.

Could I get in trouble with law by just accessing the data?
Or is it all there carelessness?

What makes me think I could get in trouble: The content appears to be not directly accessable through any Protocoll supported links, so wihtout the php bug they seemingly have I wouldn't know about the directorys.
And it is probably sensitive data of some users or other stuff, which in generell is treat pretty hot here in germany.

What makes me think its not my problem:

It is just a url without any verification process so how I could even know its not made to be accessed by me, if I had not the technicall knowledge I actually have.
And the hoster of the page is absolutly not even trying to protect this data.
Or even if he is, it is careless anyway, as the database is stored on something like www.domain.tld/conf/sql.

(Speaking from 5 years old info gotten by searching internet piracy laws)

In France, the laws state that unauthorised access is illegal, and more interestingly maintaining unauthorized access is as much illegal as getting it.

Analysis of those laws, in French

I am not aware of the rest of the world's laws, but it seems it is indeed unlawful, as it is trivial to show these data were not intended for your use, making your access unauthorized thus illegal (however well intentioned you might be)

The fact that it is a bug / error that you exploit might be used against you rather than being in your favour, I can't imagine any case where it might be otherwise (since any intrusion is based on bug/error / edge case of security policy)


What threats are posed by SSL connections? I'm working on implementing an Exchange 2010 solutions which includes Outlook Web Access, Exchange ActiveSync and Outlook Anywhere. These services use SSL and would be presented on the Internet so our users can access them externally. I'd obviously need to protect the server (CAS role) that these services operate on. My question is what threats are posed by SSL connections? If I were just to do a port forward on the SSL connection directly to the OWA and EAS server what risks are there? Do I need to do IDP on the encrypted traffic? Thanks

If your intrusion detection system sees anything worth reporting while looking at a SSL connection, then it is not SSL, or is very poorly implemented. By construction, SSL is meant to provide a tunnel for confidential data, i.e. it is very opaque from the outside.

Generally speaking, SSL is not a threat, it is a protection measure against threats. In particular, it prevents evil attackers from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

Some sysadmins get nervous in the presence of SSL because it prevents them from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

The external services of Exchange are designed to be exposed to the public at large, which is why they use SSL by default, as they should be.


Can my employer see what I do on the internet when I am connected to the company network? This is an attempt at a canonical question following this discussion on Meta. The aim is to produce basic answers that can be understood by the general audience.

Let's say I browse the web and use different apps while connected to the network at work. Can my employer (who controls the network) see what websites I visit, what emails I send, my IM messages, what Spotify songs I listen to, etc? What are they able to see?

Does it matter if I use my own computer, or one provided for me by my employer? Does it matter what programs I use, or what websites I visit?

Yes. Always assume yes.
Even if you are not sure, always assume yes. Even if you are sure, they might have a contract with the ISP, a rogue admin who installed a packetlogger, a video camera that catches your screen... yes.
Everything you do at the workplace is visible to everyone. Especially everything you do on digital media. Especially personal things. Especially things you would not want them to see.
One of the basic rules of Information Security is that whoever has physical access to the machine, has the machine. Your employer has physical access to everything: the machine, the network, the infrastructure. He can add and change policies, install certificates, play man in the middle. Even websites with 'SSL' can be intercepted. There are plenty of valid reasons for this, mostly related to their own network security (antivirus, logging, prohibiting access to certain sites or functionalities).
Even if you get lucky and they cannot see the contents of your messages, they might still be able to see a lot of other things: how many connections you made, to which sites, how much data you sent, at what times... even when using your own device, even using a secure connection, network logs can be pretty revealing.
Please, when you are at work, or using a work computer, or even using your own computer on the company network: always assume everything you do can be seen by your employer.


How protect mobile website against encapsulating into rogue native mobile app? We are developping a mobile application (m.website.com).

Is there a way to prevent a rogue developper to build an IOS / Android native app that simply encapsulate our website into the app using Webkit to perform UI Redress attacks or clickjacking ?

(We know that the HTTP header "X-Frame-Options: Sameorigin" is effective in the scenario of a malicious website that encapsulate (frame) another website, but how to prevent encapsulation by a native mobile app ?)

A user cannot trust a web page that is inside an app that they don't trust.

Therefore, if there was a UI redress attack against your website when using a particular app, then this would be the user's fault for trusting the application.

Furthermore, if an application developer wanted users to click something on your site using the phone, then they would simply code this into their application. They would not need the user to do it. Browsers within applications use a different set of cookies than the phone browser, so this would not affect any of the user's existing sessions. They would have had to log onto your site in the application's browser window, and at that point a rogue application could simply have harvested the credentials anyway.


Are offline OTP systems really secure? I know that OTP (One-time password) system is the most secure method for now if online.
Online OTP systems, like sending code to a phone is secure because the attacker cannot know the code if he doesn't have the phone or can intercept the content of the message.
However, offline OTP looks not secure, because it doesn't need a network connection. The server and client should share the same algorithm to create the code. Maybe they use some public key that shared between server and client and timestamp.
It's not so different from using just a password. If the attacker knows the public key, he can use the key with the algorithm and make the same OTP code with his local system.
I'm not sure the offline OTP system is secured. How do you think about it?

Online OTP systems, like sending code to a phone is secure because the attacker cannot know the code if he doesn't have the phone or can intercept the content of the message.

And intercepting the message is easier than stealing a physical device. It can be done from another country, in a massive scale.
SMS, for example, can be easily hijacked, either by SIM swapping, or by using SMS re-routing systems. There are lots of applications that monitor SMS on the phone and send it somewhere else.
Email isn't any better. If the attacker manages to control any router in the email route, any message coming by that router can be intercepted. Unless the email content is encrypted, they can be read.
But what about STARTTLS? Sadly, it's more for show than anything. The initial exchange on the SMTP conversation is on clear, and if the server advertises he supports TLS but the client does not accept, the entire exchange is on clear. If the server provides a mismatched certificate, the exchange continues as normal:

TLS is intended to ‘fail open’ in the event of send failure, rather than ‘failing safe’ (whereby if errors occur, the email fails to send at all). Thus in the event of failure, TLS falls back to regular SMTP and messages are sent in clear text.

However, offline OTP looks not secure, because it doesn't need a network connection.

Quite the opposite. Without network connection, an attack cannot be made on a large scale. Hacking the SMTP server of a regional ISP means an attacker can steal any online OTP code from email. But stealing offline OTP codes means hiring a horde of thieves stealing phones from people.

It's not so different from using just a password. If the attacker knows the public key, he can use the key with the algorithm and make the same OTP code with his local system.

It's way different from a password. The vast majority of passwords are easy to break. For example, researchers cracked more than 11 million passwords on the infamous Ashley Madison leak. A paper on leaked passwords shows that lots and lots of people reuse passwords, so one leak can compromise several other accounts for the same person.
OTP is created by the system, not the user. This guarantees way more entropy than a password. And if an attacker steals both the bcrypt hashes and OTP shared secret of your account at Gmail, it will do nothing to help break Facebook, for example, if both are using OTP.

I'm not sure the offline OTP system is secured.

It is. Way more than a password. You should get a password manager, and enable OTP on every single service you use, and let the password manager generate all passwords for you.


Why isn't sophisticated malware written with .NET? I've been trying to research malware techniques lately, as malware analysis intrigues me. I've got a pretty heavy background in .NET, and based on my more than seven years experience in .NET, I feel that I could write a pretty complex piece of malware rather quickly if I was so inclined. Everything that I've seen suggests that malware written in .NET is for the "simple" or "unsophisticated" pieces of malware, why is that?

Obviously, I understand the differences between .NET and C/C++ in regards to the low level stuff. I also understand that .NET is much more easily reversible than C/C++, but still, I would think the benefit outweighs the cost here. Isn't it much quicker to write malware using .NET than C/C++?  Especially now that all Windows 7 PCs ship with the .NET framework already installed.

Other than the "low level stuff", is there a reason that malware authors avoid .NET and use C/C++ instead that I'm not aware of? Why does it appear that in the underground "hacker" forums, everybody despises .NET?

For example, if I wanted to make a program that regularly checked a Twitter account for new commands to execute, I could easily do this in about an hour in .NET and just a few lines of code. In C/C++, this would be a lot more work, no?

There is plenty of malware out there that is written in .NET, but as a C# dev I can see why many malware authors avoid it:

Easy to disassemble and reverse engineer.
Easy for AV to detect use of certain classes and functions.
Requires .NET on the box (older XP boxes might not have it, or might only have .NET 2.0)
Harder to do anti-debug tricks in .NET than in native code.
Executables are often larger than native.


Make Files Encrypted As They Download Is it possible to encrypt a file as it downloads?  Security is #1 concern, so what I am after is a way that once the file is completely downloaded and moved to an encrypted drive (not directly downloading to encrypted drive due to security) the file will be irrecoverable on the system it was downloaded on due to the encryption.

Is this possible in Ubuntu?

To encrypt a file as it gets downloaded, store it in an encrypted drive.

The requirement “not directly downloading to encrypted drive due to security” is meaningless since downloading to an encrypted drive is not a security risk. It needs to be either clarified or ignored.

If there is a requirement not to download directly to a certain location because that location should only contain valid, complete files, then download to a different directory on the same encrypted drive first, then validate the fully downloaded file, and if valid move the file to the final location. In this scenario, the intermediate staging location on the encrypted drive is necessary anyway because if the intermediate staging location was outside the drive then it would be impossible to guarantee that the final location only contained valid files, since during a copy it would contain a partial file.

If there is a requirement that files that are being downloaded but not validated do not risk filling the encrypted drive, then apply a size limit to the download.


is RDP7.0 authentication process secure enough? Latest version RDP used NLA, CredSSP and TLS to secure the authentication process. It sound like secure but in reality does it really secure enough. I knew that the previous version RDP is vulnerability to man-in-middle attacks, does this attack being eliminated?

Recent versions of RDP support SSL/TLS. RDP itself has its own format for transferring data packets; within these packets, recent enough clients and servers can transport the TLS records which will encode a tunnel into which the actual data will be sent (including authentication). This is reasonably secure, insofar as the client and server do not botch the implementation or misuse the certificates (see this answer for some discussion on the subject).

Also, TLS usage is optional and subject to negotiation between client and server; conceivably, an attacker trying a man-in-the-middle attack could alter the first packets so as to simulate a lack of TLS support on both sides, leading to a connection without TLS. It is up to the client implementation to detect this occurrence and abort the connection (or raise a warning and let the user abort).

TLS support was added in RDP 5.2. Free opensource implementations of the RDP protocol usually do not support it.

Another way to TLS-protect a RDP session is the Remote Desktop Gateway (formerly known as Terminal Services Gateway) which encapsulates the whole thing into an SSL/TLS tunnel. This is cumulative with other features of RDP, so you can end up with TLS-in-RDP-in-TLS. The gateway is a specific service available from Windows Server 2008, and only Microsoft's client appears to support it (according to Wikipedia, not even the MacOS port of Microsoft's client can use it).


Are there secure alternatives to single-use password reset links? We currently have what I believe to be a pretty standard scheme for dealing with password resets. Our reset links are single-use links: They expire immediately after they've been visited, even if the user doesn't actually reset their password.

However, our customers are predominately (99%) businesses with aggressive spam filtering. In particular, some of our biggest customers (school districts) have a spam filters in place that perform link-scanning. They visit [up to N] links in an email as part their algorithms. When users request a password reset, the links are "expired" by the spam filter's visit before the user sees them.

Are there any alternatives to the single-use link that are equally secure? Or that are secure enough to fall within the realm of acceptable practices?

We also need to consider usability. Our customers are generally about as non-technical as you can get. So ideally, the password reset procedure won't become [much] more complicated for the user.

Here's what we've thought of so far:

Store the reset token in the session. The link would remain active while the original browser session is open and/or the password hasn't actually been reset. It may complicate the process for users who use two different devices for their email and browsing (e.g., email on phone + laptop for browsing).
Expire the link after N minutes. I think I've seen this. But, I don't know what time limit is an acceptable balance between usable and secure.
Expire the link only after the form is submitted. Some users may visit the link, putting it into a browser history, but never submit the form. Is that an acceptable level of risk?

As always, you have to consider the value of the asset you're attempting to protect in order to properly assess if a security procedure is adequate or not. Typically, you'll be willing to accept lower usability when the value of your asset is high.

This means that it's impossible for anyone than yourself to estimate whether a given solution is secure enough.

That being said, a simple way to solve your issue is not to have your links expire immediately but have them expire after a period of time OR when the password has been reset (whichever comes first).

In order to decide whether this is secure enough for you, and assuming you're satisfied current setup, you will need to consider the following changes:

The same link can now be reused several time. This potentially weaken the security of the system.

However, you are currently working on an assumption that is incorrect: the first person to visit a link is the legitimate user. It's clearly not the case (as you've noticed). The consequence is that you're not really increasing the overall security by having the link expire immediately after first access.

So, in my opinion, changing the way your access token expires seems like a better solution: you're increasing usability without impacting the overall system security.

You might, however, consider including some second-level validation in the page you land in when using your reset link. Something that will somehow improve your confidence the user identity (typically, a "security question" is used although that model is not very good).