Is email encryption, as claimed by ProtonMail, possible? Is it possible to create a Web service that encrypts all messages, such that only the writer, and the person to whom the mail is sent, can read it? In other words, is the theory behind ProtonMail valid?

Strictly speaking it is not possible, for the following reason: if the Web service encrypts the message, then the Web service gets to see the unencrypted message at some point (note: I write service, not server). At best, the service may be honest and do its best not to have a look at the messages at they flow.

Now let's see the claims of that "ProtonMail" service:

Swiss Based. Well, I see no reason to find this implausible. Switzerland is a real country and there are people who live there. However, they suggest that by being a "Swiss service", the data immediately come under the cover of Swiss law, which is a rather bold statement. Electrons don't have a nationality, and, contrary to a piece of paper, an electronic message does not have a well defined geographic position at all times.
Zero Access to User Data. That one is not completely true. When you write your message, you do it in their Web site. Even if all encryption technically occurs in your browser, that would still be done using the Javascript code that they send to you every time you connect to their service. If they want to read your messages without you noticing it, they can.
End-to-End Encryption. This is possible, if encryption is Javascript-based on the sender's browser, and decryption is again Javascript-based on the recipient's browser. Taking into account the pitfalls of doing crypto in Javascript.
Anonymous. I don't believe that one, at least not in the long term. They claim not to log anything; however, experience of past anonymous remailers shows that the logs are the only thing that stands between the remailer operators and jail, in some extreme cases (e.g. if the service is used to coordinate some terrorist actions). Almost invariably, the claim of not logging turns out to be fake after a while. On a similar note, even if the site operators are idealist enough not to log anything, eavesdropping on the network provider side is enough to get a lot of metadata and, e.g., work out who talks to who. This is called traffic analysis. It works well and no Web service can protect against that (only network-wide systems like Tor stand a theoretical chance to defeat traffic analysis).
Securely communicate with other email providers. That one makes me cringe a bit. They mean that when the recipient is not a ProtonMail registered user, they send a normal email with an embedded link to their site, so that the user may download the encrypted email and the piece of Javascript that decrypts it. As they say it, this requires that you previously shared a password with the recipient by some unspecified mean. The bad part here is that it trains people to click on links received by email, and then enter their passwords on the resulting Web page.
Self Destructing Messages. This one works just as well as, or as bad as, copy protections on movies. The raw fact is that if the recipient could read the message at some point, then he can get a copy indefinitely (if only by taking a photo of the screen with his smartphone). The "self destruction" is more a declaration of intent (pleeease don't save this email) than a security measure that can be really enforced. (However, automatic destruction of messages after a time will sure help the ProtonMail administrators, since they store the encrypted emails on their systems and don't want to do that indefinitely, because disk space, though cheap, is not free.)
Open Source Cryptography. That one is believable, and good news. At least they don't reinvent their crypto, but use time-honoured standards (in this case, OpenPGP). (I don't recognize any name in their list of security experts, but I don't know everybody. Effort at transparency is good.)
Hardware Level Security. They don't mean a HSM; they mean that they lock the doors of their server rooms, and use disk encryption. That last bit is weird: weren't the emails supposed to be already encrypted ? What private data remains, that they feel that it should be encrypted again ? This looks like security theatre to me.
SSL Secured Connections. This is very plausible, and very much needed in order to avoid third-parties tampering with their Javascript. Not using SSL would be a killing flaw in their system. Unfortunately, they spoil the effect by adding: "To allow extremely security conscious users to further verify that they are in fact connecting to our server, we will also release the SHA3 hash for our SSL public key". Publishing the hash of your public key makes sense only if people can obtain the hash in an untamperable way; if that hash is simply pushed on your own SSL Web site then you are running in circles. Invoking the magic of "SHA3" reveals the extent of the seriousness of that claim: this really is just some more security theatre (not the least since SHA-3 does not exist yet: right now, FIPS 202 is still a draft). (In fact they published the SHA-1 hash, not SHA-3.)
Easy to Use. For that one, you will have to judge for yourself. "Ease of use" depends on who uses it.

Summary: ProtonMail appears to be roughly the equivalent of using PGP, except that it is Web based, thus centralized. It brings back a lot of issues that PGP was supposed to solve, namely that there is a central server that gets to see who talks to who, and that serves the actual code repeatedly. That central server is thus a juicy target for whoever is intent on spying on people. The decentralized nature of PGP is its biggest asset against attackers; by making it Web-based, they increase the ease of use but abandon that decentralization.

While ProtonMail is certainly better than plain, unencrypted email, it would be wrong to believe it to be the ultimate answer to email security. At least, they made some efforts:

They use existing standards.
They have an explicit threat model. Even if it is not very detailed, at least they know the expression "threat model", which puts them in the top 5% of vendors of security systems.
They try to be transparent.

On a less bright note, I did not see anything related to opensourceness. That is, they say that they use "open source libraries" for cryptography, but they don't actually say which libraries these are; and they don't show their own source code, either. Users are back to having a look at the Javascript code and do their own reverse-engineering, and that does not look very opensource to me.

They also don't actually given any details on their protocol. Since they don't know (or so they say) the "mailbox password" of the recipient, then this begs the question of how they can push an email into that mailbox. We can infer that the mailbox includes a public/private key pair, and the mailbox password is really used to encrypt the private key, not the mailbox itself; this is what would make sense with the information they give (in particular reliance on OpenPGP). But it would be better if they said it. If the protocol is fine then it should be published; there is no reason not to do so. No source and no protocol are very bad points and they really should fix that.

Summary of the summary: ProtonMail's security can be summed up as: their system is secure because they say that they are good guys, honest and all, and they claim to be competent. So that's all fine, eh ?


Android Applications hosted on 3rd party Sites I'm concerned about the number of application stores which have appeared, which are hosting an application (which I post for free) on the Google Play Store.

Doing a quick search for "Android App Store" I get many hundreds of thousands of results, with my application appearing on a large number of them.

Aside from writing an article on my home page, explaining about the risks of downloading Android Applications from 3rd party sites, what else can I do ?

Is it the company behind the application to ensure that the apps are removed? OR is it just a  business risk that I have to accept when publishing applications for Android?

Most of those 3rd party sites are hosted and managed in countries that do not really care about software licenses and/or abuses or any other kind of legal complaint :)

You can always try to contact the owners of those 3rd party application stores, but don't expect too much from it. And also, it'll be a never ending task.

There is at least one thing that you as a developer are able to do. Is making the tampering of your application a little bit more complicated, by adding integrity checks that will trigger a message of warning every time a user opens the application.

Please have in mind that this is also bypassable, but if you perform code obfuscation (i.e. Proguard) in addition to those checks, it'll make the work harder to those people tampering and/or re-distributing your applications.

You must also have in consideration that these recommendations are just mitigations, but you won't be able to completely stop this, as some markets as China completely rely on those 3rd party markets to get the applications. So there will always be someone re-distributing for them :)

Hope I helped a little !


Is this RSA/AES combination good? The team of developers I am part of is trying to develop a safe way to exchange sensitive data between a server and mobile devices.

We have come up with the following algorithm:

Device generates private RSA key, and sends the public key to server.
Server generates unique to user AES key and uses the RSA public key to encrypt it and send it back to device.
Device gets the AES key. Uses it to encrypt password and username and sends it to the server.
Server decrypts the username and password. If there is a match, the AES key is used for secure communication for X amount of time or until log-out. Else, the process must be restarted.

Is it safe enough? Are there ways it can be improved? What are the faults?

Edit: After reading the comments, what is a safer alternative and why?

Edit2: Ok, i get it. I won't use my own implementation, will find something already tried and proven.

All of the weaknesses in your protocol can be summed up as "use SSL" or even "use SSL, dammit !".

In more details:

All the protocol is of course vulnerable to impersonation, specifically the double impersonation that is also known as Man-in-the-Middle attack.
Similarly, if any of potential attackers that can eavesdrop on the line decides to do a modification of the data in transit, then he can, and your client and server will be none the wiser.
Experience shows that saying "encrypt all the data with that key" and then doing it correctly is awfully complex. SSL itself took almost 15 years to do that, and many implementations are still not up to it. Padding oracles, predictable IV, MAC verification timing, verified closure, protection against resequencing and replay of packets...

As an overall assessment: don't do that.


Secure a server on `localhost` such that only the authorized users can connect Consider an application (such as an IPython notebook) that runs an HTTP server, and that (by design!) allows arbitrary code execution by authenticated users (this is the entire point of IPython, Jupyter et al, and is not a bug).

Clearly, it is a disaster for any user to be able to authenticate OTHER than the user the server is running as.

This can be done by ensuring that only the authorized user can supply proper credentials, and by ensuring that these credentials are only supplied to the appropriate server.

I would like to handle this in an entirely automated way.

The ideal solution seems to be TLS server and client certificates.  The problem is that this requires manual, awkward setup.  I want there to be no manual setup – just something that can be run by the server itself.

Note: the server is running as the same user as the client, so it has write access to the directories that the client browser uses to store per-user configuration.  It is not running as a privileged user, so it can't modify firewall rules.

A perfect solution would be a way to enforce a specific server certificate and provide a server-specific client certificate, all controlled (externally) by the server process (which is just a command line program that runs an HTTPS server).

No, the server cannot run as an unprivileged user.  It is really an IDE that uses the browser as a GUI.  It needs to be able to execute arbitrary code with the privileges of the invoking user.  Hence the need for absolutely secure authentication.

Yes, I can reject connections that are not from 127.0.0.1.  This does not help against local attackers by other users on the same machine.

