#MT103 | Explore Tumblr Posts and Blogs

arfox158 · 3 years

Text

5m Mathmrs. Mac's Messages

TLDR: With a bit of research and support we were able to demonstrate a proof of concept for introducing a fraudulent payment message to move £0.5M from one account to another, by manually forging a raw SWIFT MT103 message, and leveraging specific system trust relationships to do the hard work for us!

5m Mathmrs. Mac's Messages App

5m Mathmrs. Mac's Messages Message

5m Mathmrs. Mac's Messages To My

5m Mathmrs. Mac's Messages For Her

Before we begin: This research is based on work we performed in close-collaboration with one of our clients; however, the systems, architecture, and payment-related details have been generalized / redacted / modified as to not disclose information specific to their environment.

A desktop application for Instagram direct messages. Download for Windows, Mac and Linux.

Have a question, comment, or need assistance? Send us a message or call (630) 833-0300. Will call available at our Chicago location Mon-Fri 7:00am–6:00pm and Sat 7:00am–2:00pm.

5m Mathmrs. Mac's Messages App

With that said.. *clears throat*

The typical Tactics, Techniques and Procedures (TTPs) against SWIFT systems we see in reports and the media are - for the most part - the following:

Compromise the institution's network;

Move laterally towards critical payment systems;

Compromise multiple SWIFT Payment Operator (PO) credentials;

Access the institution's SWIFT Messaging Interface (MI);

Keys in - and then authorize - payment messages using the compromised PO accounts on the MI.

This attack-path requires the compromise of multiple users, multiple systems, an understanding of how to use the target application, bypass of 2FA, attempts to hide access logs, avoid alerting the legitimate operators, attempts to disrupt physical evidence, bespoke malware, etc. – so, quite involved and difficult. Now that’s all good and fine, but having reviewed a few different payment system architectures over the years, I can’t help but wonder:

“Can't an attacker just target the system at a lower level? Why not target the Message Queues directly? Can it be done?”

A hash-based MAC might simply be too big. On the other hand, hash-based MACs, because they are larger, are less likely to have clashes for a given size of message. A MAC that is too small might turn out to be useless, as a variety of easy-to-generate messages might compute to the same MAC value, resulting in a collision. WhatsApp Messenger is a FREE messaging app available for iPhone and other smartphones. WhatsApp uses your phone's Internet connection (4G/3G/2G/EDGE or Wi-Fi, as available) to let you message and call friends and family. Switch from SMS to WhatsApp to send and receive messages, calls, photos, videos, documents, and Voice Messages. WHY USE WHATSAPP. Garrick Hello, I'm Garrick Chow, and welcome to this course on computer literacy for the Mac. This course is aimed at the complete computer novice, so if you're the sort of person who feels some mild anxiety, nervousness, or even dread every time you sit down in front of your computer, this course is for you.

Well, let's find out! My mission begins!

So, first things first! I needed to fully understand the specific “section” of the target institution's payment landscape I was going to focus on for this research. In this narrative, there will be a system called “Payment System” (SYS). This system is part of the institution's back-office payment landscape, receiving data in a custom format and output's an initial payment instructions in ISO 15022 / RJE / SWIFT MT format. The reason I sought this scenario was specifically because I wanted to focus on attempting to forge an MT103 payment message - that is:

In this video I will show you where to locate the serial number on a Western golf cart. Ebay Store: Please SUBSCRIBE. Western golf cart serial number lookuplastevil.

MT – “Message Type” Literal;

1 – Category 1 (Customer Payments and Cheques);

0 – Group 0 (Financial Institution Transfer);

3 – Type 3 (Notification);

All together this is classified as the MT103 “Single Customer Credit Transfer”.

Message type aside, what does this payment flow look like at a high level? Well I’ve only gone and made a fancy diagram for this!

Overall this is a very typical and generic architecture design. However, let me roughly break down what this does:

The Payment System (SYS) ingests data in a custom - or alternative - message format from it's respective upstream systems. SYS then outputs an initial payment instruction in SWIFT MT format;

SYS sends this initial message downstream to a shared middelware (MID) component, which converts (if necessary) the received message into the modern MT format understood by SWIFT - Essentially a message broker used by a range of upstream payment systems within the institution;

