What is the method used in the New York Times attack? In the recent New York Times attacks, how did the attackers gain access to the server?

Additionally, is there any evidence that these attacks were launched by China, aside from the proxy?

The article you linked to gives as much information as is publicly known. So I'll just quote from there:

  Investigators still do not know how hackers initially broke into The Times’s systems. They suspect the hackers used a so-called spear-phishing attack, in which they send e-mails to employees that contain malicious links or attachments. All it takes is one click on the e-mail by an employee for hackers to install “remote access tools” — or RATs.

And also:

  The malware was identified by computer security experts as a specific strain associated with computer attacks originating in China.

Which means that this isn't software you're going to find on metasploit. It's something custom that they built.

  They set up at least three back doors into users’ machines that they used as a digital base camp. From there they snooped around The Times’s systems for at least two weeks before they identified the domain controller that contains user names and hashed, or scrambled, passwords for every Times employee.

So, 3 employees workstations compromised with RATs (probably via email spear phishing) leveraged to gain access to the domain controller.

  While hashes make hackers’ break-ins more difficult, hashed passwords can easily be cracked using so-called rainbow tables — readily available databases of hash values for nearly every alphanumeric character combination, up to a certain length.

Active Directory is known to use unsalted hashes for password storage. There are several methods AD uses for hashing passwords, none of them very secure ... except perhaps as compared to the previous ways Microsoft hashed passwords. Their security is based primarily on the assumption that Windows access controls will prevent the attacker from retrieving the hashes. But if the attacker uses a targeted phishing attack to compromise the workstation of someone who has the necessary access, then AD won't put up much further resistance, and the attacker can then learn everyone's password.

After cracking the passwords stored in AD, the attackers then have the necessary credentials to do whatever they want to do. In this case, read email.


Is this "security update" from security-update@amazon.com an advanced phishing scam or a real security measure from Amazon? I just got either a helpful security update from Amazon or an advanced phishing attempt by an Amazon impersonator falsifying the email origin. The title is "Your Amazon password has been changed".

There seem to be mixed claims about the validity of this online. One of the articles I'll cite mentions that in his version of this email, each mention of "Amazon.com" is formatted as a link. The article doesn't mention verifying the target of the link and unfortunately (or fortunately) my email client (Yahoo mail) seems to have removed this link from the text, perhaps to combat such phishing attempts.

I'm not worried about being in danger myself, but I thought it would be good to create this question for people searching Google about this email today to learn about the validity of it or lack thereof.

The email reads:

  Hello,

  At Amazon we take your security and privacy very seriously. As part of
  our routine monitoring, we discovered a list of email addresses and
  passwords posted online. While the list was not Amazon-related, we
  know that many customers reuse their passwords on multiple websites.
  Since we believe your email addresses and passwords were on the list,
  we have assigned a temporary password to your Amazon.com account out
  of an abundance of caution.

  You will need to reset your password when you return to the Amazon.com
  site. To reset your password, click "Your Account" at the top of any
  page on Amazon.com. On the Sign In page, click the "Forgot your
  password?" link to reach the Amazon.com Password Assistance page.
  After you enter your email or mobile phone number, you will receive an
  email containing a personalized link. Click the link from the email
  and follow the directions provided.

  Your new password will be effective immediately. We recommend that you
  choose a password that you have never used with any website.

  You can also enable Amazon's Two-Step Verification, a feature that
  adds an extra layer of security to your account. In addition to
  entering your password, Two-Step Verification requires you to enter a
  unique security code during sign in. To learn more about Two-Step
  Verification, go to Amazon.com Help, go to Managing Your Account, and
  click More in Managing Your Account, and then click More under Account
  Settings.

  Sincerely,

  Amazon.com http://www.amazon.com

  This e-mail was sent from an address that cannot accept incoming
  e-mail. To contact us, please visit the Help section of our website.

A quick Google search of the first paragraph returns one article claiming the email is a valid security measure from Amazon, while the other claims it to be a phishing scam.  Which is it?

One comment reports they contacted Amazon about the email and received this response:

  Hello,

  The e-mail/SMS message you received wasn't from Amazon.com. For your
  protection, do not respond to it, and do not open any attachments or
  click any links it contains.

  We recommend that you send a new e-mail/SMS message and attach the
  e-mail/screenshot of the message you suspect is a fake, then send the
  e-mail to stop-spoofing@amazon.com.

However another comment claims:

  My wife got this email also. I contacted amazon through my account and
  we were able to confirm that this was indeed really from amazon and
  that they did scramble passwords.

I called Amazon and the representative verified that no such email had been sent by Amazon. This is may be a phishing attempt. The original email seems (according to other reports) to include link formatted "Amazon.com" text, which may be a link to a fake version of the site. I can't see this in mine, possibly due to a measure by Yahoo Mail to remove such link formatting to avoid phishing attempts like this.

Edit: As mentioned in comments, there could be a valid strand of this email and a duplicate malicious strand, with the false link formatting for phishing purposes.

Beware there are people claiming this is a legit email, while I can't 100% deny the possibility, I'm skeptical: It would be smart for the sender of phishing mail to write that it's a real email on related web pages such as this one. Also note that the directions in the email don't make sense. The title of the email is "Your password has been changed" - but my password was still active.

Update:

I commented skeptically toward answers here claiming the email was legitimate, however I might be pulling the trigger prematurely. My answer assumes:

The customer service rep I spoke to was fully informed.
No identical legitimate email had been copied in the past, or even in the past 24 hrs and false link formatted duplicates were sent out by a malicious user.

Both are possibilities to consider.


How does an attacker compromise a soft switch? Speaking of soft switches (e.g soft switch in data plane of software defined networking). I've been trying to find a good research paper or article that explains how an attacker can compromise a soft switch to tamper flow routing table or perform any other kind of attacks. I think this can be done by compromising a host connected to that soft switch. If this is the case, I still don't know how to be able to tamper the soft switch.

In fact, I want to understand these things conceptually for the sake of my research.

Testing SDN including soft switches can be accomplished with the delta GitHub project from -- http://opensourcesdn.org/projects/project-delta-sdn-security-evaluation-framework/

Ivan Pepelnjak, at his blog, but also in his 2014 Troopers conference talk (YouTube video here), discusses security issues with Software Defined Networks regularly.


What are Security Considerations of Using File Upload/Comparison as Simplified Second Factor? I am evaluating the idea of simplified second factor authentication by requiring a file to be uploaded, such as an image along with username/password.  The file is stored on a user's device.

My reasoning is that this is faster/simpler than getting a code via SMS and entering it.  Specifically, the user does not need to leave the login page to use another app such as an RSA generator or push notification, etc.  The user would have previously submitted and stored a file that is not available elsewhere on the Internet, but is located on their device.

I am using HTTPS, but I do understand that a man-in-the-middle attack could cause the uploaded file to be compromised along with the username/password, so in that sense it is less secure than a code that was sent via SMS that expires in a few minutes and can only be used one time.  And maybe that is the critical flaw.

I did find this post, but it wasn't very useful/specific (or current).
A special file as the second factor in 2FA

I have spent several hours researching the subject of using an uploaded file as a second factor for authentication and found very little, so from this I assume there is something wrong or inferior about the idea.  It is much more convenient for the user for frequent use, but what are the negatives?