Is this possible, or will I need to embed a browser?  I don't think the Chromium Embedded Framework would help, as it does not handle control of TLS certificate trust.

Assuming you can manipulate the code of both the server applications, simply drop a random value into a file only readable by the running user at startup of the server, then use that as an authentication token (either directly or as the salt for the response to a challenge). You could, for example, set an http password at startup using a simple script and drop the plain text into a file. But like the client cert, the process of getting the data into the client remains manual.

The only way to get this working transparently to the user without rewriting the client would be to configure a web application for use by all authorized users which populated a token into a cookie on the browser, then wrote a server config file which required that specific cookie to connect and which listened on an assigned port then started the server running as the identified user which therefore implies re-authenticating first, using the OS's authentication mechanism. However this means giving a lot of privilege to the master server instance and the complication of integrated authentication. But managing the ports and processes will be a nightmare.

Can't you just give them VMs?


Single Page Application with REST API backend based on XML, queried by dynamic XPath A web application I'm developing will be a Single Page Application (SPA) that will interact with a REST API backend, through jQuery.ajax() calls.

The SPA and API will both be served over an https/TLS connection. The API will be served from a subdomain of the SPA domain:

SPA: example.org
API: api.example.org

... and will respond with the appropriate CORS headers:

Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: GET, POST, etc. // whatever applicable to the requested resource
Access-Control-Allow-Headers: Accept, Authorization, Content-Type

Upon logging into the SPA the user (an organisation) will be served its unique associated sha1 API-key (either in a cookie or as a global javascript variable), that the SPA will use for interacting with the API, for the duration of the login session of the user. The SPA will issue this API-key in each request to the API in an Authorization header:

Authorization: MyAppsApi apikey=<API-key>

The REST API's persistence storage will be XML based. I haven't decided on an actual storage mechanism vendor yet (considering using eXistdb, at the moment). In this early stage of development, however, I'm simply using PHP's DOMDocument and DOMXPath, with no concurrent read/write capabilities.

The REST API will furthermore dynamically generate XPath queries, based on the received request-URI's path. Communication between the SPA and API will probably be done in JSON, though.

Consider this example XML document:

<?xml version="1.0" encoding="utf-8"?>
<organisations>
  <organisation id="1">
    <apiKey>some hex sha1 digest</apiKey>
    <products>
      <product id="1">
        <parts>
          <part id="1">
            <subParts>
              <subPart id="1">
                ...
              </subPart>
            </subParts>
          </part>
        </parts>
      </product>
    </products>
  </organisation>
  <organisation id="2">
    <apiKey>another hex sha1 digest</apiKey>
    <products>
      ...
    </products>
  </organisation>
</organisations>

Currently, this document is validated by a custom XSD schema.

The REST API will first determine if an <organisation> node with the issued <apiKey> exists before interacting further with the XML. If the <organisation> node is found, it will be used as the context node for any further XPath queries.

The request-URI paths will be restricted by the following regex pattern:

~\G(/(?<collection>[a-z]+)(?:/(?<resourceId>\d+))?)(?:(?=(?1))|/?$)~

allowing only /<loweralpha>+(/<digit>+)? segments

Consider these example request-URI paths and their dynamically generated XPath:

/products/1          => .//products/*[@id="1"]
/parts/1             => .//parts/*[@id="1"]
/products/1/parts/1  => .//products/*[@id="1"]/parts/*[@id="1"]

As you can see, they will be relative to the <organisation> context node.

Considering that I haven't fully investigated the typical workings of XML backends yet, it may very well turn out that my above XML setup is flawed to begin with, in that I should create an XML document per organisation, mitigating the risk of accessing nodes that do not belong to the <organisation> context node.

However, do you see any inherent flaws in this current set-up?

In my current set-up I am mostly concerned about the dynamic XPath querying that could turn out to be too risky. Perhaps an adversary is able to sneak in XPath axes, somehow? But I'm interested to hear about any other possible flaws as well.

Thank you.

PS.: perhaps I should have clarified more what the risks are, that I am most concerned with:

Can an adversary somehow obtain the API-key of an(other) organisations?
Can an adversary somehow manipulate content of an(other) organisations?

Your primary problem when handling client-provided is going to be XML External Entities (XXE) attacks. Systems with such vulnerabilities can often be exploited to read files or enumerate the internal network which the server is on. In PHP you can help fix this by calling libxml_disable_entity_loader(true); in order to disable external entities.

Another problem is, potentially, the Billion Laughs attack. This is a CPU and memory exhaustion DoS attack which uses nested element type declarations. This SO question should give you a good idea on how to pre-validate XML before loading it to avoid this kind of attack, but the short answer is that libxml allows you to set a custom DTD validator / loader callback.

You may also want to consider XPath Injection, though I'm not sure how critical this would be in your use-case. It's hard to tell what kind of impact it might have on your system's business logic without having a wider understanding of the application.


Why do Facebook and Microsoft make you enter a code when reseting a password? Typically when you reset a website password you receive an email.

A lot of sites send you a link with a code on the end of it to click on which will take you to an 'enter new password' form.

Facebook and Microsoft have a similar sequence except they send you a code which you need to copy and paste into the password update screen.

Why do they do it differently?

As a countermeasure against phishing emails.

Such emails will look like legit email asking you to change or update your password, but their link will direct you to a false website (still looking as legit as possible, with URL such as micr0s0ft.com: here the letter 'O' was replaced by zeros '0', it looks like "microsoft.com" but it is not "microsoft.com") which will transmit your credential to malicious people.

By requiring you to copy-paste the code instead of clicking on a link, you will have to type Microsoft/Facebook address yourself in the URL bar (or use your usual favorite link), so you are sure that the address is genuine and that you are not being directed to a false website.


How to safely wipe a USB flash drive I want to wipe all residual data left behind even after a format on a regular 64GB fash drive, the ones someone can scan and recover data. What's the most efficient but quickest way to do this? Any test software I can scan for those residual files before and after the wipe?