MID forwards the message in it's new format on to the institution's Messaging Interface (let's say its SAA in this instance) for processing;

Once received by SAA, the message content is read by the institution's sanction screening / Anti-money laundering systems (SANCT).

Given no issues are found, the message is sent on to the institution's Communication Interface (SWIFT Alliance Gateway), where it's then signed and routed to the recipient institution over SWIFTNet.

OK, so now I have a general understanding of what I'm up against. But if I wanted to exploit the relationships between these systems to introduce a fraudulent payment without targeting any payment operators, I was going to need to dig deeper and understand the fundamental technologies in use!

So how are these messages actually 'passed' between each system? I need to know exactly what this looks like and how its done!

More often than not, Message Queues (MQ) are heavily used to pass messages between components in a large payment system. However, there are also various “Adapter” that may be used between systems communicating directly with the SAG (Such as SAA or other bespoke/3rd party systems). These are typically the:

Remote API Host Adapter (RAHA);

MQ Host Adapter (MQHA);

Web Services Host Adapter (WSHA).

Having identified that MQ was in use, my initial assumption was that there was most likely a dedicated Queue Manager (QM) server somewhere hosting various queues that systems push and pull messages from? However, due to SWIFT CSP requirements, this would most likely - at a minimum - take the form of two Queue Managers. One which manages the queues within the SWIFT Secure Zone, and another that manages queues for the general corporate network and back office systems.

Let's update that diagram to track / represent this understanding: Now I could research how this 'messaging' worked!

There are multiple ways to configure Message Queues architectures, in this case there were various dedicated input and output queues for each system, and the message flow looks something like this: Full disclosure, turns out it’s hard to draw an accurate - yet simple - MQ flow diagram (that one was basically my 4th attempt). So it’s.. accurate 'enough' for what we needed to remember!

5m Mathmrs. Mac's Messages Message

Now I had a good understanding of how it all worked, it is time to define my goal: 'Place a payment message directly on to a queue, and have it successfully processed by all downstream systems'.

This sounds simple, just write a message to a queue, right? But there are a few complications!

Why are there few indications of this attack vector in the wild?

How do I even gain “write” access to the right queue?

What protects the message on the queues?

What protects the messages in transit?

What format are the messages in?

What is the correct syntax for that message format at any particular queue (0 margin for error)?

Where does PKI come in? How / where / when are the messages signed?

Can I somehow get around the message signing?

What values in the messages are dependent / controlled / defined by the system processing them (out of my control)?

What is the maximum amount I can transfer using Straight Through Processing, without alerting the institution / requiring manual validation?

But OK, there's no point dwelling on all of that right now, I'll just clearly define what I want to do! The goal:

Successfully write a payment instruction for 500,000 GBP;

Inject that message directly onto a specific queue;

Have the message pass environment-specific validation rules;

Have the message pass sanctions and AML checks.

Have the message successfully signed;

Have the message pass SWIFTNet-specific validation rules;

What I was not interested in doing for this research - yet needed to understand nevertheless for a full attack chain was:

How to compromise the institution's network;

How to gain access to the MQ admin's workstation;

How to obtain the pre-requisite credentials.

What I wanted to 100% avoid at all costs:

The attack involving SWIFT payment operators in any way;

The attack involving SWIFT application access in any way;

A need to compromise signing keys / HSMs;

A need to compromise SWIFTNet operator accounts or certificates or any type of PKI;.

Now I had an idea of what to do, I needed to make sure I could write a raw MT103 payment instruction! Typically, even when operators write payment messages using a messaging interface application like Alliance Access, they only really write the message “body” via a nice GUI. As raw data this could look something like:

I'll break this down in the following table:

NameFieldValueTransaction Reference20TRANSACTIONRF103Bank Operation Code23BCRED (Message is to 'credit' some beneficiary)Value Date / Currency / Amount32A200102 (02/01/2020) GBP 500,000.00Currency / Original Credit Amount33BGBP 500000,00 (£500,000.00)Ordering Customer50KGB22EBNK88227712345678 (IBAN) JOHN DOE (Name) JOHN'S BUSINESS LTD (Line 1) 21 JOHN STREET, LONDON, GB (Line 2)Beneficiary59KFR20FBNK88332287654321 (IBAN) ALICE SMITH (Name) ALICE'S COMPANY (Line 1) 10 ALICE STREET, PARIS, FR (Line 2)Remittance Information7012345-67890 (essentially a payment reference)Details of Charge71ASHA (Shared charge between sender and receiver)

Now as this is a valid message body, if I were targeting a payment operator on SWIFT Alliance Access, I could - for the 'most' part - simply paste the message into SAA's raw message creation interface and I'd be pretty much done. With the exception of adding the sender / recipient BIC codes and most likely selecting a business unit. However, these values are not stored in the message body. Not stored in the message body you say? Well that complicates things! Where are they stored exactly?

The message “body” is referred to as “block 4” (aka the “Text Block”) within the SWIFT MT standard. As suggested by the name, there is probably also a block 1-3. This is correct; and these blocks are typically generated by the payment processing applications - such as SWIFT Alliance Access - and not necessarily input by the operators. A 'complete' MT103 message consists of 6 blocks:

Block 1 – Basic Header

Block 2 – Application Header

Block 3 – User Header

Block 4 – Text Block

Block 5 – Trailer

Block 6 – System block

So it looked like I was going to need to learn how to craft these various “blocks” from scratch.

Block 1 (Basic header)

Reading through some documentation, I crafted the following “Basic header” block:

A breakdown of what this translates too is as follows:

NameValueContextBasic Header Flag1Block 1 (Not 2, 3, 4, or 5)Application TypeFFIN ApplicationMessage Type0101 = FIN (I.e not ACK/NACK)Sender BICEBNKGB20EBNK (Bank Code) GB (Country Code) 20 (Location Code)Sender Logical TerminalATypically A, unless they are a significantly large institution and require multiple terminalsSender BranchXXXAll X if no branch neededSession Number0000The session number for the messageSequence Number 999999The sequence number of the message

Taking a step back, I already identified two potential problems: the “session” and “sequence” numbers! These are described as follows:

Session Number – Must also equal the current application session number of the application entity that receives the input message.

Sequence number – The sequence number must be equal to the next expected number.

Hmmm, at this point I was not sure how I could predetermine a valid session and/or sequence number - considering they seemed to be application and 'traffic' specific? But there was nothing I could do at the time, so I noted it down in a list of 'issues/blockers' to come back to later.

Block 2 (Application Header)

A bit more dry reading later, I managed to also throw together an application header:

Again, I’ve broken this down so it makes sense (if it didn’t already; I’m not one to assume):

NameValueContextApplication Header Flag2Block 2I/O IdentifierIInput Message (a message being sent)Message Type103103 = Single Customer Credit TransactionRecipient BICFBNKFR20FBNK (Bank Code) FR (Country Code) 20 (Location Code)Recipient Logical TerminalXAll General Purpose Application Messages must use 'X'Recipient BranchXXXAll General Purpose Application Messages must use 'XXX'Message PriorityNNormal (Not Urgent)

Awesome! No issues crafting this header!

Note: At this point I should probably mention that these BIC codes are not 'real', however are accurate in terms of in format and length.

Block 3 (User Header)

The third block is called the “User Header” block, which can be used to define some “special” processing rules. By leverage this header, I could specify that the message should be processed using “Straight Through Processing” (STP) rules which essentially attempts to ensure that the message is processed end-to-end without human intervention. This could be specified as follows:

However, this was not yet a valid header! As of November 2018 the user header requires a mandatory “Unique end-to-end transaction reference” (UETR) value, which was introduced as part of SWIFT's Global Payments Innovation initiative (gpi)! This is a Globally Unique Identifier (GUID) compliant with the 4th version of the generation algorithm used by the IETF standard 'RFC4122'. This consists of 32 hexadecimal characters, divided into 5 parts by hyphens as follows:

where:

x – any lowercase hexadecimal character;

4 – fixed value;

y – either: 8, 9, a, b.

This value can be generated using Python as seen below:

With an acceptable UETR generated, this is how the third block looked:

And as before, a breakdown can be found below:

NameValueContextUser Header Flag3Block 3Validation Flag119Indicates whether FIN must perform any type of special validationValidation FieldSTPRequests the FIN system to validate the message according to the straight through processing principlesUETR Field121Indicates the Unique end-to-end transaction reference valueUETR Value8b1b42b5-669f-46ff-b2f2-c21f99788834Unique end-to-end transaction reference used to track payment instruction

Block 5 and 6 (Trailer and System Blocks)

I’ve already discussed “block 4” (the message body), so to wrap this section up, I'll be looking at the final 2 blocks: Block 5, aka the “Trailer”; and block S, aka the “System” block.

Before going forward, let me take a moment to explain the pointlessly complicated concept of input and output messages:

An “input” message (I) is a message which is traveling “outbound” from the institution. So this is a message being “input” by an operator and sent by the institution to another institution.

An “output” message (O) is a message which is traveling “inbound” to the institution. So this is a message being “output” by SWIFTNet and being received by the institution.

OK, moving swiftly (aaaahhhhh!) on.

For Input messages, these blocks were not too much of a problem. The headers only really seemed to be used to flag whether the message was for training / testing or to flag if it was a possible duplicate, which syntactically took the following form:

Where “TNG” indicated “training” and “SPD” indicated “possible duplicate”.

However, with Output messages, it got considerably more complicated. An example of what the trailer and system block could look like on an Output message is the following:

A breakdown of these various values is:

Trailer ((5:) MAC – Message Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination bank and a secret algorithm; CHK – This is a PKI checksum of the message body, used to ensure the message has not been corrupted in transit; TNG – A flag to indicate that the message is a Testing and Training Message.

System ((S:) SPD – Possible Duplicate Flag SAC – Successfully Authenticated and Authorized Flag. This is only present if:

Signature verification was successful.

RMA (Relationship Management Application) authorization and verification was successful.

COP – Flag indicating that this is the primary message copy; MDG – The HMAC256 of the message using LAU keys.

However, these seemed to only be values I would need to consider if I was to try and forge an “incoming” message from SWIFTNet or an 'outbound' message on the output of the SAG.

So.. I'll stick with crafting an “input' message trailer:

Now, having said all that, it turned out the trailer block did seem to sometimes hold a MAC code and a message checksum (sigh), meaning I actually needed to construct something like:

So that was +2 to my 'issues/blockers' list. However, issues aside, I now understood the complete message format, and could put it all together and save the following as a draft / template MT103 message:

Highlighted in bold above are the areas of the message I was - at this point - unable to pre-determine. Nevertheless, a summary of what that the message describes is:

Using the transaction reference “TRANSACTIONRF103”;

please transfer 500,000.00 GBP;

from John Doe, (IBAN: GB22EBNK88227712345678) at “English Bank” (BIC: EBNKGB20);

to Alice Smith (IBAN: FR20FBNK88332287654321) at “French Bank” (BIC: FBNKFR20);

Furthermore, please ensure the transaction charge is shared between the two institutions;

and mark the payment with a reference of “12345-67890”.

To wrap up this section, i wanted to take a moment to explain some logic behind the target of 500,000 GBP, as it is also important.

Aside from the many reasons it would be better to transfer (even) smaller amounts (which is an increasingly common tactic deployed by modern threat actors), why not go higher? This is where it’s important to understand the system and environment you are targeting.

In this instance, let's assume that by doing recon for a while I gathered the understanding that:

If a message comes from SYS which is over £500k;

even if it has been subject to a 4 eye check;

and even if it is flagged for STP processing;

route it to a verification queue and hold it for manual verification.

This was because a transaction over £500k was determined to be “abnormal” for SYS. As such, if my transaction was greater, the message would not propagate through all systems automatically.

OK, so now that I understood:

how the system worked;

how it communicated;

the fundamental structure of a raw MT103 payment messages;

and how much I could reliably (attempt) to transfer.

And with that, it was time to take a break from MT standards and establish an understanding of how I would even get into a position to put this into practice!

To place a message on a queue, I was going to need two things:

Access to the correct queue manager;

Write access to the correct queues.

Depending on the environment and organisation, access to queue managers could be quite different and complex. However a bare-bones setup may take the following form:

An MQ Administrator accesses their dedicated workstation using AD credentials;

They then remotely access a dedicated jump server via RDP which only their host is whitelisted to access;

This may be required as the queues may make use of Channel Authentication Records, authorizing specific systems and user accounts access to specific queues;

The channels may further be protected by MQ Message Encryption (MQME) which encrypts messages at rest based on specific channels. As such, even if someone was a “super duper master admin” they would only be able to read / write to queues specifically allocated to them within the MQME configuration file (potential target for another time?);

The MQ Admin can then use tools such via the Jump Server to read/write to their desired message queues.

So, in this scenario, to gain access to the message queues I - as an attacker - would need to compromise the MQ admin’s AD account and workstations, then use this to gain access to the jump host, from where I could then access the message queues given I knew the correct channel name and was configured with authorization to access it.. and maybe throw some MFA in there..

That is understandably a significant requirement! However, when discussion sophisticated attacks against Financial Market Infrastructure (FMI), it is more than reasonable to accept that an Advanced Persistent Threat (APT) would see this as a feasible objective - We don't need to dig into the history of how sophisticated attacks targeting SWIFT systems can be.

Next, it was time to finally identify a feasible attack vector for message forgery.

Now with an idea of how to gain the right access, as well as an understanding of the various technologies and security controls in place; I update my diagram:

You may have noticed I've added something called “LAU” around the SAA-to-SAG adapter, and another “LAU” to the MID-to-SAA MQ channels, which I have yet to explain. “Local Authentication” (LAU) is a security control implemented by SWIFT to authenticate messages using a pair of shared keys between two systems. These keys are combined and used to generate a SHA256 HMAC of the message and append it to the S block. This can then be validated by the recipient system. Effectively, this validates the origin and authenticity of a message. As such, even if an attacker was in position to introduce a fraudulent payment, they'd first need to compromise both the left and the right LAU signing keys, generate the correct HMAC, and append it to the message in order to have it accepted / processed successfully.

But LAU aside, I now just needed to figure out which queue to target! There were a lot of queues to work with as each system essentially has multiple “input” and “output” queues. With that in mind, it was important to note that: an incoming message would require being in the format expected by the target system (from a specific upstream system) and an outgoing message would need to be in the format “produced” by one target system and “expected / ingested / processed” by its respective downstream system. So to figure this out, I worked backwards from the Gateway.

Targeting SAG

This was the least feasible attack vector!

I hadn't really looked into how the SWIFT adapters worked - If only I could research literally everything);

SAA and SAG implemented LAU on messages sent between them - An excellent security control!;

The output of SAG was directly on to SWIFTNet which would entail all sorts of other complications - this is an understatement)!

Next!

Targeting SAA

So what if I wanted to drop a message on the “outbound” channel of SAA?

LAU and the SWIFT adapter aside, remember those session and sequence numbers? Well, messages which leave SAA are in the near-final stages of their outbound life-cycle, and as far as I understood would need to have valid session and sequence values. Given I didn't know how to generate these values without gaining access to SAA or how they worked in general (and lets not forget the LAU signing) this didn't currently seem feasible.

Next!

Targeting SANCT

This solution didn't actually transport messages back and forth; it just reads messages off the queues and performed checks on their details. Not much I could wanted to leverage here.

Targeting MID

To target MID, I could try and inject a message onto SAA’s “input” queue, or the “output” queue of MID. This would only need to match the format of messages produced by the Middleware solution (MID). Following this, in theory, the (mistial) message session and sequence number would be added by SAA, along with the UETR. This was promising!

However, MID was a SWIFT “message partner”, which are typically solutions developed using the Alliance Access Development Kit that allows vendors to develop SWIFTNet compatible software, and consequentially, implement LAU. So again, in-order to forge a message here, I’d need to compromise the left and right LAU signing keys used between SAA and MID, manually HMAC the message (correctly!), and then place it on the correct queue.. This also no longer looked promising..

Targeting SYS

OK, how about the input of the next system down - the 'Payment System'?

5m Mathmrs. Mac's Messages To My

As described previously, the inbound data was a custom “application specific” payment instruction from the institutions back office systems, and not a SWIFT MT message. This would be an entirely new core concept I'd need to reverse - not ideal for this project.

But how about the output queue?

Although SYS received custom format data, I found that it output what seemed to be an initial SWIFT MT messages. This was perfect! Additionally, SYS did not have LAU between itself and MID because (unlike MID) SYS was not a SWIFT message partner, and was just one of many-many systems within the institution that formed their overall payment landscape.

Additionally, because SYS was esentially just one small piece of a much larger back office architecture, it was not part of the SWIFT Secure Zone (after all you cant have your entire estate in the Secure Zone - that defeats the purpose) and as such, made use of the Queue Manager within a more accessible section of the general corporate environment (QM1). Konica minolta bizhub c352 driver mac os xcompubrown recovery tool.

With this in mind, and having - in theory - compromised the MQ admin, I could leverage their access to access on the corporate network to authenticate to QM1. I could - in theory - then write a fraudulent payment message to the SYS “output” queue, which we will call “SYS_PAY_OUT_Q” from here on.

OK! It seems like I finally had an idea of what to do! But before I could put it into practice, I of course needed to create a diagram of the attack:

I think it’s important to take a minute to refer back to the concept of “trust” which is what lead to this attack diagram. My theory behind why this may work is because the MID application, implicitly trusts whatever it receives from its respective upstream systems. This is intentional, as by design the security model of the payment landscape ensures that: at any point a message can be created, a 4 (or 6) eye check is performed. If there was a system whose purpose it was to ensure the validity of a payment message at any point upstream, the downstream systems should have no real issue processing that message (with some exceptions). After all, It would be next to-impossible to maintain a high-throughput payment system without this design.

And with that said, the plan was now clear:

Leverage the access of a Message Queue administrator;

to abuse the “trust relationship” between SYS, MID, and SAA;

to introduce a fraudulent payment message directly on to the output queue of SYS;

by leaning on my new found understanding of complete MT103 payment messages.

It was finally time to try to demonstrate a Proof-of-Concept attack!

So at this point I believe I had everything I needed in order to execute the attack:

The target system!

The message format!

The queue manager!

The queue!

The access requirements!

The generously granted access to a fully functional SWIFT messaging architecture! (that’s a good one to have!)

The extra-generously granted support of various SMEs from the target institution! (This was even better to have!)

Message Forgery

I needed to begin by creating a valid payment message using valid details from the target institution. So before moving on I was provided with the following (Note: as with many things in this post, these details have been faked):

Debtor Account Details – John Doe, GB12EBNK88227712345678 at EBNKGB20

Creditor Account Details – Alice Smith, GB15EBNK88332287654321 at EBNKGB20

Some of you may have notice that the sending and receiving BIC’s are the same. This was because, for the sake of the research, I wanted to send the message back to the target institution via SWIFTNet so that I could analyse its full end-to-end message history. Furthermore, you may have noticed we are using 'test & training' BIC code (where the 8th character is a 0) - this was to make sure, you know, that I kept my job.

But yes, with access to these 'valid' account details and the knowledge gained during the research so far, I could now forge a complete Input MT103 messages:

Note: Field 33B is actually an optional field, however, the MT standard stated that “If the country codes of both the Sender’s and the Receiver’s BIC belong to the country code list, then field 33B is mandatory”. As such, if 33B was not present in the message, it would fail network validation rules and SWIFTNet would return a NAK with the error code: D49.

Optional / Mandatory fields aside, it was not quite that simple! There were a few minor changes I needed to make based on the specific point in the message's its life-cycle I was planning to introduce it!

As I list these changes, remember that the objective is to introduce the message to the output queue of SYS (Which exists before MID, SAA and SAG)

The first 3 blocks needed to be placed on a single line;

Remove field 121 (UETR) from the User Header, as this would be generated by SAA during processing;

Remove 1 character from the transaction reference as it needed to be exactly 16 characters (classic user error);

Add decimal point to transaction amount using a comma - otherwise it would fail syntax validation rules;

Ensure the IBAN's were real and accurate, otherwise it seemed the message would fail some type of signature validation on the SWIFT network. The IBANs are fake here, but during the real PoC we used accurate account details in collaboration with the target institution;

Remove the trailer block (5) - as this would be appended by SAA during processing;

Remove the System Block (S) - as this would be completed by the SAG.

And the final message was as follows:

Note that the location in which I introduce the message has resolved all of the 'issues / blockers' I'd tracked whilst researching the message structure! It would seem the further upstream you go, the easier the attack becomes - given MQ is still used as a transport medium.

Message Injection

Now I had my raw MT103 message, I just need to save it to a file (“Message.txt” - sure why not) and place onto the “SYS_PAY_OUT_Q” queue using one of the admin's tools:

With access to a sole MQ Administrator's AD account;

We connect to the MQ admins machine;

Log into the Jump Server;

Open our MQ tools of choice and authenticate to queue manager (QM1) where the output queue for SYS was managed;

Connected to the 'SYS_PAY_OUT_Q' queue;

Selected my forged “Message.txt” file;

Invoked the “write to queue” function;

And it was off!

Loggin in to Alliance Access and opening the message history tab, we sat awaiting for an update. Waiting, waiting, waiting… waiting… and..

ACK! It worked!

That's a joke; did we hell receive an ACK!

See, this last section is written slightly more 'linear' than what actually happened. Remember those 'tweaks' used to fix the message in the previous section? I hadn't quite figured that out yet..

So roughly seven NACKs later - each time troubleshooting and then fixing a different issues - we did indeed, see an ACK! The message was successfully processed by all systems, passed target system validation rules, passed sanctions and AML screening, passed SWIFTNet validation rules, and SWIFT’s regional processor had received the message and sent an 'Acknowledgement of receipt' response to the sending institution!

For the sake of completeness, I’ve included the ACK below:

And of course a breakdown of what it all means:

NameValueContextBasic Header Flag1Block 1Application TypeFF = FIN ApplicationMessage Type2121 = ACKInstitution CodeEBNKGB20AXXXEBNKGB20 (BIC) A (Logical Terminal) XXX (Branch)Sequence and Session No.19473923441947 (Sequence No.) 392344 (Session No.)Date Tag177200103 (Date) 1102 (Time)Accept / Reject Tag4510 = Accepted by SWIFTNet

Excellent! WooHoo! It worked! .. That took a lot of time and effort!

Closer Inspection

But the ACK wasn't enough, I wanted to make sure I understood what had happened to the message throughout its life-cycle. From the message I placed on the initial queue, to being processed by SWIFTNet.

Thankfully, as we sent the message back to the target institution we could see its entire message history. I already knew what the raw message placed on the queue looked like, so I wanted to focus on what became of the message once it had been processed by SAA:

The end-to-end tracking UUID had been generated and added (b42857ce-3931-49bf-ba34-16dd7a0c929f) in block 3;

The message trailer had been added ((5:(TNG:))) where I could see that - due to the BIC code used - SAA had flagged the message as 'test and training'.

Additionally, an initial System Block segment had been added ((S:(SPD:))), tagging the message as a possible duplicate. I wonder why - *cough* 7th attempt *cough*?

OK, so that was SAA. Now let’s see how it looked it once it passed through the Gateway and regional processor:

OK, we can see a few changes now.

The session and sequence numbers have been populated (1947392344);

The I/O identifier in block 2 has been updated to track that it is now an 'Output' message;

The additional data within Block 2 is a combination of the input time, date, BIC, session and sequence numbers, output date/time, and priority;

The trailer has been updated with a message authentication code (MAC) calculated based on the entire contents of the message using a pre-shared key and a secret algorithm;

Additionally, a checksum of the message body has been stored within the trailer’s “CHK” tag. This is used by the network to ensure message integrity.

I also took a look at the entire outbound message history, just to see all the “Success” and “No violation” statements to make it feel even more awesome!

So that's that really..

With a bit of research and support I was able to demonstrate a PoC for introducing a fraudulent payment message to move funds from one account to another, by manually forging a raw SWIFT MT103 single customer credit transfer message, and leveraging various system trust relationships to do a lot of the hard work for me! https://arfox158.tumblr.com/post/655263262721638400/wireless-external-hard-drive-for-mac.

As mentioned briefly in the introduction, this is not something I have really seen or heard of happening in practice or in the 'wild'. Perhaps because it clearly takes a lot of work.. and there is a huge margin for error. However, if an adversary has spent enough time inside your network and has had access to the right documentation and resources, this may be a viable attack vector. It definitely has its benefits:

No need to compromise multiple payment operators;

No requirement to compromise - or establish a foothold within - the SWIFT Secure Zone;

No requirement to bypass MFA and gain credentials for a messaging interface;

No generation of application user activity logs;

No payment application login alerts;

No bespoke app-specific and tailored malware;

And all the other things associated with the complex task of gaining and leveraging payment operator access.

All an attacker may need to do is compromise one specific user on the corporate network: a Message Queue administrator.

The industry is spending a lot of time and effort focused on securing their payment systems, applications, processes, and users to keep - among other things - payment operators safe, Messaging Interfaces locked down, and SWIFT systems isolated. But the reality is,; the most valuable and most powerful individual in the entire model, might just be a single administrator!

As always, a security model is only as strong as its weakest link. If you're not applying the same level of security to your wider institution, there may very well be many weak links within the wider network which chain together and lead to the comrpomise of systems which feed into your various payment environment.

I think the main thing to remember when reflecting on this research is that it did not abuse any vulnerabilities within the target institution's systems, or even vulnerabilities or weaknesses within the design of their architecture. It simply leverages the legitimate user access of the Message Queue administrators and the trust relationships that exist by design within these types of large-scale payment processing systems.

So the harsh reality is, there is no particular list of recommendations for preventing this type of attack in itself. However, the main point to drive home is that you must ensure the security of your users - and overall organisation - is of a high enough standard to protect your highest privileged users from being compromised. Things such as:

Strong monitoring and alerting controls for anomalous behaviour;

Requirements for Multi-Factor authentication for access to critical infrastructure;

Segregation of critical infrastructure from the wider general IT network;

Strong password policies;

Well rehearsed incident detection and incident response policies and procedures;

Frequent high-quality security awareness training of staff;

Secure Software Development training for your developers;

Routine technical security assessments of all critical systems and components;

The use of 3rd party software from reputable and trusted vendors;

However, in the context of Message Queues, there is one particular control which I think is extremely valuable: The implementation of channel specific message signing! This, as demonstrated by SWIFT's LAU control, is a good way in which to ensure the authenticity of a message.

As discussed, LAU is - as far as I know at the time of writing - a SWIFT product / message partner specific control. However it's concept is universal and could be implemented in many forms, two of which are:

Update your in-house application's to support message signing, natively;

Develop a middleware component which performs message signing on each system, locally.

This is a complex requirement as it requires considerable effort on the client’s behalf to implement either approach. However, SWIFT provides guidance within their Alliance Access Developers guide on how to implement LAU in Java, Objective C, Scala and Swift;

Strip any S block from the FIN message input. Keep only blocks 1: through 5;

Use the FIN message input as a binary value (unsigned char in C language, byte in Java). The FIN message input must be coded in the ASCII character set;

Combine the left LAU key and the right LAU key as one string. The merged LAU key must be used as a binary value (unsigned char in C language, byte in Java). The merged LAU key must be coded in the ASCII character set;

Call a HMAC256 routine to compute the hash value. The hash value must also be treated as a binary value (unsigned char in C language, byte in Java). The HMAC size is 32 bytes;

Convert the HMAC binary values to uppercase hexadecimal printable characters.

An example of how this may work in the more flexible middleware solution proposed is where the original service is no longer exposed to the network, and is altered to only communicate directly with the custom 'LAU-eqsue' service on its local host. This service would then sign and route the message to its respective queue.

When received, the core of the recipient payment service would seek to retrieve its messages from the queues via the 'LAU-esque' signing middleware, which would retrieve the message and subsequently verify its origin and authenticity by re-calculating the signature using their shared (secret) keys. Key-pairs could further be unique per message flow. This design could allow for the signing to be used as a way to validate the origin of a message even if it had passed through multiple (local) intermediary systems.

As a final bit of creative effort, I made yet another diagram to represent what this could perhaps look like - if life was as easy as a diagram:

If you made it this far thanks for reading all.. ~6k words!? I hope you found some of them interesting and maybe learned a thing or two!

I'd like express our gratitude to the institution who facilitated this research, as well as specifically to the various SMEs within that institution who gave their valuable time to support it throughout.

Fineksus - SWIFT Standard Changes 2019

https://fineksus.com/swift-mt-standard-changes-2019/

Paiementor - SWIFT MT Message Structure Blocks 1 to 5

https://www.paiementor.com/swift-mt-message-structure-blocks-1-to-5/

SEPA for corporates - The Difference between a SWIFT ACK and SWIFT NACK

https://www.sepaforcorporates.com/swift-for-corporates/quick-guide-swift-mt101-format/

SEPA for corporates - Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

https://www.sepaforcorporates.com/swift-for-corporates/explained-swift-gpi-uetr-unique-end-to-end-transaction-reference/

M DIBA - LAU for SWIFT Message Partners

https://www.linkedin.com/pulse/lau-swift-message-partners-mohammad-diba-1/

Prowide - About SWIFT

https://www.prowidesoftware.com/about-SWIFT.jsp

5m Mathmrs. Mac's Messages For Her

Microsoft - SWIFT Schemas

https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/swift-schemas

SWIFT FIN Guru - SWIFT message block structure

http://www.swiftfinguru.com/2017/02/swift-message-block-structure.html

2 notes · View notes

kingrisefinancelimited · 4 years

Text

sblc bg funding

Understanding sblc bg funding

SBLC (Standby Letter of Credit) and BG (Bank Guarantee) are both financial instruments issued by banks and financial institutions. These financial instruments are used to obtain loan and financing from banks, they are also used for trade finance, foreign exchange as well as import and export transactions.

sblc bg funding- Kingrise Finance Limited

What is Standby Letter of Credit (SBLC/SLOC)?

A standby letter of credit (SBLC or SLOC) is a guarantee of payment by a bank on behalf of their client. It is a loan of last resort in which the bank fulfills payment obligations by the end of the contract if their client cannot

A standby letter of credit helps facilitate international trade between companies that don't know each other and have different laws and regulations. Although the buyer is certain to receive the goods and the seller certain to receive payment, a SLOC doesn't guarantee the buyer will be happy with the goods. A standby letter of credit can also be abbreviated SBLC.

Types and Examples of Standby Letter of Credit (SBLC/SLOC): Financial standby LOC: An exporter sells goods to a foreign buyer, who promises to pay within 60 days. If the payment never arrives (and the exporter required the buyer to use a standby letter of credit) the exporter can collect payment from the importer’s bank. Before issuing the letter of credit, the bank typically evaluates the importer’s credit and determines that the importer will repay the bank. But if the customer’s credit is in question, banks may require collateral (or funds on deposit) for approval.

Performance standby LOC: A contractor agrees to complete a construction project within a certain timeframe. When the deadline arrives, the project is not complete. With a standby letter of credit in place, the contractor’s customer can demand payment from the contractor’s bank. That payment functions as a penalty to encourage on-time completion, funding to bring in another contractor to take over mid-project, or compensation for the headaches of dealing with problems. This is an example of a “performance” standby letter of credit, and a failure to perform triggers the payment.

Advantages of a Standby Letter of Credit (SBLC / SLOC)

The SBLC / SLOC is often seen in contracts involving international trade, which tend to involve a large commitment of money and have added risks.

For the business that is presented with a SLOC, the greatest advantage is the potential ease of getting out of that worst-case scenario. If an agreement calls for payment within 30 days of delivery and the payment is not made, the seller can present the SLOC to the buyer's bank for payment. Thus, the seller is guaranteed to be paid. Another advantage for the seller is that the SBLC reduces the risk of the production order being changed or canceled by the buyer.

An SBLC helps ensure that the buyer will receive the goods or service that's outlined in the document. For example, if a contract calls for the construction of a building and the builder fails to deliver, the client presents the SLOC to the bank to be made whole. Another advantage when involved in global trade, a buyer has an increased certainty that the goods will be delivered from the seller.

Also, small businesses can have difficulty competing against bigger and better-known rivals. An SBLC can add credibility to its bid for a project and can often times help avoid an upfront payment to the seller.

How to Obtain a Standby Letter of Credit (SBLC / SLOC)

The standby letter of credit process is similar to that of obtaining a commercial loan and business financing, with a few key differences.

As with any business loan, you will need to provide proof of your creditworthiness to the bank. However, the SBLC / SLOC approval process is much quicker, with letters often being issued within a week of all paperwork being submitted.

Unlike traditional loans, the bank will require a standby of letter of credit fee of between 1-10% of the SBLC/SLOC amount before issuing the letter. This fee is usually charged per year that the letter of credit is in effect. If the terms of the contract are fulfilled early, you can cancel the SLOC without incurring additional charges. Standby letters of credit can help establish trust with your business partners and be a powerful tool to help meet your business goals.

Please note that Standby Letter of Credit (SBLC/SLOC) is different from Letter of Credit (LC).

CLICK HERE TO LEARN MORE ABOUT DIFFERENCE BETWEEN STANDBY LETTER OF CREDIT AND LETTER OF CREDIT.

loan, bg & sblc financing- Kingrise Finance Limited

WHAT IS BANK GUARANTEE (BG): A bank guarantee acts similarly to a line of credit, except that a line of credit can be drawn upon at will by the bank's client. A bank guarantee is used only if the client does not pay its vendor an agreed-upon amount. U.S. credit institutions are forbidden from assuming guarantee obligations, and therefore most international transactions require a standby letter of credit.

Examples of Bank Guarantees

There are many different kinds of Bank Guarantee namely:

A Payment Guarantee assures a seller the purchase price is paid on a set date.

An Advance Payment Guarantee acts as collateral for reimbursing advance payment from the buyer if the seller does not supply the specified goods per the contract.

A Performance Bond serves as collateral for the buyer’s costs incurred if services or goods are not provided as agreed in the contract.

A credit security bond serves as collateral for repaying a loan.

For example, St. Marys hospital is a new hospital that wants to buy $1 million in medical equipment. The equipment vendor requires St. Marys hospital to provide a bank guarantee to cover payments before they ship the equipment to St. Marys hospital. St. Marys hospital requests a guarantee from the lending institution such as Kingrise Finance Limited ( kingrisefinance.com ) keeping its cash accounts. Kingrise Finance Limited essentially cosigns the purchase contract with the vendor.

The Easiest and Best Way To Obtain a Standby Letter of Credit (SBLC / SLOC) Is To Contact Kingrise Finance Limited.

Kingrise Finance Limited is a direct provider of Standby Letter of Credit (SBLC/SLOC) and Bank Guarantee (BG).. We also provide Business Loans, SME Loans, Project Financing, recourse Loans, Non Recourse Loans, Letter of Credit, Standby Letter of Credit Funding, Lease Bank Guarantee, Performance Guarantee Bond, Tender Bond Guarantee, Advance Payment Guarantee, Bank Comfort Letter, sblc bg funding, lease sblc, lease bank instruments, sblc bg provider.

Our bank instruments, bg and sblc/sloc are issued from prime banks such as Barclays Bank London, Standard Chattered Bank, HSBC Hong Kong or any rated AAA bank of your choice. All our financial instruments are Cash-Backed and can be used as collateral to secure funding for projects, Discounting, Monetization and Private Placement Programs (PPP)..

BG/SBLC Description:

1. Bank Instrument Type: Cash Backed Bank Guarantee {BG} / Standby letter of Credit (SBLC) 2. Face Value: USD/EUR 1Million (Minimum) to USD/EUR 50 Billion (Maximum) 3. Issuing Bank: Barclays Bank London, HSBC Hong Kong, Citibank New York, Deutsch Bank Germany or any prime bank. 4. Age: One Year and One Day (with rolls and extensions where applicable) 5. Leasing Price: 4% of Face Value plus 2% brokers commission (Applicable only if there are brokers in the transaction) 6. Delivery: SWIFT MT-760 7. Payment: MT103 Swift Wire Transfer 8. Hard Copy: Bank Bonded Courier within 7 banking days.

Why Choose Us?

Fast Turnaround

Best Top Rated Banks

Competitive Low rates

No prepayment penalty

2 Days for Commitment

Extremely Satisfied Clients

WE KEEP OUR PROMISE

20 Years of Experience & Trust

No Personal Collateral Required

Solutions for every customer & every industry.

Loan amounts from $1 million to over $500 million

Fast Approvals & Fast Funding- Closing in as little as 5 days

BROKERS: We welcome new brokers who are direct to their client. New brokers are welcomed and are rewarded with 2% commission on every deal they bring to us.

Kindly contact Us today for all your funding needs, including business loan, sme Loans, project financing, Lease bg, Lease sblc, Bank Guarantee Provider

Blog:

https://kingrise.finance.blog

Website:

www.kingrisefinance.com

Email:

[email protected]

#sblc bg funding #sblc bg financing #lease bg sblc providers #bg providers #bg/sblc providers no upfront fees

2 notes · View notes