Copyright James Daniel Marrs Ritchey. This material was created for
  submission at
  'What are Security Considerations of Using File Upload/Comparison as Simplified Second Factor?',
  but can also be alternatively obtained from
  'https://snippetly.blogspot.com/2020/05/pros-and-cons-of-using-file-for-2fa.html'
  under the terms of any of the following licenses: Ritchey Permissive
  License v8
  (https://jamesdanielmarrsritchey.blogspot.com/2020/01/ritchey-permissive-license-v8.html),
  The MIT License (https://opensource.org/licenses/MIT).

All security measures are a balancing act between various client-side, and server-side attack vectors. By increasing the security against one vector you decrease security somewhere else. Whether it's a good or bad configuration depends on your service and clients, because that's what decides where you need to prioritize your protection.

Positive:

The file is essentially acting as a secondary password, but assuming it's a decent sized file, created using a secure method (eg: a 10 second video of my dog), it would be significantly more secure than a normal secondary password (eg: 12-18 printable characters) against login attacks, or stolen password database attacks. So this increases some server-side security. Since the user isn't typing it in, it won't be catchable by keyloggers running on the device, or persons/surveillance watching the user login, which increases some client-side security.

Negative:

This file must be present on the device, and it can't be protected with file encryption since it's being directly uploaded. The same situation applies to SMS codes. A normal secondary password however, can be stored in a password manager.
To avoid loss of the file users may decide to backup it up (eg: external drive, cloud, etc). This results in additional attack vectors which you are counting on the user to have the know-how to protect.
The user may be enticed to name it something obvious to more easily remember which file to use (eg: "2FA.jpeg"), but this will also make it easier for hackers/malicious software to find it.
Uploading files will use more of the user's internet bandwidth. This could deter cellular, and satellite users from using your service.
Matching the uploaded file with the record on your server will use more of your storage, internet bandwidth, cpu usage, and memory usage which may affect your cost of operation.
You will likely wish to impose maximum size restrictions, but non-technical users may not know how to best make a file under that limit (eg: You impose a limit of 3MB, but their camera produces images which are 10MB).
When the file is uploaded it will be temporarily stored on your server without file encryption, unless you hash it client side, but hashing it client-side would affect the performance of the user's device.
Unlike an SMS code which comes through a different route of communication than the username and password, all communication of login credentials will be coming through one line of communication.
Unlike SMS codes which are usually one-time use, this file will be used every time, which means once an attacker has it they have it.
Depending on the data provided to the user from your service, this file may cause a noticeable change in data transmission (eg: spike, or drop) between the client and the server making it possible to track when a user is logging in vs using the service.


When is content security policy (CSP) not appropriate? We've recently conducted a security review of our identity server website and one of the finding was about missing CSP header. We do have implementation of request filter to add CSP on a controller level. So my question is, is there any documentation out there recommending CSP for or against certain response? It seems overkill to include CSP in all responses.
Here is what I could find which makes sense for pages that have reference to 3rd party code like analytics.
https://developers.google.com/web/fundamentals/security/csp

Even on a fully static website, which does not accept any user input,
a CSP can be used to enforce the use of Subresource Integrity (SRI).
This can help prevent malicious code from being loaded on the website
if one of the third-party sites hosting JavaScript files (such as
analytics scripts) is compromised.

Here are some responses I am questioning whether they are appropriate. Finding some documentation around it would help us justify whether or not it is worth adding them.

Non HTML response (json, css, etc...)
Redirect response (redirect 302)

CSP is only in effect on content that creates its own rendering context. In general, this means two kinds of content: HTML and SVG (other XML-based types, such as RSS/ATOM, might also support CSP in the few browsers that still support them; I'm not sure). These might be full pages, frames, iframes, objects, or (in the case of SVG) images. Note that it only impacts content that is rendered directly into the page; if the contents of an iframe are retrieved using XHR/Fetch and then dynamically inserted into the iframe's document, then CSP headers on the XHR/Fetch response will not have any effect (CSP in HTML meta tags will still be effective when the iframe loads).
Additionally, subcontexts inherit CSP from their parent context. This means that you don't need to set a CSP for something like an SVG or iframe if you set it for the parent page. However, it's still a good idea; if there's an XSS vuln in a subcontext (yes, SVG can contain script!), an attacker would just navigate the victim to the SVG/iframe/etc. URL directly, rather than to the parent page, and you don't want them to be able to skip CSP that way. It's also possible to extend or override the parent context CSP, which is useful in some cases (e.g. allowing inline styles in SVG but not elsewhere).
Mind you, there's no harm - aside from slightly more network traffic - in sending CSP with every response. But if you want to reduce it, HTML and SVG are the areas to focus on. Redirects and error pages with no content are probably fine to skip, but if there's any HTML content, it can use SVG. If you want to go extremely minimal for some reason, CSP can be safely skipped on any page that neither handles any user-sourced data (including stored data from the DB) nor includes any externally-sourced content (scripts, stylesheets, images, iframes, etc.). However, it's best to send CSP with such responses anyhow, as the content of those pages might change in the future and it's best to be already protected (especially at such minimal cost).


DoS attacks and bitcoin I was wondering what the repercussions were if a Bitcoin exchange or website that holds bitcoins were to succumb to a DoS attack.

In my understanding, all a denial-of-service attack does is deny legitimate users access to the website. However, btc-e.com, a large Bitcoin exchange, and many Tor hidden services (which use Bitcoin as a primary form of payment) seem to fall victim to DoS attacks.

Does this leave these websites vulnerable to bitcoin theft? If not, why perform the attack in the first place?

Thank you all.

DoS attacks do what you said: they prevent users from accessing the service. DoS by itself does not mean that theft is possible, although sometimes DoS attacks happen in order to distract those running the service from noticing another type of attack or to trigger known remediation processes that the attackers can exploit in order to perform a different attack.

In the case where theft is not the end goal, why DoS? Why do some people pull the wings off flies? Some people just like to watch the world burn.


How to run multiple session while scanning application through Burp? While scanning an application through Burp, I've found that if I use multiple threads, it results to session errors like The requested session id appears to be invalid. You may have more than one Task Manager window/tab open.

But if I use single thread, the scanning is slow.

Can anyone explain me how to assign different session IDs to different threads so that I can scan through multiple threads? Is it possible to use multiple threads with multiple distributed cookies to these threads using Cookie Jars?

This is ultimate answer by none other than Dafydd Stuttard  when I posted this question on portswigger support forum:

  Dafydd Stuttard Jan 12, 2015 10:58AM UTC Support Center agent

  It sounds like the application is not willing to support multiple
  concurrent requests in the same session (for this particular function,
  at least).

  Burp only currently has a single cookie jar, so you can’t do a scan
  with multiple threads using different cookie jars, sorry.

  One possible solution would be to create an extension that handles
  sessions, and maintain your own separate cookie jars and use one per
  thread. Or you could run multiple instance of Burp, each running
  single threaded, and scan different parts of the application with each
  one.


I am unable to secure a WPA handshake (4 way handshake) I am training to be a pen tester and am having some issues obtaining a 4 way handshake. I use airodump-ng -c -w file --bssid wlo1 followed by Aireplay-ng -0 0 -a (Mac) wlo1

Here's all the steps I follow:

Ifconfig wlo1
ifconfig wlo1 down
iwconfig wlo1 mode monitor
ifconfig wlo1 up
airmon-ng check wlo1
kill processes

Airodump-ng wlo1
airodump-ng -c (channel) -w (file) --bssid  wlo1
aireplay-ng -0 0 -a (mac) wlo1

I know what to do after I get the handshake, I am just stuck. Any help would be greatly appreciated. I am using Fedora 25

First you have to make sure that your NIC can inject and that the targeted access point is in range.

aireplay-ng -9 wlo1

After running this command you should see 'Injection is working!' , and the targeted AP with a high response rate ( 50 - 100% )

Deauthentication attack sends disassocate packets to connected clients, so you need to have at least one associated client.

airodump-ng -c <ap channel> --bssid <ap mac> wlo1

There should be at least one MAC under the 'STATION' tab associated with the AP. You can use this client for a targeted attack.

aireplay-ng -0 5 -a <ap mac> -c <client mac> wlo1

You may have to run the above command several times untill you get a handshake.

You can increase or decrease the number of deauthentication packets. Sometimes one is enough, sometimes it takes ten or more. If you still can't capture a WPA handshake then maybe the issue is with your NIC. Here you'll find a list of compatible drivers, and a patching guide.


How would "hardware verified" API calls be constructed? Problem

Thinking about the Snapshat clones, that stole API credentials, and then used an API without permission.. I think the underlying hardware and OS should have prevented this.

Proposed solution

In other words, I think that hardware-verified API calls from a phone, to a device should be possible... where API endpoint can determine that a call was permitted by an underlying cryptographic verification process.

Simply speaking, if Apple wanted to expose an API that only its devices can access, they could put a private key on the secure element, and then use a fixed API to sign the API call with a key, which would then be verified by the 443 endpoint.

Taking this a step further, if apps in the AppStore can be considered to be a controlled "extension" to base iOS, then I would think that 3rd party users would be able to construct similarly signed APIs.

The result is that their endpoints can verify that it was their signed application, on an iOS device, that caused the API call to occur.  No more spoofing.

Question

Does anything like this exist?

Can we leverage what is exposed to us today to have this additional level of authenticity on API calls to our mobile servers?

Client-side certificates, in software, provide exactly this purpose.

Apple, for instance, bundles each of it's devices with certificates signed by itself as the CA. Thus any communication from an Apple device requires the server to authenticate the identity of the device. Having been signed by Apple, the client is thus authenticated and the communication proceeds.

As to can this be done in hardware, I think the only issue would be on the methodology to revoke the certificate.


Bank account number and account holder in check exposed? I'm not sure if this is standard practice in all banking institutions but almost all banks where I've received checks the account number of the issuer is exposed (some even the account name). Isn't this information considered confidential? If not then disregard this question.

If yes, then it makes me wonder why banks blatantly expose the account number/name of the issuer in checks? Would it be a good practice if they at least hash the account name and number before they print it in the checks you will issue?

Going to have another go at this one, to try and address the many excellent comments...

A cheque is an instruction to a bank to take money from Alice's account and give it to Bob. In order to act on it, the bank need to know Alice's account details; they must be written on the cheque in some form when it arrives for clearing.

A pre-printed cheque in Alice's cheque book happens to have her account number already written on it, purely for convenience sake, in both human and machine readable forms.

@IMB first asks if this is a vulnerability, since if Eve gets hold of a cheque, she can read the account details off it and use them in an attack. The answer is yes, it is a vulnerability.

Then @IMB asks if hashing the account details would be a good control. I suspect they actually mean encrypting, rather than hashing, as cryptographic hashing is a rather specific technical term that doesn't quite apply here, but you get the picture. The answer is also yes, if done carefully, encrypting the account number (with a suitable nonce added) would largely prevent Eve using the account information.

Lastly @IMB asks why don't the banks do it then? Well, as with every security control, you have to measure the cost of using it against the impact of a failure in order to decide if you should implement it or not.

I think the main cost is that humans could no longer read the whole cheque. That doesn't sound like a problem in these days of ubiquitous computing, but banks are conservative and old fashioned and they are particularly fond of having human audit processes. They like a manager being able to pull a cheque at random every day and double-check how it was processed. They like being able to pull a physical piece of paper out and wave it at a customer and say "No, we didn't make a mistake."

Additional costs are that it adds overhead to the cheque clearing process (and customers already hate how long that takes), that you no longer have a backup if the machine readable part of a cheque is damaged, and I suppose you might run into regulatory difficulties about the legal definition of a cheque.

The risks, on the other hand, are not huge, because the banks have other controls in place. They authenticate people before allowing them to remove money, and require more than just account numbers to easily withdraw money. They use various technical methods to prevent Eve printing cheques with Alice's details on. They have insurance to cover any losses. They  monitor account activity for suspicious transactions.

One last thing to consider: Alice has to tell her account details to quite a lot of people anyway: her employer (so she gets paid), the tax man, the water company (for direct debits) and so on. And she has to embed it in her debit card. And the bank have to print it on her statements... So Eve has many other ways to get this information.

In the end, the banks have weighed the costs and the risks and concluded it's just not worth it - especially considering the decline in use of cheques. Last time I tried to pay for something in a store by cheque they had to get the manager because none of the sales assistants had seen one before except in movies.


Is refreshing a refresh token a bad idea? Say I have a refresh token that is set to expire in 14 days.  And I have an access token that expires in 20 minutes.

What if every time you update the access token (using the refresh token), the server hands you back a newer refresh token with an expiration 14 days from when you updated the access token?

Is this a bad idea? Why or why not?

It depends on what sort of system you want to create.

Requiring a re-up of the refresh token is annoying, as users have to enter their password again (or whatever the process is).  If this is an automated process, like an application that runs unattended on a server, this becomes not just a UX issue but a stability one as well, as the system will break if someone doesn't remember to log in and manually get a new refresh token.

However, there's a reason you see this sort of setup.  For instance, Google logs you out of all their webapps every month, which prevents someone who has access to your account (stolen laptop, left yourself logged-in at a library, etc.) from maintaining that access indefinitely.


Can we prevent DDoS or spam form submission with client authentication? There is a public query form in my web app, and architecture team asking to authenticate the web app with OAuth2 like this, but I don't believe it will be of any help.

I believe best way to protect is by reCAPTCHA.

Can we prevent DDoS or spam form submission by using client authentication?

tl/dr: Client authentication in the browser is useless because browser-based bots will automatically authenticate themselves, and
browser-less bots will get stopped by much simpler methods anyway.
This isn't really a surprise, because "client authentication" isn't
really effective for browsers (and is only slightly effective for other "kinds" of clients). Captcha, unfortunately, is the only real solution,
although it cannot protect you from targeted attacks.

Background
I want to clarify a detail from the comments.  My understanding is that the goal here isn't to require someone to login to use your form.  Rather, you want the client (in this case, the JavaScript app you build which runs in the user's browser) to authenticate with your server, so only people browsing your website can submit your form.  This authentication will happen by JavaScript adding an authorization token to the request, and the server rejects any form submissions that don't contain the correct authorization token.
Before I go into details I want to emphasize one important point: it is not possible to restrict someone to only using your "app".  Your JavaScript runs on their computer, in their browser.  As a result an attacker can easily reverse-engineer your app (which is extremely easy when it is javascript in a browser), determine how it authenticates itself with the server, and then reproduce that in anyway necessary.  To try to limit users to only using your app effectively means that you are trying to implement DRM, and it is simply not possible (especially in cases like this).  You can make things harder for attackers, but you can't stop them outright.  Still, let's discuss your question in more specifics.
Bots
In order to protect against spam bots, you first have to understand how they work.  There are of course a ridiculous number of varieties, but I'll focus on two general "types" (keep in mind that I've chosen these categories somewhat arbitrarily):

Many simple bots request pages from the website using a non-browser HTTP client (for simplicity, imagine they use curl).  They then  parse the HTML looking for forms.  If they find one they also look at the inputs on the form, decide on how to "fill out" the inputs, build an HTTP request with their data, and then send it off to the url of the action property on the form.  Pretty simple.  They will also fake details in the request headers (Origin, User-Agent, etc...) to look more like a regular user.
However there are "fancier" bots out there that actually use browsers.  You can build your own bot using something like selenium which effectively lets you automate browsing the web using an actual browser.  The bot uses Selenium to load up a page in the browser, click on input forms, send in keyboard input, and then click on the submit button.

Protecting against "simple" bots
The simple class of bots reads the HTML returned by the server to figure out what kind of request the server is looking for, builds a matching request, and sends it to the server.  If your client-authentication process involves using JavaScript to attach additional credentials to the request, then that authentication process will actually stop such bots from executing successfully.
However, it isn't technically the presence of the authentication that keeps the bots out - it is simply the use of JavaScript that stops them, because the bot doesn't know anything about steps that JavaScript takes.  For this class of bots, you could just as easily have JavaScript intercept the form submission, add some predetermined data to the request (imagine it adds something like not_a_bot=true to the request data), and submit it with Ajax.  The server then rejects any requests that don't include that not_a_bot=true flag.  This sort of incredibly simple check will stop bots that don't execute your JavaScript. In fact, I've actually used this in production systems and it dramatically cuts down on bot submissions.  The only downside is that it also locks out users that don't have JavaScript enabled (which your proposed client authentication method also does).
So, will your authentication step help? Yes!  However, only by accident, and there are much simpler ways to accomplish the same thing.
Protecting against "fancier" bots
However some bots work by using an actual browser, which means it runs any JavaScript passed down by the server.  As a result any sort of automatic authentication step that is executed by your JavaScript will automatically happen for these kinds of bots as well.  In fact, it is nearly impossible to differentiate between these bots and regular users.
This means that whether you secure your form by adding the not_a_bot=true flag in JavaScript, or whether you secure it by having JavaScript add in an authorization token to the request, these bots will take the same exact steps and the server will accept the spam submission.  The attacker won't even have to reverse engineer your app - your own JavaScript will allow the spam bot to circumvent your protections.
How do you stop these bots from filling out your forms?  There's only one cost-effective solution: a captcha system (although even that isn't a guarantee).
DDoS
DDoS is not even worth a mention.  A DDoS attack works by simply flooding the server with so much traffic that it cannot keep up.  While there are some kinds of DDoS attacks that might be prevented by trying to ignore submissions from bots, the most common kind won't be.  Many DDoS attacks work by simply sending so much network traffic to your infrastructure that there is not enough bandwidth to keep up.  When that happens there is nothing that can be done at the server level to stop the DDoS attack.  Completely different strategies (mainly at the network-level) are required there.  Whoever suggested that this might help against a DDoS simply doesn't understand how such attacks work.
Summary
So after breaking things down we can see that client authentication provides absolutely no benefit.  It would stop simple spam bots, but only because it requires JavaScript which simple bots don't execute.  Instead there are much simpler steps which would stop these kinds of spam bots anyway.  Moreover, the client authentication will provide no protection against bots that use actual browsers to do their job.  Nothing will stop those, although a good captcha may at least discourage drive-by-bots that aren't specifically targeting you.