To quote the ISM (Australia's military standards for cyber security).

  Security Control: 0359; In flash memory media, a technique known as wear levelling ensures that writes are distributed evenly across each
  memory block. This feature necessitates flash memory being overwritten with a random pattern twice as this helps
  ensure that all memory blocks are overwritten.

This means that if you select a secure delete function such as DoD 5220.22M, you will need to run it twice (note that this method only writes randomly through one pass). If you do this it will mean that your data should be safe from the average attacker, however if your USB contains the Colonel's Secret Recipe, or evidence of you committing a serious crime, refer again to the ISM:

  Security Control: 0360; Following sanitisation, highly classified non-volatile flash memory media retains its classification

In other words Destroy it with fire and spread its ashes to the 4 corners of the globe.

If you don't have anything as valuable as I stated above don't listen to the paranoid people on here about how you can never sanitse it, as frankly no one will have the resources to retrieve the data, unless it is a Nation State or a Global Conglomerate.

You may also be interested in NIST SP800-88 Which is American Guidelines for Sanitisation, although I like the ISM as it is much more succinct.


Does credit card tokenization have an expire date? I am reading the tokenization product security guidelines of PCI-DSS but I do not see the time of expiration of the token. Does it have it?

Yes tokenisation does expire, either by date, or by the payment provider invalidating it.

Credit card expiry is usually set for each token and has a pre-set expiry date of 48 months in the case of MasterCard (although payment providers can adjust this), which is a sliding scale and reset during each token use. The token is unique to the card number not the transaction.

It should also be obvious that a card that expires (expiry date met) within that time will naturally expire therefore before tokenisation expiry.

While I know the OP didn't ask, to help others with tokenisation I have added the below for fullness:

The Tokenisation Process

The token is created by the payment provider (the company actually taking the payment) and returned to the merchant (e.g. could be the online shop). The merchant stores this token and replays it back to the payment provider as proof they are allowed to process money on behalf of that card. The payment provider stores the original PAN number (card number) and will only accept the token from authorised calls to use it. The payment provider may well have the PAN stored within a valut that can only be accessed (decrypted) using the authorised users password (e.g. could be an API key). This mitigates an attacker stealing the token and being able to use it. The payment provider can also invalidate the token from their end at any point.

More details here: http://www.mastercard.com/gateway/implementation_guides/Tokenization.html


Is spoofing the origin IP in a TCP header an effective "anonymity" strategy? I know just enough about TCP to know there's a header which, among other things, contains the origin IP and target IP of that packet, which the internet uses to guide it to its destination and then on its return journey (the response).

If I wanted to make an illegal online transaction, could I write the origin IP header to point to some other person's computer, perhaps one I've compromised, then gather the data from that computer later and delete the traces, leading any investigators to the wrong PC and a dead end (once they try to prosecute the wrong person and realize they were tricked)?

This seems like an interesting and simple alternative to running the packets through a series of proxy servers and encrypting the TCP headers via a network such as Tor (which the FBI has allegedly developed a way to compromise). Is this a common / well-known strategy? If so, what are the flaws?

While this is a good idea in theory it can not work practically.
The TCP protocol uses a three-way-handshake, and so when you spoof the origin IP in a packet the packet with the SYN flag (First packet) will be sent but when the destination machine tries to establish a connection by sending an SYN-ACK packet back to that spoofed IP, the connection will fall since the spoofed machine will deny sending the first packet.

P.s: Some routers will not allow the sending of a packet not from the routers IP and drop it already by them and may even notify the ISP...


How can Malware authors be determined? My question is:

How can we make any conclusions about malware authors at all, when anyone could just get sample malware online, copy paste the parts they like, and add their own parts to it?

Obviously there are many types of malware this question would apply too, but I'll use WannaCry as an example. Suspicion was based on a lot of techniques and logic parts used in the malicious files because some were identical to malware used by North Korean groups before.

But during this video the reporter even says that this could be a ruse by some other nation state actor. Seems like any assumption regarding malware authors is just made for political reasons, seeing as no one can guarantee that this one particular makeup of binary data is related at all to one particular group.

I'm wondering if a few lines of matching assembly (see video) is justification enough to release headlines like this, getting the general public on the fence about Cyber War One, when it could have literally been a 20 something year old that had access to any possible spam folder?

EDIT:

I am aware that sometimes certain artifacts in the code can help figure out who might have written it, but in the video it looks like they are connecting a government to a world wide cyber attack based on assembly instructions. This seems different than accidentally leaving the authors address in the whois info, or forgetting to delete the hard coded credentials.

Mainstream media reporting is not the place to go for this kind of stuff. If you look up Symantec's report you'll get a lot more detail. They claim that WannaCry is probably authored by an outfit called Lazarus Group, and specifically claim that this malware does not fit the pattern you might expect from a nation-state effort.

https://www.symantec.com/connect/blogs/wannacry-ransomware-attacks-show-strong-links-lazarus-group

In particular, they say:

The networked command & control infrastructure between this attack and another Lazarus attack is similar, using some of the same IP addresses.
The softwares handle network buffers and network communications in identical fashions, specifically they use some of the same constant values.
The softwares have a large set of repeated strings in the binary.
The softwares generate cryptographic numbers the same way.
The softwares have at least one shared function between them.

What this means is that these two softwares share some connection. Either the same group is responsible for writing them, or they're written by two groups that share code and network infrastructures, or it might be the case that someone has gone to a great length to make it look as though there is common authorship when there is not. It's not practically possible that there is no relationship and all of the above just just total random chance.

Some folks have tried to claim that Lazarus Group is a North Korean nation-state group, but there's not really any evidence to support this. Some of their early attacks were against the South Korean government and Sony, but this is pretty circumstantial. They have attacked non-South-Korean and non-Japanese targets as well.


Storing credit card information - encrypted at rest A client is asking for a way so his app can receive credit card information and store them. He needs this to process scheduled payments from his clients.

I told him that I can build a asymmetrical (RSA) encrypted solution that would store the data and only he would be able to decrypt it if he has the correct key.

The private key would only be held by the client himself. So the system as a whole would not be able to decrypt the information at any point in time.

Would this be a legal solution?
Since the data is always encrypted at rest, would this violate anything in regards to creditcards?
The only way this could leak, is via the key of the client. If he keeps it say, would there be any trouble?

If your client is required to be compliant with PCI DSS, then yes, the card data must be encrypted while at rest.  But, that's the easy part.  The hard part is management of the keys used to decrypt the card data.  There are 90+ pages of things you need to know for this (see https://www.pcisecuritystandards.org/documents/PCI_PIN_Security_Requirements_Testing_v3_Aug2018.pdf).  Your process must be documented, you must keep audit trails, etc.

Most businesses feel that it's much simpler to offload the storage of card data for recurring billing purposes to a service that is setup for this, such as Authorize.Net.  See https://www.authorize.net/our-features/recurring-payments.html.


Is hashing a DLL useful to protect from DLL hijacking? I want to make sure that the dynamic link libraries used by my application can't be replaced with other libraries of the same name, in order to inject malicious code. Therefore, I thought about creating a fingerprint of the DLLs before releasing new application versions.

The application would then validate the fingerprint before the DLL is loaded. Would this provide good protection in the above scenario?

Regarding the hash function: I'm not sure whether or not to use MD5, or one of SHA algorithms. I know MD5 isn't safe to collision attacks, but it is safe against preimage attacks.

Against which attacks should I protect the libraries (using fingerprints)?

It all boils down to how compromised your system is.
If attacker is able to only put/replace your dlls with malicious ones -
probably some sort of digital signature will help to filter our untrusted dlls.

If attacker controls system enough to replace not only dlls, but also your executable -
he can modify code which verifies signature, defeating your protection.

As for .net assemblies strong names - strong name is not for security and must not be
considered as a protection. It can only help to ensure that assembly was issued by a specific
vendor, and not modified since then. Assembly can be modified and re-signed at any point
with different private key (of course, vendor will change in this case). But assembly
will remain valid and signed.

As for hashing algorithm - it is probably fine to use SHA256, it is used by microsoft when computing
hash for digital signature of assemblies.


Could I use a proxy alongside Tor? A user visits a proxy site like hidemyass while using Tor.

What would the implications be of using a proxy within Tor? Would that in theory enhance anonymity by adding another layer of security?

This depends a bit on how the two are configured.

If Tor is the outer connection, then the proxy would prevent the traffic from coming from an exit node; since the list of those is public, this could potentially get around restrictions from a site operator who wishes to block Tor traffic.  It could also potentially serve as a layer of protection against a malicious exit node, as there's no encryption in the Tor protocol at that point; normally TLS (HTTPS) is used for that role, to prevent eavesdropping (e.g. a session stealing attack) or modification of the response (e.g. adding in advertisements or malware).

A free proxy site, however, is likely to be less trustworthy than Tor, though, which makes these benefits negligible.

If Tor is the inner connection, the proxy could be used to bypass restrictions by the ISP aimed at stopping you from connecting to the Tor network.  However, a common proxy like hidemyass is probably also blocked, and bridges are a more direct way of dealing with that problem.

Overall, I think the primary result would be a slower connection, with minor to negative impacts on privacy and security.


Why is it so hard to trace origins of DDOS attacks? According to the July 2009 cyber attacks Wikipedia article, US & South Korean governments suffered a DDOS attack on their websites. However, up till now they have not been able to find any substantial evidence to prove who the culprit is.

Why is it so difficult to prove who did it? No doubt the attackers may have used proxy and a host of other techniques, but this is the US government we are talking about, not some random company.

What possible techniques did these people possibly use to evade detection from the US & South Korean government?

Those DDOS attacks were performed using a botnet. A botnet is a network of consumer PCs infected with malware. Such botnets are routinely used for a lot of activities, most of them illegal or at least ethically questionable. For that reason the people who control a botnet do their best not to get found. They usually control their botnets using obscure methods of anonymous communication which are very hard to track back to them.

You might wonder "considering the publications lately about the internet spying capabilities of the US government, how couldn't they get found?". Maybe the US government is aware who did it, and when they aren't they could easily find out. But the truth is that even though the US government collects bulk data about everyone in the world, the current legal situation does not allow them to prosecute anyone based on that data. All that data collection is illegal wiretapping, so it may not be used as evidence in court.

The only thing the US government can do against people they only have evidence against through their surveillance programs are illegal extrajudical actions like kidnapping them and deporting them to a secret prison or killing them through a drone strike. Such drastic actions are currently only performed against people who are deemed a danger to national security (or live near the Afghan/Pakistan border).

And contrary to what some "Hacktivists" believe, making a public website of a government agency unreachable for a few hours, is not an attack on national security. Such an attack is about on the same danger-level as drawing an defamatory graffiti on their wall.


Peculiar Japanese DNS arrangement I have been receiving spam emails on my many mails but specifically gmail from a .jp domain. I deleted the emails but today I decided to actually read one of those emails to see if they can send me my inheritance from this Nigerian prince via PayPal.

Anyway, I noticed the email was from a Japanese domain and I decided to follow the top level domain.

These are the screenshots:

and

I went ahead and opened ne.jp and that redirected to www.ne.jp

That's where it got interesting and I now suspect they have no idea they are among the top mailers of spam worldwide.

The page reads:

  About www.ne.jp

  The name of this domain is www.ne.jp, NOT ne.jp. Japanese domain
  names, like those of many countries other than the United States,
  consist of three parts rather than just two (compare a typical
  American domain like "aol.com"). We just happened to register the word
  "WWW" as the private part of our name -- the Japanese equivalent to
  the US domain www.net. In other words, the "WWW" part is not simply an
  indicator of where the home page resides, as in most cases, but is
  actually the name itself.

  Thus, if you are searching for information about a domain name of the
  form foo.bar.ne.jp, where bar is not "WWW", you've come to the wrong
  place. In particular, if someone has attacked you or spammed you from
  such a domain, it has nothing to do with us. You can find more
  information about the real culprit by looking up the name bar.ne.jp in
  the WHOIS database at JPNIC, the Japan Network Information Center.

From the page,

  ...In particular, if someone has attacked you or spammed you from such
  a domain, it has nothing to do with us.

Why do they say that while the mail outpost@alpha.ocn.ne.jp is part of ne.jp?

ne.jp is not a domain name. It's a second-level TLD, similar to co.uk.

outpost@alpha.ocn.ne.jp is an email address under the domain alpha.ocn.ne.jp, which is a subdomain of ocn.ne.jp -- a large Japanese Internet provider.


Preventing millions of requests to Amazon s3 bucket I developed an open source library and hosted its assets on Amazon S3 (CSS, JS), these files were used in demo via URLs like: http://my_bucket_name.s3.amazonaws.com/some-file.js (my bad, I know).  Without my permission some websites started hot-linking these files.

It was fine for a while, but recently a few NSFW sites hot-linked it and I get tens of millions GET requests in a month. So I deleted/moved these files, but I still get a lot of GET requests that return 403 errors, and Amazon bills them as a valid requests (see Charge Details section).

What should I do to avoid getting billed for error requests that I don't make?

Thank you for advice.

About deleting the bucket - you're right, if someone else creates the bucket with the same name it will get all your traffic.
As you don't want to delete the bucket to prevent abuse - I think it is best to open the ticket with them and see their stance on that. If they care, great - they will find a solution, if they don't - why should you pay for their ignorance ?
In my dealings with their support regarding (other) security/abuse related topics they actually were quite responsive and helping.


derived key from email + password? When deriving a private key from a password, will the resulting secret key be any weaker if the user email is included in the function input? Meaning, user email concatenated with the user password.

I'm using scrypt for key derivation, with libsodium in the browser and on the server.

I would recommend using a more established system. If you would like, gpg could definitely be used as it allows for distributed identities, provides email correlation, and is far more secure than you trying to build your own home grown solution.


Privacy in P2P vs relayed connections for VoIP I'm developing some sort of VoIP application for mobile devices for fun.
I initially planned to rely on P2P connections only.
I didn't want to use a relay server because I thought (1.) there would be a higher latency and (2.) this would reduce privacy/be another potential risk if not maintained properly.

However, just thinking about this again, I wonder whether using a relay server in the middle doesn't actually add a layer of privacy since it would be less obvious where the packets are being sent - all packets would go to the server instead of being sent straight to the other device. So the only thing someone could know when intercepting the traffic between one of the devices and the server is that there is a connection between that device and the server (provided that the actual UDP/TCP payload is encrypted or unreadable for someone intercepting the traffic).

So unless there's only two devices sending packets to the server it would be more difficult to find the peer connection.

Is this assumption correct?

If it is, is there a way/are there any known techniques to obfuscate the source/destination when establishing P2P connections, specifically when using IPv6? By this I mean somehow hiding/changing possibly identifying information such as the IP & port number.

I wonder whether using a relay server in the middle doesn't actually add a layer of privacy since it would be less obvious where the packets are being sent - all packets would go to the server instead of being sent straight to the other device.

It adds different kinds of privacy. You have (mainly) two kinds of privacy here:

Privacy from provider
Privacy from other users.
Privacy from someone with network level access (ISP, government)

A P2P architecture can be implemented in a way so that the provider is only involved in the set up of the connection, and doesn't need to know for how long you communicate, if you use video etc.
However, a P2P-structure will leak info about users to other users. This may or may not be an issue. In many cases, users communicating will know each other, and will prefer not leaking information to a provider over leaking information to whomever they're talking with.
However, if you're a Chinese dissident using a non-national service, it's probably preferable to leak information to the provider over the other user.
It will affect latency - especially if the two clients are otherwise close (e.g. same cell phone provider and country), but the server is 50ms away.
Signal gives the users a choice:

I believe this is the best solution, especially if the users are educated on security. They may make their own trade-offs based on what value they place on the various aspects. For me, the quality penalty makes me stick to P2P. This is based partially on the fact that I'm in a politically stable region with a very strong freedom of speech.
To protect against someone who can do network level eavesdropping, it should be impossible to correlate streams.
Now, if clients communicate P2P, it's absolutely trivial to work out who communicates with whom; the streams are direct.
If they go via a central proxy, it's harder, but probably not impossible to correlate streams in time, based on size and frequency of packets. There's been research on unmasking tor users based on this.
In short, you have multiple different kinds of privacy worries. Some of them are mutually exclusive. Different users will have different needs of anonymity. A dissident communicating with peers may want P2P, to avoid any central servers that can be targeted. The same dissident, when recruiting other dissidents, may want a centralized server - as that makes locating them harder.
When I'm talking with friends, I don't care if they know who I am; they alread know, so P2P is just fine. If I'm selling drugs, I probably don't want people to get my IP address.

If it is, is there a way/are there any known techniques to obfuscate the source/destination when establishing P2P connections, specifically when using IPv6? By this I mean somehow hiding/changing possibly identifying information such as the IP & port number.

No. IP packets require source and destination. Port number may be choosen freely.
The technique for obfuscating IP is using a proxy (as you are suggesting) or a VPN.


Snort false positive, yet suspicious I have Snort installed and tuned nicely with ET Rules on my pfSense,
both my pfSense and the modem are using Googles public DNS 8.8.8.8.

Recently I was denied access to google.com, and by reviewing the logs,
I found the following records in the blocked list for the same IP:

ET INFO Possible Chrome Plugin install
SENSITIVE-DATA Credit Card Number

I did  suppressed the offending IP for further investigation which revealed it's one of my ISP IPs with ports 80,443 and OS Fingerprint CPE: cpe:/o:freebsd - nmap tells.

A traceroute to the offending IP ends on hop 10 with a virtual/private IP,
apparently a router in the AS system of my ISP with transparent proxy "?"

Later on I tried to access the offending IP from my web-browser and I got redirected to google.com.mycountry

Now I'm confused.
Could this be a Snort false positive?
Is there anything i should be worried about?

It seems to me it's possible snort was doing its job.

ET INFO Possible Chrome Plugin install

The above rule detects when a chrome extension was installed. So perhaps you installed one from google.

SENSITIVE-DATA Credit Card Number

The above rule matches any number in a packet that resembles a credit card. Perhaps one request you made contained a sequence of numbers that looked like a credit card.

The next questions
- verify each happened (what extension ? What number ?)
- do you want to monitor these rules ? Perhaps turn them off
- if left on , should they be blocking or just alerting ?

Snort rules require a lot of maintenance and tuning


AES/Rijndael Encryption Does block size matter for security? Would AES with a 256-bit block size be more secure than a 128-bit block size? I'm curious if block size really makes something more secure.

I'm dealing with a third party to use their API and they require a 256-bit block size Rijndael encryption but I can't find many libraries that do that for Ruby since AES traditionally uses 128-bit block size. I would think the mode matters more right? If so then I worry that the third-party isn't using a safe encryption technique as they are using ECB. Just looking for general clarifications here.

Block size does matter for security, but only up to the point where there is no possible attack with plausible technology. In a nutshell, an n-bit block cipher is safe for use with up to a little less than 2n/2 blocks of data encrypted with the same key. The n/2 figure comes from the birthday paradox: that's when you get a macroscopic chance of repeat values if you draw blocks at random. For a 64-bit block cipher, that means you must not encrypt more than a few gigabytes (264/2 blocks of 64 bits is 32 GB). Sweet32 is an example of a concrete attack against a cipher (3DES) due to its small block size.

AES has a 128-bit block size (regardless of the key size). This is safe up to exabytes of data encrypted with the same key.

For more information on how AES's block size was chosen and some examples of attacks that are practical with a block size that is too small, see Difference between Rijndael 128 / 256 blocksize implementations? (and impact of block size in general).

So there is no security benefit to “AES with a 256-bit block size” compared to regular AES. Worse, “AES with a 256-bit block size” has security problems that regular AES doesn't have.

The first problem is that “AES with a 256-bit block size” does not exist. AES is a 128-bit block cipher. All there is is Rijndael with a 256-bit block size and whatever number of rounds. Since it is not standard, most cryptography libraries do not implement this 256-bit-block variant. This limits you to a few implementations or possibly a home-grown one, instead of implementations that have had solid scrutiny and are actively maintained. For example, you may have a hard time finding an implementation that has been hardened against timing attacks and other side channel attacks — in cryptography, getting the correct result is far from the only requirement.

Another problem is that AES specifically has had more scrutiny than Rijndael in general. It's possible that some attacks only apply to a specific set of parameters, for example a specific block size. A known example is that related-key attacks (which do not matter in practice) are markedly worse against AES with a 256-bit key than against AES with a 128-bit key.

A third problem is that since the parameters they're using are non-standard, you have less confidence that these API designers chose the other parameters securely. In particular, a larger block size requires more rounds (Rijndael proposal, 7.6). If they kept the same number of rounds, or worse if they chose a lower number of rounds to compensate for the lower performance of larger blocks, this could make the result easier to break. There are known attacks against AES with a reduced number of rounds, which no one knows how to use to effectively break the full number of rounds, but which might apply to a Rijndael variant with custom parameters.

All the risks of using a non-standard Rijndael variant pale against the use of ECB. Using ECB shows a basic lack of understanding of cryptography. The classic picture where patterns are clearly visible is just one of the problems with ECB that happens to be easy to illustrate graphically. Encryption without authentication also tends to allow a large class of attacks called oracle attacks, where the attacker sends encrypted blocks without knowing their content and observes how the party with the key behaves. What oracle attacks might be possible depends on the protocol, but ECB is not randomized (no IV or nonce), which tends to make such attacks a lot easier.

In a nutshell, the use of non-standard cryptography and the use of ECB are both red flags against the security of a product.


Implementing 2-step verification via email for web apps? I was thinking of applying 2-step verification to my web apps that will work similarly to Gmail's SMS/voice 2-step verification, except my web app will just email the verification code each time a user logs in.

I was wondering is this a good practice or is it still vulnerable? I ask because no one seems to implement this. For example Paypal uses a gadget while Blizzard uses a Smartphone app for their 2-step verification. I think they could also use email verification codes instead but they don't. Any problem with email?

See If I include a Forgot Password service, then what's the point of using a password?.  That question considers whether we can use a "I forgot my password; please email me a reset code" function as the main way of logging into your account.  The issues are similar.

In particular, the primary drawback is that, from a usability perspective, it may be annoying to have to wait for the email to show up each time the user logs in.

From a security perspective, it is (in my opinion) a reasonable approach, though not perfect.  The primary security drawback is that the user's email account becomes a major risk: if the user's email account is hacked, the attacker may be able to gain access to the account (e.g., if the user uses the same password for the email account and for their account on your service).
Moreover, the way you handle password reset becomes security-critical.  If you follow the standard practice of just emailing the user a reset link, then you've created a major weakness in your system: this makes it easy for an attacker who has compromised the user's email account to then steal the user's account on your service, with no guessing, by using your password reset process.

By the way, this is not really 2-factor authentication.  Don't expect this to provide the same level of security as true 2-factor authentication, like Google's SMS/voice verification.  For instance, if someone gets access to the user's computer (e.g., the user's computer is stolen; the user's roommate is playing tricks on the user), then that person will be able to get access to the user's account on your service.

P.S. See also What problems does this “recover account” procedure have?, Password sent via email upon registration, Email forgotten password or send reset link, both just as insecure?.  And I recommend using SSL sitewide if you can.


Which of the TLS/SSL and IPsec protocols is effective? Which of those two protocols is the most effective for sending data from a client to a server on a local network (knowing that I aim to use it for FTP traffic)?

Both will do what you need effectively.

Whether you need to use one over the other depends on your use case. From what you have described, as long as there aren't other requirements, I'd go with TLS, as it requires very little additional work on most network architectures.

IPSec is just a little more convoluted to set up - but it does provide additional security options.


What to do when a connection to a government website for submitting personally identifiable data is not encrypted? I need to apply for a new passport, but my government's official website for submitting applications containing personally identifiable data does not use HTTPS — http://passport.gov.in/nri/Online.do

Normally, if a website is insecure and I don't need to use it, I simply won't use it or will find an alternative that is secure. In this case though, I'm at a loss — I need to apply for a new passport and I don't have an alternative because this is the government's only website. The form contains extremely sensitive & private information — pretty much my entire life history — and it would be a great loss if it were leaked.

How does one approach such a situation from a security perspective? Is petitioning my government to upgrade their security practices the only option?

P.S. Sending in a paper application is not an option, because the information needs to be sent to India somehow and the processing contractor will simply re-upload the data using the same insecure website. That is if they haven't rejected a paper application in the first place.

Simply use the https version of this site which you can do by simply replacing the http:// in the URL with https://. It works and the site has also a valid certificate. And I don't know how you got to this site but if I search in google for 'Online NRI Passport Application' I actually get the https site as first result.


SmartCard Key Extraction / Alternatives (1) As it is possible to extract the secret key from a SmartCard using laboratory equipment, I wonder if there is any (new) way to protect against this sort of security breach? Does it affect all kinds of SmartCard?

(2) Do eToken/ crypto-token resist such key-extraction attacks? Would the PIN lengh make any difference?

(3) Is there any alternative available (similar to smartcards) with better security that is secure also when the attacker steals them?

A smart card is supposed to resist physical tampering.

Heavy hardware such as HSM and payment terminals use active protections: basically, their "secrets" (e.g. private keys) are stored in a SRAM module, with a battery, and they are never completely "off". If they detect a physical breach (there are many sensors inside the box), they proactively destroy their secrets.

Smart cards don't have room for such a battery, so their protection is mostly passive. However, some also keep their keys encrypted, using the PIN code as key. This is an extra layer which tries to thwart physical attacker who opened the case and are ready to plunder the EEPROM/Flash in which the card keys are stored. However, user PIN codes are rarely strong enough to make this encryption much of an obstacle.

For smart cards which use PIN-based encryption in addition to the physical shielding, the PIN entropy can matter (not the length, at least not directly -- secrecy of the PIN depends on how random it is, not on how long it is), but only if that entropy is high enough to be non-negligible. Think "passphrase" here, not PIN.

Smart cards achieve a resistance up to a (rumoured) breach cost of about 5000$, for a 5$ hardware cost. That's a 1000x factor, which is not bad when you think about it. I am not aware of tokens which do better. If you search one (there are many products on the market), look for active protections (with an inner battery) and certifications like "FIPS 140-2 Level 3" or "EAL4+" (certifications don't guarantee robustness, but they signal that the vendor, at least, put significant money on the subject).


John stdout to Hydra I'm trying to use a John ruleset which seems to take up more space than I have available. Is there a way to pipe John into Hydra?

Hydra does not read from STDIN. It's like ramming your hand in a hole that isn't a hole.


What makes SoftHSM more security than other software solutions such as OpenSSL? I see many people using softhsm just for encryption / decryption rather than using openssl.When I ask people they reply softhsm is more secure. Can anyone say in what ways softhsm is more secure.

SoftHSM does not do the same functions as OpenSSL. People aren’t “choosing” SoftHSM over OpenSSL, as they do different things.

Note that SoftHSM can be linked with the OpenSSL libraries to implement the cryptography internally, meaning that at best its overall security can be no better than that of the OpenSSL libraries themselves.

SoftHSM is also not more secure than an actual Hardware Security Module (HSM). Any keys stored in it are visible in some way to the host computer. By contrast, an actual HSM is designed with physical security in mind, and it will not allow a key to be exported or exposed. For example, an HSM is equipped with tamper-detection circuitry such that it will destroy any keys it contains rather than allowing someone to open the case and sniff out the keys with a logic probe.

Any differences you are seeing in use between using SoftHSM and a true HSM are almost certainly due to cost. SoftHSM is an open source implementation of a PKCS#11 service, and costs virtually nothing to test with and use. A true PKCS#11 commercial HSM can cost many thousands of dollars, and have even more costs for licensing, support contracts, installation, etc.