Web site vulnerability discovery by scanner I have a web site which require user login and password before they can access any materials and use the services. However, a recent VA scan found that one URL link is vulnerable to a an old version of a component.  E.g.

https://mydomain/myservice/somelongURLstring.extension

The question I want to ask is, how does the scanner knows how to find this vulnerability even though they do not have the login credentials at all? Is it some kind of file/folder configuration problem at the web server side? So should I check the permission of somelongURLstring.extension ? What about things like robots.txt ? would this file be the cause of scanner being able to find this link?

UPDATE:
After poking around for the required string, it was found in a .js file

document.goform.action = '/myservice/somelongURLstring.extension'

and also from a file called struts.xml.

If it's a js file then its considered "publicly downloadable" and that's why the scanner is able to find?

thanks

Difficult to say without knowing how the vulnerability scanner was configured.

I can tell you from experience there are 3 ways that I know of it could have been found:

1.) A web application vulnerability scanner will crawl all URL's found. Is it possible there is a link to this service or page some where else on the site or disclosed through an error page/message?

2.) A web application vulnerability scanner will search for known/common and even unknown/uncommon dirs by directory fuzzing.

3.) The web application vulnerability scanner was provided a list of physical files that resided in the web dir. It then attempted to scan each file without authentication. If proper authentication mechanisms aren't in place, it could have accessed the file in question.


How original PDF books get out of the publisher's reach and appear online for pirate downloads? If a scanned book appears online for pirate download, it's no wonder: someone who had a hard copy just scanned every page.