If you need to test a piece of software against a PKCS#11 server, SoftHSM is a cheap way to accomplish your task. OpenSSL doesn’t offer a PKCS#11 interface, so it’s not like they can use it as a substitute. But never think that SoftHSM is as secure as an HSM.


Verification of Python(x,y) installer I'm an Aerospace Engineer just starting out in my field, I'm planning to start using Python, but I've run into a bit of a conundrum. I downloaded Python(x,y)-2.7.10.0.exe Windows installer from here (I found that link on the Official GitHub page), but the executable is unsigned.

Is there any way to verify the authenticity of the executable? Anybody else used this and had problems?

Answering to your question and comment:

If you think that the mirror you used could have been compromised, you can download the file from the other 2 mirrors available there and compare the hashes (md5 or sha1) of the downloaded files, the probability of all three sites being hacked is not very high and could help you to feel safer about it.
Checking the official website, I found the History section, here you can find the names of the developer and the maintainer.

If you search for these names on Google, you will be able to find their personal profiles, you can ask them if they provide signed binaries as @Arminius said,
or ask them to provide you with the original file, also you can ask them the hash value to compare with the file that you downloaded.

Gabi Davar (Maintainer since 2011):

LinkedIn
Stack Exchange
Github
Google+

Pierre Raybaut (Original Developer):

Twitter
Github

Hope it helps.


Does a bitlocker pin become part of the key? I recently added a pin to my bitlocker encryption and this seemed to be pretty much instant. In what way is this pin an actual part of the key that is needed to decrypt the hard drive? Or is it used to decrypt the actual key itself (in combination with information from the TPM) before decrypting the actual hard drive?

Bitlocker uses an encrypted key stored on the disk, wrapped with one or more encryption keys.  This could be a key stored in the TPM, protected with the PIN, or the full Bitlocker encryption passphrase (startup password).  Which keys are available depends on the configuration you have setup.

I'm not aware of any FDE scheme that derives the actual encryption key from any user input (passphrase, PIN, etc.).  Doing so would make it impossible to change the passphrase without re-encrypting the data, which is time consuming, not great for SSDs (wear leveling) and not to mention the mess created if your computer crashes mid re-encryption!

For example, Truecrypt has a header area including the master key that is encrypted with another key derived from the passphrase.  PBKDF2 is used on the user passphrase to derive an AES key.  This AES key is used to decrypt the header and receive the master key, which encrypts all of the data.  If the passphrase is changed, only the header needs to be re-encrypted.


Can you extract memory contents from a hibernated Windows machine? In a recent discussion about hardware hacks, attacks surrounding Windows hibernate popped up. I am not entirely convinced that it would be viable to get stuff out of the memory saved to disk.

When Windows hibernates, it puts the contents of RAM to a file on disk (and maybe other stuff too, I don't know) and then turns off. When it turns back on, I'm assuming, it pops the saved RAM contents on to the actual RAM itself.

So a hypothetical attack would be to either steal the saved disk file, thereby stealing RAM contents, which may include sensitive data such as passwords, or do a memory corruption by changing the RAM contents, by adding/editing instructions so that arbitrary code is executed.

Now, I know that an attacker having physical access to a machine can do just about anything, but taking these specific attacks into consideration, is this at all possible? Assuming there is no disk-wide encryption, does Windows actually encrypt the saved RAM when it hibernates?

Also, does anyone know where this file will be stored? So that, I can try hands-on to view contents of the disk, maybe using a LiveCD?

Yes, it does store it unencrypted on the disk. It's a hidden file at C:\hiberfil.sys, which will always be created on any system that has hibernation enabled. The contents are compressed using the Xpress algorithm, the documentation of which is available as a Word document from Microsoft. Matthieu Suiche did a comprehensive analysis of it as a BlackHat presentation in 2008, which you can get as a PDF. There's also a tool called MoonSols Windows Memory Toolkit that allows you to dump the contents of the file. I don't know if it lets you convert back, though. You might have to work on a way to do it yourself.

Once you've got the data out, it's possible to extract or modify data, including instructions. In terms of mitigation, your best solution is to use full-disk encryption like BitLocker or TrueCrypt.


Unauthorized credit card payment I have a debit card which links to my savings account in a let's call it Bank A. I had never used it for online purchases/transactions (not even interbank transfer). After a while, I purchased virtual credit into my online wallet from an online gaming platform. During the purchase I had to provide my debit card details (number, CVC, expiry date) without authentication. Normally I will receive TAC to confirm the transaction but in this case I did not.

A few days later, I was called by Bank A saying my debit card was frozen due to suspicious transactions (amounted to roughly RM 1xxx) but failed to process due to I had only RM 2xx in my bank account.

Now I am afraid that websites might use my bank details to perform purchases. Will this be the case? Is it true?

TL;DR: Report that your card has been compromised to your bank and ask for a new one.

You are the victim of a credit card fraud. Your bank (Bank A) noticed a suspicious activity with your debit card and froze it.

As techraf said, report that this activity was indeed fraudulent to your bank. If some unauthorized transactions were approved, you can reclaim your money. Your bank will send you a new credit/debit card.

As soon as the card is frozen, nobody is able to use your card details anymore. Your new card will have new details, thus you won't have to worry about the previous one being compromised. It won't affect the new one.

We can't tell how your current card has been compromised. Perhaps the website is not as trustful as you though, or perhaps something else happened, like:

Someone saw your card and wrote down the relevant information;
The website uses HTTP to transmit your card details to the server;
Your computer is compromised;
An in store credit card database leaked
…


Can a TCP connection be terminated by an attacker if SSL/TLS has been used to protect data in the TCP segment? I understand that SSL/TLS is built on top of TCP. That is after a TCP connection is established, an SSL handshake can be started, when it is completed, all communication will be encrypted and authenticated. To close the connection a specific alert is used.

I would like to understand whether an attacker is able to terminate a TCP connection if SSL/TLS has been used to protect the data used in a TCP Segment

I have found this...

  If an attacker tries to terminate the connection by finishing the TCP
  connection (injecting a FIN packet), the communicating parties will
  know the connection is improperly terminated. The connection cannot
  however be terminated, only interrupted.

But I would like to know how the communicating parties would know the connection is improperly terminated and why it is only interrupted.

Furthermore, is the injection of a TCP FIN message the same as injecting a TCP RST message to tear down the connection?

Any thoughts?

This is entirely doable, with the caveat being that you need to know the correct sequence number required by the target tcp stack. (so to be able to do it for all connections to a server, you have to be either on the server itself or a gateway to that server).

Note: the farther you are from the target stack, the more likely it is that you'll have timing issues with the injection. (presuming it's a packet injection and not a full mitm)

I also know from experience that such intercepts are swiftly broken with a small security update to the target stack :(

Rst and fin will be relatively closely guarded, it may be worth looking at just setting the tcp window size to zero instead? (just a thought, been a long time [a decade now!]  since I played with this stuff)

  ..but I would like to know HOW the communicating parties would know the connection is improperly terminated and why it is only interrupted.

The whole point of tcp it to provide reliable connections, if you kill the connection then the stack on each side knows. It's only interrupted because when the connection dies most systems will retry the connection, usually  without even telling the user.


Can I spoof IP addresses when attempting to brute force a login? I am testing my website with hydra brute-force software. But accessing my apache conf remote server file, it seems that an attacker can't log-in more a limited number of times per seconds. Does hydra systematically uses the same source IP to log, or can it spoof the adresses in order to attempt multiple logins alledgedly coming from numerous sources. If not, how can I test a brute force coming from several sources ?

When making a connection to a webserver you make use of the TCP protocol. It is a stateful protocol and requires a hand shake to set up.  The handshake is set up in three messages:

a SYN message from the client
a SYN+ACK message from the server
another ACK message from the client

Only after this is done you can transmit data. The problem with IP spoofing is that the SYN+ACK message will never reach you and you will not be able to send the ACK message in reply. This makes the handshake incomplete and you will not be able to send any data. Furthermore when bruteforcing the login screen you need to get a reply from the server that you logged in successfully.

Even if you do not take into account my previous statement  about TCP (for instance technologies which use UDP). If you spoof your IP the server will reply to the random IP and you wouldn't see the data either (unless you are on a hub like device or network and sniff all traffic AND provided the target device is on that same network).


Is it secure to transfer certificates from Service 1 to Service 2 over HTTPS? I need to transfer SSL certificates (including their private keys) between two services over HTTPS.

For example, service 1 makes a PUT REST call to service 2 over HTTPS.
Request Payload = The certificate including the private key.

Is that secure? Is there a more secure way to transfer certificates?

Let's restrict the question to network traffic only, so we treat the machines themselves as safe. Additionally we treat the TLS version used as safe (be sure to use the latest, as there were some bugs in previous versions).

The security of HTTPS consists of two parts:

Authenticity: If both clients already have some sort of certificate known to the other side or one signed by a CA both sides trust (or a securely implemented token mechanism, like in your example), they can assume, that the client they are connecting to, is in fact the one it claims to be.
This is assured by digital signatures, which we treat as secure at the moment (assuming proper hash and cryptographic algorithms are used, like SHA256 and RSA-2048 or more).

Encryption: The security of encryption depends on whether both sides can trust the keys being used. Assuming that neither side leaked a private key, it's safe to assume that nobody except those two clients can participate in the initial key exchange. The digital signatures mentioned above guarantee that the asymmetric keys belong to the other side respectively, while the asymmetric cryptography guarantees that only the owner of the private key can read messages.

If these conditions are satified, both sides can securely agree on a shared secret for this HTTPS session, without anybody in the middle being able to compute the same secret, even if he/she reads all packages being sent.

Edit: Using the method you added to your question, this transfer should be safe (be aware of the conditions above). Be sure that BOTH sides provide a way of authenticating themselves respectively. If the Service A connects to Service B (which is server-side in this example), A checks the certificate of B. They are able to establish a secure connection, but B can't be sure that A is who it pretends to be.

This is where your (hopefully secure) token system should be used. You may also use some other way of authentication but be sure to use one, as this could be a serious problem. An attacker being able to import his own certificate into Service B... I say no more ;)


Yahoo mail hacked - how to recover, how did it happen and how to prevent? I was yesterday informed by some friends that they received spam mails with my name as sender. The sender addresses look like firstnamelastname@spacepc.pt and firstnamelastname@revistaplot.com with the subject line "from: Firstname Lastname" and the mail containing only a link and my name as signature (and one mail also stated "Sent from my iPhone").
It seems like the mails are not sent from my Yahoo mail (as the sender is not Yahoo and they are not in my sent mails folder), but the list of people receiving these mails has to come from my Yahoo account as I only have mailed with them from Yahoo! Note: they are not from my contact list! It looks to me that the addresses come from my sent mail folder as one receiver is listed twice, once with the correct mail and once with a typo I made when typing the address some months ago. The list has to be extracted between April/May and yesterday which I can say for sure because of some of the recipients which I did not mail with before that time.
I have changed the password and security questions asap and checked also the alternate email address, cell phone, website connections and account activity but could not see anything fishy. The account activity goes back to 8th of July and there was nothing I could not explain.
Some questions:

I read about this XSS hack from 2012/2013 but thought the hole was closed. Is it still open?

The last couple of weeks I almost only used my iPhone for online activity. Could it be that there is some virus/malware on the phone? I only downloaded apps from the official Apple store!

Is it enough to change the password and security questions or should I take some further steps?
Note: my password was strong with both upper and lower case, numbers and special characters and was changed 6 months ago. Only mistake: I used the same password on a couple of other (trusted) sites.

How could did this happen? I am nearly paranoid when it comes to security and I did not click on any link in any email (I even cannot recall receiving some strange mails lately).

EDIT: Found this article today Hackers exploit flash vulnerability in Yahoo Ads
Even though the article does not say a word about this kind of attack I was exposed to this might be an explanation! I swear that I did not surf around on shady pages :)
Next question: how can I make sure that my PC is clean? When the attack was run I was using my Win7 laptop (even though the mails were sent while I was offline). I am now writing from my Linux comp as I do not dare to turn on the Win7.

I used the same password on a couple of other (trusted) sites.

Maybe you do not want to reuse the same password for important sites, like Email

See also this Dropbox story. And XKCD at the bottom of the answer.

Email can be easily forged. If one of your friends let you look at the mails "from you", there are certain headers that should indicate whether the mail was really sent by Yahoo or not. Have a look at why-is-it-even-possible-to-forge-sender-header-in-e-mail.

For the rest of your questions:

  I read about this XSS hack from 2012/2013 but thought the hole was closed. Is it still open?

Very unlikely that they keep an exploit from 2012/2013 open until today. There are ways to mitigate XSS attacks. In case you use Firefox on your main PC, have a look at noscript. (as mentioned in the answer to the question you probably meant)

  The last couple of weeks I almost only used my iPhone for online
  activity. Could it be that there is some virus/malware on the phone? I
  only downloaded apps from the official Apple store!

While Apple offers some tight control over what they accept as apps, there are exploits from time to time. Hard to tell from a distance. The shared password seems a more likely attack vector.

  Is it enough to change the password and security questions or should I take some further steps?

Using a separate password is a very good step. Depending on your level of paranoia, 2-factor-authentication might be a way to go. Do seriously consider noscript.


How to store passphrase in this situation? How to store a passphrase with a Java application that periodically needs access to its plaintext form? It is a strange situation, but I am wedged in it. If providing a decent security mechanism is impossible, any tips on deterring script-kiddies?

Elaboration on my situation (it rhymes):

It's an inconvenient (read "horrible") situation where the application will be accessing a remote http (not https) service, passing a login/password in plaintext, a few times a week. Yes, ideally I would change service, but I can't do that. Given that, my question is on how to store the login, which the application needs to be able to access in plaintext/unencrypted form. Is there a more secure or at least script-kiddies deterrent solution than just hardcoding the plain values?