But there are a lot of PDFs out there that look like official publisher's copy that was never supposed get out of the publishing house. How does this massive centralized nature of book piracy happen?

I assume that scientific books that get published online as PDF ebooks may have been "contributed" to a file-sharing database, but other books, in print-layout are more difficult to get access to in large numbers.

Is something in the publishing chain compromised..? Is it probable that publishers' computers were intentionally infected with viruses for this purpose?

A combination of things could contribute, with a particular book being some/all/none of these, or something else entirely. Here are a few of the ways books could "get out" into the wild

People inside the company selling the books "on the side"
People inside the company taking the book home for personal use and then giving it to a few family members or putting it online
Review copies being sent out and shared by the reviewer
Screenshots of the eBook - if you can display it, you can screenshot it. Like a scanned copy, but without the loss in quality
"Ripping" the book - ie taking the proprietary copy and extracting the contents
Someone hacking into the publisher's systems and taking a copy (possibly from a site providing review copies)
The author releasing a copy (perhaps to friends or family)
Some are simply free


Google showing spam links on my site When I search the name of my site on Google, I see site links description which are spammy and not related to my site. Sometimes when I click I get redirect to phishing sites.

But I have used many site cleaner tools, and they reported that my site is clean. I have checked my site in Google's webmaster tools for malware, it says no malware detected. Though Google webmaster tools did show about 290 crawl errors, which are unknown links like payday-medcine-money-45451212.html.

My site is in Wordpress, I have looked at themes files and found backdoor.

I don't know what to do, is this malware harmful for my website? How can I get my wordpress site clean?

On of the side links points to http://www.moonthemes.com/themes/elegant-best-bussines-portfolio-theme/.

Downloading that file using wget results in:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Online LICENSED drugstore ::: Levitra indian price | EXTRA LOW PRICES!
</title>
<meta name='description' lang='en' content='Levitra indian price ::: We sale
   brand and generic drugs. In our pharmacy: US FDA Approved

So unless you put that up there, your server is compromised.

Note that common malware does a number of tricks in order to stay undiscovered. For example it may check the Referer-header, only send the malicious content to a client ip-address onces, check the browser user agent header, etc.

Furthermore it may be hidden in a number of places. For example in the 404 error handler. It might even be possible that the attacker got root permissions and manipulated the webserver software.

You need to get help from someone with experience to identify the vulnerability that was exploited. Then you need to setup the server from scratch.

The server might spread malware to visitors or send email spam. So in order to protect your visitors, third parties from attacks and yourself from legal actions, you should take the server offline.


RC4 support in SSL configuration GitHub recently improved its SSL setup by removing RC4 support:

  To keep GitHub as secure as possible for every user, we will remove RC4 support in our SSL configuration on github.com and in the GitHub API on January 5th 2015.

  RC4 has a number of cryptographic weaknesses that may be exploited, impacting the security of your data. More details about these vulnerabilities are listed in the current IETF draft.

  If you are using Internet Explorer on Windows XP, you will no longer be able to access github.com once this change takes place. Windows XP only supports outdated SSL ciphers, is no longer supported by Microsoft, and contains a known critical security problem in its SSL implementation.

Since this breaks the site in Internet Explorer on Windows XP, I assume that sites that are accessible with IE on Windows XP must support RC4 ciphers.

Does this mean that those sites are not as secure as possible?

There is only one way to make a site as secure as possible: take it completely offline. Everything else is a compromise: what browsers and clients do you want to allow to your site.

Even GitHub is still not as secure as possible. They allow TLS 1.0 and TLS 1.1 while there is a newer TLS 1.2. Disabling TLS 1.0 and TLS 1.1 would however deny users with Internet Explorer 7/8/9 on Vista which they are not (yet) willing to do.

To answer your question: yes, those other sites are not as secure as possible. But neither is GitHub.


DNS communicating with a remote host on an unusual server port 53 We have an Active Directory EC2 server on AWS US East region that has DNS enabled to resolve only internal hostnames. It is not reachable from any hosts on the public internet.
Recently we enabled an AWS service called Guard Duty for threat detection and it flagged a finding which indicated our DNS server communicated to a DNS server in Australia (nslookup/whois/nmap all helped to quickly determine the server in AU is indeed a DNS server)

Does anyone know why an internal DNS server would communicate to an external DNS server? Is this normal or does it indicate a problem that might uncover something very bad.

Appreciate any inputs. Thanks!

Based on the setup described in the question and comments this kind of traffic is likely innocent. You seem to run a DNS server which recursively resolves the domains. In order to resolve a domain it would need to query multiple DNS servers, starting with the root servers. The DNS servers which are queried might be all around the world, depending on the domain which need to be resolved. And it might for example be a simple typo in the domain name which makes the DNS server visit strange locations which are usually not visited.

If you don't want to have this kind of traffic you might configure a fixed forwarding DNS which does all the resolving. Any DNS traffic which is not send to this forwarder can be considered suspicious then.


Web developer needs customer's private key As a non security expert, I'm looking for advice from those who are.
I work with company X who have hired company Y to develop their website. Company Y needs to integrate server-side online payment and has asked company X for the secret (private) key related to their payment account. Of course, secret keys are called that for good reason. So what is the "right" way to do this?
My dilemma is that either X shares the key with Y in as secure a way as possible (with the resultant risk that the secret key is somehow compromised)
OR
Y creates the payment account on X's behalf and integrates the secret key server-side so that no key sharing occurs but Y still has to hand over the payment account to X on completion - including account credentials - which carries the same risk of breach.
What am I missing please?

Plenty of entities will commonly have access to the private key:

Hosting provider may read it at will.
Employees of company may read it.
Service provider who generated it may store a copy.

We handle this by legal agreements. We trust our hosting providers not to peek at it, because their business model is selling hosting (and implicitly trust), not stealing your private keys. In addition, there may be explicit NDA's and legal accountability.
We trust employees, because of NDA's and a legal framework for holding them accountable.
You see a theme here? It's a private key for payment processing. If you don't trust whomever develops your e-commerce platform to handle this, you shouldn't trust them to develop your e-commerce platform either.
In fact, having competent people handle the key material may be securer than attempting to instruct someone from Company X, who may not know about editors leaving a backup file behind - or transporting it over insecure channels - or all other kinds of mistakes.
Transfer the key to the developer in an as secure fashion as possible. This may be S/MIME-encrypted e-mail, PGP, or a 7zip-archive with a complex password sent in a separate channel (SMS, phonecall, mail etc).
Develop a legal framework for holding Company Y accountable if they leak the key, and specify measures that they should take - such as limit the availability to the minimal set of persons needed and so forth.


How to generate a password dictionary for a specific use I have a locked work file that I need access to. Unfortunately, the company that provided the file is no longer in existence and I can't track anyone down to help me out.

The file is encrypted and can be unlocked using a "source key". The source key is stored in a clear text .DAT file, and you can have multiple source keys in a single .DAT file. I've run some tests, and I can put thousands of lines (unlimited?) in this file and the software will check them all to see if one is a match for the encrypted file.

I'd like to create a .DAT file with all the possible dictionary attacks using these rules:

Source keys are text strings that follow IEC-1131 naming conventions. Specifically,
this convention states that an identifier must be a string of letters, digits, and
underline characters which begins with a letter or underline character. Underlines are
significant in identifiers (e.g., A_BCD is interpreted differently than AB_CD).
Multiple leading or multiple consecutive embedded underlines are not allowed, trailing
underlines are not allowed, and letter case is not considered significant. The source
key can be any text string that follows these rules and consists of up to 40 characters.

If anyone could help me with this, I'd be really grateful. Thanks

It would be pretty easy to write a script that will generate every possible key according to those rules and dump them in a .dat file. If you want, I can whip one up for you in python and post it here, but I don't think that would actually solve your problem.

Taking a rough squint at the math, you have an alphabet of 37 characters (26 letters + 10 numbers + _), with lengths of up to 40, so that's at least 37^40 different keys to try. At40 bytes per key, you're looking at roughly 10^66 bytes of data to store this file. Note that a terabyte is 10^12 bytes, so you would need 10^54 1 TB hard drives just to store the file.

The only way this would finish in your lifetime is if you know something about how they generated the keys which allows you to cut down the list of possible keys by 99.999999...% For example if you know that they only used 8-digit keys, or the keys were all English dictionary words, etc.