Elaboration 2:

This is a server app. I might have the option to host it on a Java EE app server, I am not aware of benefits it provides though. At the same time I am equally interested in how I could deal with this outside a JEE app sever.

First, the login should be issued per-client, so it can be changed if leaked, or cancelled when a client's access to the service is revoked. This reduces the consequences of loss of the password to the smallest size, instead of losing everything when one client is compromised or goes rogue.

Once you have done that, your problem is simply to store a password which is used for this one client with this one service. This is a well-known problem with well-known solutions. Essentially, you should assume that the operating system is secure. (If it is not you have bigger problems.) So save it into a file, the registry etc, and protect it with an ACL. If you wish you can add obfuscation on top of that, or use CryptProtectData or similar, which can provide some protection against unsophisticated attackers.

But the bottom line is you need to accept that issuing, revoking, and resetting credentials is going to be a normal part of your operation. You will also want to monitor usage of the service so you can detect when credentials have leaked.


Problems with getting reverse shell I got a badUsb, my current solution is: it downloads netcat.exe and establishes a netcat connection between test-box and me with the help of localxpose tunneling (when I'm not in the same network).

The huge problem with this is that localxpose generates a random port every time i run it, or change networks, or lose connectivity... so I'd have to recompile the badUsb every time..
Is there a tunneling service that lets me reserve unique names instead of ports, like serveo.net allows for ssh? Because that way I have a static address to netcat to.

OR, do you suggest I use something other than netcat for the reverse shell? Is it  possible to download a small ssh.exe file and run ssh on the test-box, because then I'd use the oh so lovely serveo...
Thanks.

EDIT: I found out I can use serveo.net for more than just ssh... doh. Current solution: ssh -R REMOTE_PORT:localhost:LOCAL_PORT serveo.net

This way I can at least choose the remote port and use the same one every time, that is if someone else doesn't reserve it?

Solution: serveo.net can be used for tcp ports as well, not just ssh, and ssh can be used for tunnelling.. my bad.

I used ssh in par with serveo.net to reserve a static port on serveo.net which is a tunnel to my local server. Problem solved.


Using SSLStrip, password is still encrypted I did SSLStrip on my network (for educational purpose only!)
And I've got the username and all.

system=Test&uid=dixon01&__password=hkulqlyhza&command=login&password=320dd485b1834cf8%7C%40%7C0bf892a5b7dbf901%7C%40%7C5e5f2722f2ed1cc0%7C%28%23%29%7C

The ssl works, the connection with the website is http, but the password is still encrypted? Is the password counted as encryption? Or is it just under some encoding?

SSLStrip is a transparent proxy that is used to prevent the victim of a MITM attack from uing SSL by clicking on an SSL link. To achieve this SSLStrip replaces all links that start with https:// with http://. The Idea behind this is that most users arent aware of encryption and just use encryption becaue the owner of the webpage links or even redirects them to the secure version of the webpage.

The request you see is clearly not encrypted because you can read it. So this is not a problem of SSLStrip. It is application specific. You can preprocess a password by using javascript. This process can be triggered by clicking the submit button for example. This is done to prevent a sutuation where the pasword travels the wire. It seems like you are in such a situation. Have a look at the webpage with firebug. You can check the button for costum functions triggered when the click event is triggered or the input textfield for costum events when keyup is triggered for example.


Where to store an important private key? I run LEMP stack on Ubuntu 18.04. I need to sign / verify transactions for Ethereum real-time. Where can I store the private key for it? Is storing it in .env good enough? It just seems super dangerous but I can't think of a way of me losing that key. But I am not a security specialist, so want to make sure and use the best practice.

Check out the HSM products of Nitrokey and Yubikey. They are explicitly produced for this kind of use-case, where you need to sign with a key, while keeping it on-device.


Reason behind sending multiple probes when scanning? I've read, that the ZMap creators recommend to send three probes for each (ip,port) tuple when scanning. Let's say, we scan port 443 port with a TCP SYN scan. One reason, I can imagine is packet loss. Do you know any other reasons for sending multiple probes instead of sending only one?

The main reason is the one you've stated, which is that there's a risk of packet loss on any connection and as a result it's prudent to send more probes to reduce the risk of missing an open service.

With scanners like nmap it's possible to over-ride the default configuration and reduce or increase the number of retries it will make. This can be handy to either reduce the time the scan will take (with a larger risk of missed services) or increase the service detection likelihood when scanning over flaky networks.


How to use OAuth with Active Directory I'm creating a REST WCF service and want to use OAuth to authenticate each user's request. The user accounts are stored in Active Directory so I have access to their AD login name on the client application and can pass that information along with the request header.

I've used oauth with the FatSecret REST API before so I'm familiar with how the authentication works.

Basically I'm just not sure how to handle assigning and storing secret keys for the users and how to go about tying a user's secret key to their AD login name.

Would I just have another database that held a mapping table of user AD login names to secret keys and then just do a lookup for the secret key on that table when the request comes in?

How do I ensure that the incoming request is actually coming from the user whose login name is in the incoming request, couldn't anyone just open Fiddler and create a request with another user's AD login name?

I'm not sure what OAuth gives you that can't be accomplished using other means.  WCF + Rest works very well with claims based authentication bundled in WIF.
Since WCF implies you're using ASP.NET I recommend using Windows Identity Foundation (WIF) on the server side.  Check out this ebook for more info.
Next you need a way to expose AD to your app.  You can use ADFSv2 which is free on Windows 2008 R2.  Take a look at the SQL installation that protects from session replay attacks.
Copying and pasting the credentials from Fiddler isn't something you can completely stop. HTTPS helps, but if you really want to investigate this issue look at this Q&A on Stack Overflow.


Yubikey for signing efi images, could not find token I am trying to sign an efi image with a Yubikey 4

I configured Yubikey with the following:

yubico-piv-tool -k $key -a import-key -s 9c < test-key.rsa
yubico-piv-tool -k $key -a import-certificate -s 9c < test-cert.pem

I included the certificate in a certdir:

certutil -A -n "efi-cert" -t ,,Tu -d $CERTDIR -a -i test-cert.pem

I can see the token in pkcs11-tool:

$ pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -L
Available slots:
Slot 0 (0xffffffffffffffff): Virtual hotplug slot
  (empty)
Slot 1 (0x1): Yubico Yubikey 4 OTP+CCID 00 00
  token label        : PIV_II (PIV Card Holder pin)
  token manufacturer : piv_II
  token model        : PKCS#15 emulated
  token flags        : rng, login required, PIN initialized, token initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 00000000

But when I try to use it with pesign, it doesn't find the token

$ sudo pesign -i bootx64.efi --export-signature bootx64.sig --sign -d sha256 -t "PIV_II (PIV Card Holder pin)" -c "efi-cert" -n $CERTDIR
could not find token "PIV_II (PIV Card Holder pin)"
pesign: Could not find certificate efi-cert

In strace I saw that pesign doesn't read opensc-pkcs11.so, but it reads libnssckbi.so, can this be the reason? Should I configure the Yubikey differently?

Any help would be much appreciated.

I just managed to get it working:

In strace I saw that pesign was looking for $CERTDIR/libnssckbi.so, but doing ln -s /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so $CERTDIR/libnssckbi.so didn't work, so to solve this I linked with opensc-pkcs11.so:

ln -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so $CERTDIR/libnssckbi.so

And now it finds the token. Please, let me know if there is a better solution (as this doesn't seems ideal).

Also, my argument in pesign ... -c "efi-cert" ... was wrong, as I should use the label in the token and not the one I gave to the certificate when including it in the certdir.

Executing the following revelled that the right label was "Certificate for Digital Signature" instead of "efi-cert":

$ pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O
Using slot 1 with a present token (0x1)
Public Key Object; RSA 2048 bits
  label:      SIGN pubkey
  ID:         02
  Usage:      encrypt, verify
Certificate Object, type = X.509 cert
  label:      Certificate for Digital Signature
  ID:         02
Data object 27638640
  label:          'Card Capability Container'
  application:    'Card Capability Container'
  app_id:         2.16.840.1.101.3.7.1.219.0
  flags:          <empty>

Data object 27637904
  label:          'Card Holder Unique Identifier'
  application:    'Card Holder Unique Identifier'
  app_id:         2.16.840.1.101.3.7.2.48.0
  flags:          <empty>

Data object 27638000
  label:          'Unsigned Card Holder Unique Identifier'
  application:    'Unsigned Card Holder Unique Identifier'
  app_id:         2.16.840.1.101.3.7.2.48.2
  flags:          <empty>

Data object 27638096
  label:          'X.509 Certificate for PIV Authentication'
  application:    'X.509 Certificate for PIV Authentication'
  app_id:         2.16.840.1.101.3.7.2.1.1
  flags:          <empty>

Data object 27636560
  label:          'X.509 Certificate for Digital Signature'
  application:    'X.509 Certificate for Digital Signature'
  app_id:         2.16.840.1.101.3.7.2.1.0
  flags:          <empty>

Data object 27636656
  label:          'X.509 Certificate for Key Management'
  application:    'X.509 Certificate for Key Management'
  app_id:         2.16.840.1.101.3.7.2.1.2
  flags:          <empty>

Data object 27636752
  label:          'X.509 Certificate for Card Authentication'
  application:    'X.509 Certificate for Card Authentication'
  app_id:         2.16.840.1.101.3.7.2.5.0
  flags:          <empty>

Data object 27636848
  label:          'Security Object'
  application:    'Security Object'
  app_id:         2.16.840.1.101.3.7.2.144.0
  flags:          <empty>

Data object 27636944
  label:          'Discovery Object'
  application:    'Discovery Object'
  app_id:         2.16.840.1.101.3.7.2.96.80
  flags:          <empty>

Now I can execute the following:

$ pesign -i bootx64.efi --export-signature bootx64.sig --sign -d sha256 -t "PIV_II (PIV Card Holder pin)" -c "Certificate for Digital Signature" -n $CERTDIR
Enter Password or Pin for "PIV_II (PIV Card Holder pin)":
Enter passphrase for private key:


Using passwords made of words People say don't use passwords in the dictionary but if you use two words isn't it alright? Dictionaries have at least 10,000 entries so just two words will be 100,000,000 possibilities (and that's given if the attacker somehow knows it is an English word).

Is there something about the way passwords are stored that make them easier to crack if they are all numeric or all alphabetical characters?

An Nvidia GTX 560 Ti costs about $250 USD, and with something like http://www.golubev.com/hashgpu.htm enables you to try matching about 1.5 Billion NTLM password hashes a second.

This varies some depending on the hashing algorithm used but I wouldn't rely upon using two words from a dictionary of 10,000 entries.


How to fix Path Disclosure Vulnerability? I have run a Qualys Web Application Scan for a customer website and found the "Path Disclosure Path-Based Vulnerability".

If the normal URL is like this http://example.com/
When I go to the URL http://example.com/m/templates/
I can find the files and directory in there and navigate in the server.

In my report I have to give the "solution". So the question is, how to fix this vulnerability?

The feature you need to disable is usually called "directory browsing", and the method for doing so depends on which web server your customer uses.

It is usually a simple configuration change. Look at these instructions for Apache and IIS, which are two of the more popular web servers. Every web server should have documentation that describes how to configure this setting.

Note that the customer may not have direct control over the application. Some applications automatically install a bundled web server, and some products are distributed as virtual machines. In these cases, the customer may be unable or unwilling to configure the web server directly.

If these cases, your customer may contact the vendor for assistance or ignore the finding.


Is external Nmap scan considered active or passive? I had a debate recently regarding whether conducting an Nmap scan through a 3rd party such as pentest-tools.net is considered active or passive. I argued that it is passive since there is no link between the scan and myself.

On the other hand, my friend argued that Shodan and Censys are considered passive which to me is the same as an external Nmap scan.

Is an external Nmap scan active or passive?

I tend to take a legal eye when I look that this (IANAL).

An NMAP scan of a target will always be active regardless of who performs the scan. Just because you shift the scanning responsibility to a third party doesn't change that fact.

You might be able to argue that you retrieved the scan data passively, but I would argue otherwise based on the post. From a legal stand point, it doesn't matter if you proxy the attack, if the attack as illegal it would just add another defendant. Would you consider C&C agents for something like a DDOS attack as passive? I sure as hell wouldn't.

It would however be different if you came across scan data on a third party site. You would have to prove that you didn't initiate the attack. From a legal perspective, you simply possessing scan data that was widely available (arguable), damning or not, would be different.


XSS prevention in single page web applications One of my colleagues suggested the following methods to secure against XSS attacks in my angular5 application:

Enable X-XSS-Protection header
Enable X-frame-options header
Adding proper content security policy to prevent inline javascript execution.

But I don't think the above protect my application from all XSS attacks. Do I need to anything more than the above?

NOTE

I am planning to pass auth token to the backend API via authorization header. In order to do that, I need to store the token either in local storage or in a cookie (access to ready by javascript).

But I don't think the above protect my application from all XSS attacks. Do I need to anything more than the above?

These headers will not magically protect you from all XSS attacks. X-XSS-Protection only lets you tune what the browser does if its heuristics detect a potential XSS (reflected XSS only). And X-Frame-Options is not about XSS at all but about preventing Clickjacking.

As long as your application needs Javascript there is simply no magic header which will prevent XSS. You can limit the impact of potential XSS with a strict Content-Security-Policy but other then that you just need to have proper coding, validating and sanitizing all input etc. See OWASP: XSS Prevention Cheat Sheet for more information.


In postgres LDAP authentication, are passwords encrypted? I am wondering if postgres LDAP login is secure? Would passwords be transmitted in clear text potentially if this is not set up properly?

PostgreSQL LDAP authentication mechanism does not provide by itself security guarantee. The password used for DB is either plain text based or MD5 hashed. Your communication protocols do. But even if the communication is encrypted using SSL, it is better to hash your passwords with MD5 since you can always be sniffed or trapped using  other methods.


Encrypted cookie to prevent csrf attacks For preventing CSRF attacks does creating an encrypted cookie with a nonce prevent a CSRF attack? In addition, to that checking the referrer against the  target origin. I cannot change 1000s of pages to embed the token in each submit and I do not have session state.

For preventing CSRF attacks does creating an encrypted cookie with a nonce prevent a CSRF attack?

No, requiring certain cookies would not defend against Cross Site Request Forgery, because the browser will still send the cookies, regardless of whether the request was Cross-Site or Same-Site.

  In addition, to that checking the referrer against the target origin. I cannot change 1000s of pages to embed the token in each submit and I do not have session state.

Read the OWSAP CSRF Prevention Cheat Sheet for recommended methods to prevent CSRF. Specifically look at the Verifying Same Origin techniques which are more easy to implement than tokens. Also look for OWSAP's description of this technique's limitations, if any.

If I remember correctly, checking the Origin is an effective countermeasure against CSRF for most (if not all) 'major' clients.


How to determine IP address of target device or network I know most exploits over the internet are opportunistic, but assume an aggressor has a specific target, but no physical access to that target. How do you find the target network or device to begin an attack over the internet? My first thought is social engineering, if the adversary can convince the target to access a resource under the adversary's control, then the adversary can obtain the target's IP address that way. What are some other possibilities?

This is the combination of two stages of penetration testing, known as information gathering and enumeration.

Information gathering is the preliminary process of collecting information about your target. This is often divided into passive (no contact with target) and active (contact with target). It can take many, many forms from social engineering, nameserver enumeration, website research, and more.

Enumeration generally refers to discovering and listing resources within the network, such as servers or user accounts. Typically, this phase occurs after the attacker has already gained access to the network, but in cases where the configuration is poor or data is otherwise leaked, it may be accessible without such a foothold.


What is the risk of my VPN traffic routing through China? I recently set up a new VPN on a Hetzner VPS (using Wireguard). It works fine, but I notice that when I do a traceroute from home to the server, I see several Chinese intermediaries.

I'm not too thrilled with any of my traffic touching Chinese servers, but I'm wondering, assuming my VPN server has a basic but functional configuration, what risk am I actually running with my traffic going through these Chinese servers?

Is it possible/likely/probable/etc that my traffic can be decrypted en route? Are there any even minor security risks (specifically in regards to the Chinese routing) that I should keep in mind?

In the case of VPNs, you shouldn't have to worry about whether or not it goes through China. What you should worry more about is the integrity and model of the VPN service you're using. If the encryption is secured, it should not matter what route your traffic takes.

Here's a simple model of a VPN (MITM = man in the middle)

You ----- VPN
      ^
     MITM

If the VPN service is secured, no one as the MITM should be able to read your data, Chinese or not. It should be the same no matter what route your traffic takes: everything between you and the VPN server is encrypted.

Even if the host/server of your VPN is in China, the main concern should be "Can I trust this VPN provider?" rather than "Can I trust China?". If the government mandates the VPN provider to give them your data, that's going to depend on the provider to not give out your data.

TL;DR: It shouldn't matter what's between you and the VPN. It should be encrypted and no one should be able to read it.


How can I constrain or limit 3rd party Javascript (*.js) files that can DOS my site? Many website owners integrate Google analytics, various Facebook or Twitter social media javascript plug ins into their web pages.  The problem is that this trust seems to be "all or nothing", meaning that there are no limits or structure as to what the 3rd party site is permitted to do.

In addition there doesn't appear to be any structured exception handling (SEH) available for Javascript anytime independent website author's scripts reside on the same web page.

Example

On 2/7/13 several sites that integrate with Facebook effectively DOSed half of the Internet, rendering several sites unusable.  I think this problem could be avoided if 3rd party javascript could be constrained (as defined by the website owner and honored by the browser), and/or there was a variation of meta-Structured Exception Handling for Javascript.

Question

Is there any research or proposal that attempts to constrain or control 3rd party javascript at any level?
What working group (W3C, RFC group, vendor, etc) is the most appropriate for formally proposing and defining a standard for 3rd party javascript controls?

No.  In practice, there is no good solution to this problem.  If you include a third-party Javascript library into your web page (via <SCRIPT SRC=...>), you are trusting that Javascript.  That includes trusting it not to DoS you.  That's just how it works, and there's no solution, given the current browser security model.

If you don't trust the third-party Javascript, don't embed it into your web page.  That's the only reasonable solution today.

(In principle you could use Caja, but it's a pretty complex mechanism: this is a bit like using a cannon to shoot a fly.)


Can a batch file download a file to infect a computer? Is it possible to write a batch script that can download some code from the web and infect a computer? Can you explain it briefly?

Ultimately, a batch file can write another file and execute it. Batch files can write ASCII characters fine, but other byte values can be more tricky. There are ways to do it, e.g. that which is shown in this answer. On this page a much more thorough bootstrapping method is explained. On recent Windows, it would be simpler to produce a VBScript file and run it; or, even better, a PowerShell script.

An arbitrary executable file can then do anything, including downloading and uploading files, modifying other files in arbitrary ways, and, generally speaking, taking control of the whole machine.