Without a lot more information, I don't think you're going to get much traction with this approach. :-(

Update:

If the key is a computer-generated random password then you're sunk with this approach, but your comments indicate that there's some chance that a human typed it in, which means there's some chance that you'll stumble across it in a cracked passwords dictionary.

skullsecurity.org seems to be a good source of leaked password lists (and comes with a recommendation from this answer).

crackstation.net seems to host a giant 15 GiB password list, though I can't personally vouch for it.

Depending on how much that file is worth to your company, you could download some of those lists, rename them to .dat, dedicate some computers to the cause, start one copy of the decryptor per CPU core (each one working on a different password list). Check on them after a month and with luck, one of them will have spit out a decrypted file. It's unlikely to work, but if the file is valuable enough to you, it could be worth trying.


Android Kitkat reports: "Network May Be Monitored by an Unknown Third Party" when using non-default root CA My company uses a private PKI to handle such scenarios such as

Mutual auth (TLS) to a website using client certificates
SSL web server certificates on an Intranet (once a VPN session is established.)
S/MIME secure email.
Activesync authentication

When upgrading Android to Kitkat the presence of a non-default root certificate results in these warnings

 and

It is possible to remove this warning for a root user, or by uploading the certificate into Google Apps (and paying $5 per user/month), however I'm looking for a solution that does not incur this unnecessary cost.

Several people have posted this as a defect in the FOSS code, however the issue #62076 (starred by 121 people) has been closed as "by design".  Edit: This issue has been reopened in issue 82036 Please star it to vote as an issue, or comment as needed.

Through testing I verified that this error still appears when using Name Constraints, and limiting the EKU purpose of the new Root CA.  (S/MIME, client authentication, etc).

Is there any way to add a certificate to the trusted roots on an Android phone that does not create this error? (in current or future version)
Are non-default trusted roots, in practice, more problematic than the default CA list (in other words is Google solving the wrong problem?)
Is it reasonable to allow a root cert that is properly constrained (at the root) by EKU usages, or Name Constraints to generate a different warning or set of approval dialogs?

To answer your first question:

As far as I know, there is no way to circumvent this.  It's a security feature.

To answer your second question:

Yes, non-default trusted root certs are definitely potentially problematic.  They are often abused.  They are sometimes used for workplace or traffic monitoring (which is potentially OK if adequately disclosed, though it may still feel sketchy to many), but they're also sometimes used by spyware, malicious apps written designed to snoop on your activity, and other icky stuff.

So, it's a tradeoff between (a) the risk of scaring users, when the user was already aware and nothing bad is going to happen, if you do show the warning, vs (b) the risk of users getting spied upon without their awareness, if you don't show the warning.  The Android developers presumably had to make a judgement call on the relative severity and prevalence of these two risks, and presumably came down on the side of informing the user.  I'm not in a position to form an independent view on this decision, but one can understand why they might have made this choice.

You linked to the issue on the Android bug tracker.  Well, if you look at comment 8, you will see an explanation from an Android developer of why they chose this behavior.  See also comment 39 for another scenario.  So yes, there is a valid reason why they do this; whether you agree with their judgement or not, this is a public explanation of their reasoning.


A safe digital typewriter If I understand well, it is now well documented that all Intel chips should be considered as back doored because of the Intel Management Engine. I guess one should now consider that all chips over a given complexity are possibly back-doored in this way or in hardware. It is also reported that the Russians are switching back to typewriters.

http://www.telegraph.co.uk/news/worldnews/europe/russia/10173645/Kremlin-returns-to-typewriters-to-avoid-computer-leaks.html

http://www.bbc.com/news/world-europe-23282308

However mechanical typewriters can also be bugged, and it is not that convenient for file sharing, steganography of the data on images, etc.

https://www.nsa.gov/about/cryptologic-heritage/historical-figures-publications/publications/assets/files/gunman-project/Learning_From_the_Enemy_The_GUNMAN_Project.pdf

So my question is: would the 'good' technical solution, for writing a text and encrypt it keeping the highest level of certainty that one is not spied on, be to:

put together an Arduino microcontroller (simple enough to not be back-doored), 2 SD card readers (one for SD card with text content, the other one for SD card with exclusively encrypted text content), a primitive keyboard, a simple 16 lines LSC screen, and
use the Arduino as a primitive word processor + AES encrypter
plugging only the encrypted SD card on other machines?

Do you think this would be safe? Do you think one can get a safe system in a simpler way?

You state that "I guess one should now consider that all chips over a given complexity are possibly back-doored in this way or in hardware" and then ask "what kind of chips can be safe?" The Arduino or Raspberry Pi, although less complex than PC chips, are still much more complex than the room-sized supercomputers of old.

Additionally, you make the assumption that hardware may be backdoored but the OS may not.  I think that contradicts the premise of your question: how we keep digital communications from being snooped upon?

I'm going to steal from @Hector above.  Based upon the question, I can really only see one possible technical solution: air-gap the devices and only allow specific USB disks between the two communicating devices.  No other USB disks would be allowed, and the message disk would only be allowed in the communicating devices.  Then, to encrypt that communication, use only a one-time cipher based on something random and then padded with a list of names from the Prague phone book.  (czech names would make a frequency distribution crack more difficult due to the way that names are spelled).  Also the drive in transit would need to be kept secure in a container that cannot be opened without destroying the USB disk, where only the sender and recipient have keys which vary from day to day.

That trades the security desired with usability, however.  The users of that system would find it a huge pain in the Mikta.


Credentials for scanning a database server's vulnerabilities what is the required credentials for scanning a database server's vulnerabilities by using  vulnerability assessment tools such as Rapid 7 Nexpose?

There are two general types of tools out there (and I realize I'm over-simplifying the matter), which I'll call penetration tools and risk analysis tools. We might also refer to them by other names, such as prevention tools and mitigation analysis tools, which has a similar meaning in most cases. Prevention covers preventing an attack, and mitigation refers to minimizing the impact of a successful attack.

Penetration tools cover session spoofing, cross-site scripting, exploit checking, SQL injections, privilege escalation, and so on. All of these attacks should be performed from the perspective of an unprivileged user, so no credentials should be specified at all (or possibly a guest user or basic user with limited privileges). After all, if you log a tool in as "root", it has already penetrated the system, thus negating the purpose of the tests. There's no need to "test" how much damage root can do, because everyone knows (or should know) that once root is compromised, the entire server is unreliable until it's been fully re-secured physically and in offline mode.

The second class of tools, risk analysis, aim to cover the impact of what happens after penetration has occurred. For example, if there's an SQL injection vulnerability, such a test would show if you can then trick the system into dumping every user name and password. These tools may require administrative or non-administrative credentials, if only to analyze the risk of a compromised account or direct database access.

The specific tools you're using should tell you what each test does, and what type of credentials the test will require. Providing the wrong credentials, or providing credentials when none should be given, will invalidate the results of the test.

This is something that you will need to sit down and logically think out for each test you're going to perform. Ask questions like "does this test attempt to gain access to the system?" or "does this test check the structure of my databases?" If the test is about gaining access, it shouldn't require credentials. If the test is about analyzing what happens after penetration, credentials are probably required.

As a final word of advice, if you don't feel qualified to run these tools, or you don't know, for sure, what a tool does, consult an expert. The only stupid questions are those left unasked. While a forum like IS SE is a great place to get answers to hard-pressed questions, you'll probably find that a 10 minute dialogue between someone with more experience with a particular tool or test will have far greater impact than a forum like this, where questions appear and are eventually answered.

The rule of thumb here is that if a question is particularly broad, you should expect to have to ask many questions, which means a chat is in order. IS SE provides a chat room, which I suggest you visit, as well as many other places where you could find people with experience in the matter, such as IRC or even the support personnel of the tools you're using.


Can't understand how stuxnet was bogusly signed Wikipedia says that

  Its device drivers have been digitally signed with the private keys of
  two certificates that were stolen from separate well-known companies,
  JMicron and Realtek, both located at Hsinchu Science Park in Taiwan

Source: Wikipedia - Stuxnet - Windows infection

However, I can't understand how stolen certificates make the drivers be digitally signed with the private keys of JMicron and Realtek.
As far as I know, certificate has only information of a company, and its public key. There's no information about private key in certificate.
Does it mean that their private keys were stolen too?

It is not the certificates that have been stolen, but their private keys.

The formulation is indeed ambiguous. You should read it this way:

  Its device drivers have been digitally signed with the private keys (of two certificates) that were stolen from separate well-known companies, JMicron and Realtek, both located at Hsinchu Science Park in Taiwan

(Parentheses and emphases are mines.)

I suppose the term certificate has been added to help the reader understand that they're talking about asymmetric cryptography, certificates, and trusted third parties.


Ways to bypass browsers CORS Policy I was pentesting a Json Rest API today; the API needs a specific header to be sent:- Content-Type: application/json which doesn't allow CSRF attacks.

The only option I was left with was sending cross domain requests since there is no CORS policy set. However while trying sending xhr POSTs with the "content-type" header the browser sends OPTIONS request to the endpoint and triggers a 403 disallowing to POST. I've tried bypassing this using plain/text and other headers but none of them seems to work.

Do you have any ideas on how to proceed on this? I've heard that sending the same via an SWF file would work but have to try it out.

You can use the following content types without CORS access:

application/x-www-form-urlencoded
multipart/form-data
text/plain

You can try a couple of things:

Try sending valid JSON with another content type. Some implementations don't look at the content type.
Try sending valid form data with the correct content type. Some implementations accept multiple ways to send the data.

If the application really needs the application/json content type, it is not possible to send a cross-origin request.


What are the limitation on encrpyting proxy i would like to know if i encrypt a proxy server communication with TLS v1.3 is it still possible for a firewall censor to a deep packet scanning to decrypt. Also, what can be done to make the encrypted proxy more secure?

Encrypting alone will not help. You have to make sure that the encryption is actually done  end-to-end to the expected proxy and not via some man in the middle, like the intercepting proxy on the firewall. Thus you not only need to enable TLS but also make sure that you properly check the certificate against the expected one.
Since in corporate environments it is pretty common that the intercepting proxy is added as trust anchor on all machines it is not sufficient to just rely on checking if the certificate is trusted, but also you need to make sure that it is exactly the certificate you expected or that it was issued by the CA you expect. Alternatively you might setup the proxy so that it requires authentication with client certificates which makes SSL interception impossible too, assuming that the proxy properly checks the client certificate. How this is done and if this can be done at all in your environments depends on your specific (unknown) setup.
Once this is done the connection to the proxy is save against SSL interception in the middle. You still have to trust the proxy itself though. TLS will also not protect against interception before encryption and after decryption, for example from within a browser extension.


Combining capability-based access control with SAML I have been looking into various research on identity, PKI and access control trying to boil it down to a simplified methodology for IAM (Identity & Access Management).

One thing which pops up in lots of places is capability-based access control, as in: your current permissions are encoded in a ticket or certificate following the request.  Lots of contemporary research is pointing to this as something to look in to, as it means giving temporary authorization to perform a certain transaction.  Authorizing the transaction is often more important than establishing identity.

It seems to me that SAML is flexible enough to be handle such use-cases, encoding capabilities as SAML-attributes.  I also believe capabilities is a better match in a federated scenario than roles, as trying to synchronize role-definitions (or even identity) across organizations seems futile.

However, I have found very little research, products or even prototypes on combining SAML and capabilities.

I have started looking at XPOLA, but I am wondering:

is there any other research, papers, products or projects I should take a look at?
does any of the off-the-shelf IAM or federation-products provide any capability-based functionality?

I'm not familiar with XPOLA, but here are some resources on using capability-based authorization on the web that you should read:

Alan Karp at HP Labs is doing work in exactly this area: capability-based security for web services, including using SAML and similar standards.  Take a look at his work.  See, e.g., the following papers of his:

From ABAC to ZBAC: The Evolution of Access Control Models.
Solving the Transitive Access Problem for the Services Oriented Architecture (discusses using SAML certificates for capability-based security)
Authorization-Based Access Control for the Services Oriented Architecture (more discussion of use of SAML certificates)

Webkeys bring capability-based security to the web.  It is a detailed, worked-out proposal for how a URL can serve as a capability, and how to build web services on this substrate.
The Waterken server is a capability-based approach to web security, which allows deploying non-trivial computation and coordination between entities using object capabilities as the security model.  See, e.g., some of the talks from Tyler Close.
The cap-talk mailing list is the leading place where capability folks hang out and share information about the capability-based approach to security, including web security.
For more background on capability-based systems, read Wikipedia's entry on object capabilities, Jonathan Shapiro's essay on What is a capability, anyway?.  See also Kragen Sitaker's rant on capabilities and the web, or Doug Crockford's more recent talk on capability-based security and the web (it focuses more on fine-grained sharing, including on the web side, rather than web services design, which I think you are more focused on).


Security flaws of storing strings and some of its substrings using Microsoft SQL Server Transparent Data Encryption? I am creating a database table with an encrypted value, say users:

Say John encrypted is U2FsdGVkX193AOGlBRE1RNScJRGN9vSB4erIljJwaKw=.

UserId | Name
------ | --------------------------------------------
1      | U2FsdGVkX193AOGlBRE1RNScJRGN9vSB4erIljJwaKw=

Johnny would be encrypted as U2FsdGVkX19lYDuvuBg3BzTnZro4J6zKoo9s/TLeiPU=.

UserId | Name
------ | --------------------------------------------
1      | U2FsdGVkX193AOGlBRE1RNScJRGN9vSB4erIljJwaKw=
2      | U2FsdGVkX19lYDuvuBg3BzTnZro4J6zKoo9s/TLeiPU=

How could I search for names beginning with Jo?

I was thinking of storing:

NameStub | UserId
-------- | ------
Jo       | 1
Jo       | 2
Joh      | 1
Joh      | 2
John     | 1
John     | 2
Johnn    | 2
Johnny   | 2

I can now do searches like 'Jo%', 'Joh%' and both will include both users.

I can see the obvious security flaw with the above that anyone can map out stubs like Jo or Joh.

So I have decided to store the stubs encrypted:

NameStub    | UserId
----------- | ------
enc(Jo)     | 1
enc(Jo)     | 2
enc(Joh)    | 1
enc(Joh)    | 2
enc(John)   | 1
enc(John)   | 2
enc(Johnn)  | 2
enc(Johnny) | 2

where enc(x) is just the encrypted value for x.

When searching for Joh, I will encrypt Joh and then query for matching stubs and any associated users with names for that stub.

Note:

Both of the encrypted columns will use different keys and algorithms to protect the data.
I will be using Microsoft SQL Server Transparent Data Encryption (TDE).

I need to understand if I am missing something fundamental here.

TLDRTLDR

Don't do this!

TLDR

TDE is irrelevant for this question.
Don't do this (index encrypted substrings of encrypted strings).
Don't index encrypted values generally.
If you are going to do this anyways, use an HMAC or other MAC algorithm to generate the encrypted values to be used in the index(es).
If you're feeling really lucky, consider using a format-preserving encryption algorithm or a "Searchable Symmetric Encryption (SSE)" algorithm instead of a MAC algorithm.

TDE

I'm assuming "TDE" is Microsoft SQL Server Transparent Data Encryption. TDE is irrelevant (for your question). TDE encrypts an entire database and is 'transparent' to database users or other clients connecting to the database. What TDE protects from is an adversary accessing the data in the database offline, i.e. via copies of the database files or copies of the encrypted data, but without also having access to the encryption key with which the secured data was encrypted. Think of an attacker stealing a backup of the database, e.g. stealing a backup tape cartridge containing the database data or log files. If an attacker can access a live database for which TDE is configured, and the database system doesn't otherwise deny them access to the secured data, they can access any data in it (that's not otherwise encrypted apart from TDE).

Indexing Encrypted Data

The most secure method of searching encrypted field values is going to be to decrypt all of the field values to be searched first. Ideally, you'd do this directly in the database, e.g. in a stored procedure or function. It seems unlikely that an attacker could read the memory of your database process(es) but not also access the encryption key(s) used to encrypt the data in the database.

Your idea of storing encrypted "stubs" or substrings will weaken the security, perhaps substantially. This is a great answer on another question on this site that seems to generalize your question somewhat:

encryption - Indexing encrypted data for efficient searching

That answer points out an important reason why this approach weakens the security:

  At best, what you could do is to implement deterministic encryption, such that encryption of a given record value always yields the same encrypted result. This leaks a modicus of information (if two records have the same contents then this will show, despite the encryption layer); on the other hand, it allows for exact searches: you encrypt the value to search, and use the index on the encrypted values.

You can't create an index of encrypted values without exposing (to people that can see those encrypted values) that equal values are equal. Typically, values would be encrypted with a salt that's unique to each specific instance or occurrence of a value but one consequence of that is that any number of instances of the same cleartext will be encrypted using different salts and thus will result in different encrypted values. This is one reason why decrypting the values to be searched – before searching – is probably the best choice if you really need to store these values encrypted by default, even for authorized database users.

Note that this same weakness applies even for searches for exact matches, i.e. even if you're just indexing the encrypted values whole for performing searches for exact matches. In fact, for the two sentences I quoted above, the sentence immediately following is:

  Substring searches, however, should be avoided at all costs.

(That's referring to indexing encrypted substrings.)

Algorithms for Indexes of Encrypted Data

But – if you decide that weakening security as described above is something you're willing to accept, then – cryptographically – the top two answers on this related Stack Overflow question suggest using a MAC algorithm to generate the indexed version of the field to be searched:

database - What's the best way to store and yet still index encrypted customer data? - Stack Overflow

This answer on the same question above suggests carefully considering using a format-preserving encryption algorithm, the care being in knowingly using a class of algorithms that are relatively new and thus possibly vulnerable to attacks not yet publicly known.

In this comment on this very question, @AlphaD suggests considering using a "Searchable Symmetric Encryption (SSE)" algorithm. This should only be considered with even more care than for considering a format-preserving encryption algorithm. SSE algorithms are so new that there wasn't even a Wikipedia page for them when I checked.


ASP.Net usage of the Machine.config file In ASP.Net, the normal way of encrypting an object ( as an exmaple a user cookie in the server side ) is read the shared key located in the machine.config file. The machine config file contains following config entries.

<configuration>
    <system.web>
        <machineKey decryptionKey="section for decryption key"
        validationKey="section for validation key" />
    </system.web>
</configuration>

Is this fully safe to use and safe to store key values like this? If not what are the other alternatives we have ?

Is this fully safe to use and safe to store key values like this?

It is not a good idea to save your symmetric keys in a machine level config file. Main thing is , it can be accessed by any admin level user in your system and it is not private to your application only. This key in the config file is in plain text which is pretty bad in terms of security stand point.

Apart from that in a Web farm situation you need to replicate these keys in every host machine you are using. Hence, the key rotation and updates will also become a problem.

  If not what are the other alternatives we have ?

The best way to secure your symmetric keys in a server is by using a secure key store or a HSM ( Hardware Security Module).

Since you are using the .Net you can take  look at the Data Protection in .Net. If you are using the .Net Core the best way to deal with this is using the Data Protection API .

If you are deploying your application in a cloud environment like Azure, Then you can use Azure Key vault .

More Reading


Android tamper resistance: BuildConfig.DEBUG spoofing? Our team is trying to secure a native Android mobile app.
Amongst other things we are using Dexguard for some checks such as tamper, root and emulator detection.
Long story short: some of these checks fail in our debug builds - mainly because we want to keep the build times short for developers - and we need some way to skip them [1].
The suggestion by official Dexguard support was to use something like this:
if(!BuildConfig.DEBUG){
    // do actual check if app has been tampered with
}

Now I'm worrying:
Doesn't such a conditional make the tampering checks very easy to circumvent for an attacker?
My fear is that if an attacker tries to tamper with the app, he can easily do so if he is also able to somehow make it think that it is a DEBUG build. Thus with little effort all the (expensive) Dexguard tamper checks are circumvented...
Are my concerns justified? Does including a conditional such as above make tampering the app easier for attackers?

[1]: The background here is: Dexguard makes builds take a looong time. Such as 50 seconds instead of 5 seconds for a simple unit test re-run. Because of this we disable Dexguard for our debug build, which in turn makes certain of the checks (such as tamper detection) fail, as they rely on the APK being processed by Dexguard.

As your sample code shows if the attacker uses a debug version he can easily bypass the security checks. Actually you need compiler directives to do that.

Using compiler directives the portion of codes marked as DEBUG never compile to final application and because of that you are safe using that method.


Penetration testing reported ZERO vulnerabilities. Does this mean my web app is secure? I've spent many hours on whitebox testing to make sure my code was safe. From a theoretical standpoint, the code SHOULD be safe. I then used several widely known testing tools  (including one that cost $3500) to test for SQL injections, cross site scripting, CRLF injections, file handling security, and more.  All software came up with 0 vulnerabilities found. Can I assume my app is 99% secure at this point? Has any of you ever done blackbox testing and thought it was safe only to find out otherwise?

Automated testing is a good step, but it isn't a replacement for a skilled human ethical hacker to find vulnerabilities. This may be through black and white box testing, code review, and specialized tools like metasploit and custom-written code. However it's done, people with the skills and experience dig far deeper and get many more results than automated tools no matter how good.

It's impossible to give a figure for how secure you are, if all you have done is used automated tools then you have protected yourself from a good deal of the automated exploit tools out there, but a skilled person will likely have a much better chance to find anything.


MACSEC nonce/key uniqueness 802.1ae requires a nonce to be sent with each Ethernet frame in the MACSEC tag.  The 96 bit nonce is formed by concatenating a 64 bit fixed field (based on MAC source address and port number) with a 32 bit packet number.  The packet number is incremented for each frame.  So the nonces for two successive frames belonging to the same secure association would look as follows:

Frame #1  {MAC SA, Port Number, PN}

Frame #2  {MAC SA, Port Number, PN+1}

Now the frames are encrypted using the AES-GCM mode. So each 128 bit plaintext block of each message is encrypted using a unique nonce.  For example:

Frame #1, Block #1 is encrypted using {MAC SA, Port Number, PN}

Frame #1, Block #2 is encrypted using {MAC SA, Port Number, PN+1}

etc...

Frame #2, Block #1 is encrypted using {MAC SA, Port Number, PN+1}

Frame #2, Block #2 is encrypted using {MAC SA, Port Number, PN+2}

etc...

So it seems that the same nonce/key combination is reused for different blocks in successive ethernet frames.

But the AES-CTR mode specifically warns against using the same nonce/key combination.

What am I missing?

thank-you

If you look at the GCM specification, you will see on page 15 that when the IV has length exactly 96 bits, then the counter for the AES-CTR encryption is initialized at J0 = IV || 031 || 1, i.e. the 128-bit counter is built by appending 31 bits of value 0, then one bit of value 1. The successive increments when doing the CTR encryption will alter bits in these low 32 bits. Thus, there is no overlap as long as no ethernet frame is bigger than four billion blocks, i.e. 64 gigabytes... and an ethernet frame is indeed much shorter than that.

Alternative description: if a frame uses IV x, then the counter value for that frame begins at value 232x+1 and will go up to 232x+94 (for a 1500-byte ethernet frame, a bit less than 94 blocks). Next frame will use IV x+1, for a counter which starts at 232(x+1)+1 = 232x+232+1, incurring no overlap.

Note: this means that it would be quite unsafe to encrypt more than 64 gigabytes as a single run with GCM. This is stated explicitly in the specification, page 8: plaintext length shall not exceed 239-256 bits. This is more than enough because, by definition, an authenticated encryption mode is meant to provide some integrity guarantees; thus, it makes sense when the data could be altered by the attacker; correspondingly, the receiver of data shall not use it until it has verified the MAC, which entails buffering the whole "packet". Who wants to buffer 64 gigabytes of data before being able to begin its processing ? When GCM is used in TLS, the buffer size will not exceed 17 kilobytes; and, in your case, the maximum size will be that of an ethernet frame, which maxes out at 9000 bytes even with jumbo frames.


Accessing HSTS Server with an Unsupported Browser Let's assume that I have correctly configured my server to enforce the HSTS policy, and it works correctly for IE 11 browsers. What happens when a someone using an unsupported browser (e.g., IE 9) tries to access the site? What will the server do, and what will the user see? Is there a process/procedure to "gracefully" handle the condition of an unsupported browser accessing an HSTS site?

The only thing the server does when it comes to HSTS is sending the Strict-Transport-Security header. Enforcing the policy - keeping track of which domain has HSTS, when it expires, making sure these are only accessed with HTTPS, etc. - is entierly the responsibility of the client (e.g. the browser).

So what happends when a non supporting browser visits a HSTS site? The browser sees a header it doesn't recognise, so it doesn't do anything with it. Then it continues doing what a browser does as if nothing happend. Of course the user of such a browser does not get any protection, but they don't get any compatibility problems either.

So there are no compatibility issues with HSTS, and you don't need to do anything extra for older browsers.


OBSD X11 as non-root? If running X11 as root is not a very good idea, then can anyone mention a method/solution, how to still use a GUI, and not having X11 as root?

(I speak here more generically than in the specific case of OpenBSD.)

X11 needs some direct access to the underlying hardware, something which requires some extra privileges which are not given to just any process (such privileges can be used to mess with memory transfers, e.g. between system memory and hard disks). So there must be some root-or-equivalent involved at some point. However, once the said privileges have been granted, nothing says that the process which runs the X server must keep on being root. Of course, if a non-root-but-with-hardware-access X server gets subverted, it still may gain, theoretically, strong access to the machine through DMA manipulations, but this does not look easy at all.

(Also, there can be totally unprivileged X11 servers which use a framebuffer interface, although this tends not to be very compatible with support for accelerated graphics.)


Can the ISP see the path of a SOCKS proxy chain While I was reading an article about proxy chaining

https://resources.infosecinstitute.com/proxy-chaining/

I've stumbled upon this paragraph

  Even if you use proxy chaining you can’t be 100% anonymous. You could be traced on the basis of each proxy used to establish a connection. It just makes it a lot harder to track. If you use foreign proxies, then it will be more complicated to find someone. Tracking could be done only by collecting the logs of each proxies used from the administrator. This could take a lot of time if we use a foreign proxy.

I'm not sure if i understand that correctly but from what I know about the workings of SOCKS proxies, they are raw TCP connections that relay the TCP stream to the specified address. With that in mind, consider this example:

I want to connect to someserver.com but lets say due to censorship I cannot do that openly because the ISP will give me trouble, now I want to connect to that server through a proxy chain (consisting of 3 socks5 proxies)

This will look something like this

ME -> (ISP) -> P1 -> P2 -> P3 -> someserver.com

In this situation someserver.com sees me (my IP) as P3 which is expected, but my ISP should see me connect to P1, P2 and P3 due to SOCKS5 beeing raw TCP so in theory they can clearly see where I am connecting because all the plain TCP connections are made through them and are unencrypted.

Why would the ISP had to get logs from all the proxies to know where I'm connecting if according to what I wrote above they should already know that?

With a regular SOCKS proxy, you're absolutely right. Unless your ISP is only looking at the immediate destination of your packets (which is unlikely), they would immediately see right through it all. That article is only true if the links are encrypted somehow (like Tor does automatically, for example).


Host Based Prevention System definition I'm a little bit confused about what a host-based intrusion prevention system is.
In order to better understand this concept, I'd like to introduce you a case.

Let's say someone designed the following software:

The software must be installed on a host.
The software is designed to protect a single host.
The software checks network packets sent to the host against a set of signatures.

Could this software be called a host-based intrusion prevention system?
If not can you tell me why?

The software must be installed on a host.

Yes, you need to install it :)

  The software is designed to protect a single host.

Yes, by definition, HIDS focuses on a single host/endpoint.

  The software checks network packets sent to the host against a set of
  signatures.

I prefer to quote you this directly from an official and reliable source in this field:

  HIDS work primarily by monitory system logs and behavior and can be
  signature based (include rule sets that enforce tailored security
  policies) or behavioral based. Most organizations use both types of
  IDSs. They use HIDSs to secure critical host systems and NIDSs to
  secure their network(s).

Regarding the description you gave, the answer is definitely Yes.


JWT for authentication and authorization and protecting an API. It's feasible / secure? I'm developing a web application which manages security and hygiene at work so the clients can access information about medical stuff, like exams, reports, accidents, ability to work, things like that.

Info like this is rather sensitive, so I really want to make sure that every piece of info is secure in the best way possible. The web application is developed in Angular 5 and the API is developed in Asp.Net Core 2.0, I'm using JWT to authenticate and authorize a user.

So far in my research, I have found many articles discouraging the use of JWT and others stating that JWT has nothing wrong if used correctly.

Pros

REST API authentication with JWT and CSRF protection for SPA
REST Security Cheat-Sheet ( Not really a 'pro', but helps to
implement)

Cons

Why JWTS suck as session tokens

Things to use instead of JWT

I'm storing the token in a cookie (I know about the XSS and CSRF) and right now I've done this:

Strong password mechanism ( hash and salt with a strong algorithm )
JWT blacklist table in the DB ( to revoke tokens )
The data inside the token is hashed (even if the token is stolen, they have no info from token itself )

And will do in the future :

API accepting requests only from the client URL ( not 'AllowAnyOrigin' )

So, I'm on the right path? Should I stop right now? I've done something wrong?
Any help is appreciated.

Only use JWTs if you are going to use the unique features of JWTs. Use normal session cookies if you just have normal sessions.

JWTs are signed tokens. This is useful if you authenticate at one server and use the JWT at another service. Then signed tokens provide some benefit, since the two servers do not have to share any user data. If you have the authentication server separated from the service that uses the authentication, JWTs can be a solution.

If you are just building a web app, where session data can be accessed throughout the app, there is no real benefit to JWTs, and session cookies work better. ASP.NET has excellent support for sessions with cookies, and I would think it would make the software a bit simpler if you went with that.


Is it good practice to store information about a subkey inside a hash? I recently wrote out a small javascript library that allows you to verify identity server password hashes in nodeJS. While I was doing the research I learnt that the type of hash, iterations and salt length is encoded by adding extra bytes to the final hash that is given in base64 afterwards.

Specifically the order is always the same and by reading the initial 25 bytes of data you learn everything about how the Subkey was encoded. Here's an example including the insertion example.

this.writeNetworkByteOrder(outputBytes, 1, 1);
this.writeNetworkByteOrder(outputBytes, 5, 10000);
this.writeNetworkByteOrder(outputBytes, 9, salt.length);

function() writeNetworkByteOrder(buffer, offset, value){
            buffer[offset + 0] = value >> 0;
            buffer[offset + 1] = value >> 8;
            buffer[offset + 2] = value >> 16;
            buffer[offset + 3] = value >> 24;
}

Is this common practice? Should I try and avoid using the default password hasher provided with identity server? How much is given away by knowing this information?

Why this isn't a duplicate

My question is specifically about the encoding that happens on the resulting hash. This is the base64 hash that is the result of the identity server operation. Providing you know the hash is base64 you can readily read the encryption type, iterations and salt length directly from it. I want to know how or if this is safe and if it's considered good security practice.

TL;DR yes, when it comes to protecting the password on the server it is secure to store the configuration parameters such as iteration count and salt / salt size on the server. As mentioned in the chat session, it is common to do so for e.g. bcrypt, using a different textual format.

The question is if it is secure to store the configuration parameters of the algorithm, not just the algorithm. And yes, this is secure. The configuration parameters do not give any information on the used password, so storing them with the salt (and possibly password hash, for password verification) doesn't leak any confidential information to an attacker.

And just like the Kerckhoffs principle applies to the algorithm, it is also valid for these kind of configuration parameters. Fortunately, if these parameters are changed then the password verification will simply fail.

Base 64 encoding doesn't play a role in determining the security so it is left out of this answer.

For other functions / configuration parameters the parameter may need additional protection. For instance the size of an authentication tag in authenticated encryption (or simple HMAC) should not be altered by an adversary. This could be an issue in protocol negotiation.

Similarly if the iteration count / work factor is communicated to a client (for partial offloading of the work, for instance) then you may want to protect the iteration count against change. But these kind of parameters are generally just available on the server and passwords / hashes send are generally protected by a TLS connection which you should be using.

Personally I prefer simply storing a single version instead of the explicit parameters. The parameters are then specific to a version (hardcoded), so I don't have to parse / validate any information other than the version. This is less dynamic than storing them separately but often complexity is as much an problem as rigidness.


Is it possible to send the user a randomly generated password while still storing it securely in the database? NOTE: I am aware that many similar questions exist on the topic of storing passwords safely, however, I am posting this because I believe it is different enough from existing password storage questions because this question is primarily about how a service can securely send the user a randomly-generated password in plaintext and yet keep it secure on their end (I.e. in the database) instead of storing a user-provided password securely.

I noticed the VPN service I use (PIA) is on the list of plain text offenders, and my biased opinion is that they don’t. Regardless, I’m wondering if it is indeed a good idea for a service like PIA to generate user passwords and send them to the user in plaintext while still securely storing them in a database using best practices as described elsewhere (hashing, salting, multiple iterations, etc).

If I were to implement something like this, my thought would be to make a flow something like this:

User signs up (and doesnt provide a password)
Generate a password and temporarily store it
Transmit the password in plaintext to the user via whatever method
Hash the password and store it in the database
Permanently delete the stored plaintext password and/or overwrite it a bit.

My question is, is it possible to achieve the functionality described above in bold either in a way similar to what is listed above or in a different way?

Note: I am not asking about the security of transmitting the password, just about if there is a good way for the service to keep it secure on their end while still being able to send the user their password in the clear.

The best idea here, to avoid storing the password at all, is to have a key K that only your server knows.
Then when a user signs up, you create a link like:
signup.php?username=xxxx&email=myemail@domain.tld&password=randomrandom&expiry=nnnnnnnnnn&hash=(*)

(*) then consist of sha256(K + ":" + myemail@domain.tld + ":" + xxxx + ":" + randomrandom + ":" + nnnnnnnnnn)

By using this method, you don't need to store anything at all. When user signs up, the only thing that happens is that above link is generated and sent, nothing is stored in database.

When the link is clicked, then the account is created for real. (Of course, you need to recheck that the username is not taken and that the email is not already registred for example)

This ensures that nothing needs to be stored until the action has been fully completed by the user.

You can also have that above link to directly create & login the user (without any initial random password) and have the user select a password on first visit.


Is the overwrite of a Javascript prototype method a XSS attack? I'm looking for a formal characterization of an attack that exploits the prototypical method override feature in Javascript programs. For instance, if an attacker successfully overrides the Object.prototype.toString method, he/she could get access to objects and data that may be thought to be "hidden" in closures, whenever those "hidden" values have their toString() methods invoked.

I created a more elaborated example in which an attacking script leaks sensitive information propagated into the Crypto Javascript API -- see it here in action.

Is this technique/approach a form of XSS attack? If so, is there an established name for it?

You don't seem to be specifying the vector by which the untrusted code is run.  This seems to be a good example of an attack that leverages how hard it is to sandbox / prevent vulnerabilities when loading and executing untrusted code.  While XSS is the most common vector for getting untrusted code to run in javascript, this does not seem to be an XSS.

This is similar to a CERT java issue:
https://www.securecoding.cert.org/confluence/display/java/OBJ57-J.+Do+not+rely+on+methods+that+can+be+overridden+by+untrusted+code


Does removing password improve security? I use a large assortment of software, each requiring it's own password.
Some of these applications remove the password after a failed login attempt, where others leave it populated.

Does it improve security, or is it more of a user interface choice?

This wouldn't improve security, this is entirely a user experience decision.


GPG Web-of-Trust Level (and really sorry for my english)

I have a question about Web-of-Trust of GPG.

Let's say A and B signed each other's public keys and B and C signed each other's public keys. In this case A can trust to C. But, If C and D signed each other's public keys then can A trust D (even if A didn't meet with C)? What is the level limit of web-of-trust?

The default GnuPG trust model allows a maximum length of trust paths of five, which can be configured. From the official documentation:

  A key K is considered valid if it meets two conditions:

  it is signed by enough valid keys, meaning

  you have signed it personally,
  it has been signed by one fully trusted key, or
  it has been signed by three marginally trusted keys; and

  the path of signed keys leading from K back to your own key is five steps or shorter.

I gave further explanation on how validity calculation works in another answer to What is the exact meaning of this gpg output regarding trust?.